PLANIFICACIÓN DE PROYECTOS
PLANEACIÓN DEL PROYECTO
Def: es un conjunto de actividades necesarias para desarrollar el proyecto (derivado del EDT) donde tenemos:
Actividades que más tiempo consumen
Actividades continuas desde el inicio del proyecto hasta que es liberada
(Ej: Control)
En la planificación debo:
Tener distribuidas las TAREAS
Estimar el TIEMPO y los RECURSOS requeridos para completar cada tarea
Organizar las tareas de forma concurrente para mejor uso. (No todo es secuencial, haciendo un análisis previo puedo hacer cosas paralelas)
Minimizar dependencias entre tareas para evitar retraso debido a que una tarea espere a la terminación de otra.
(Hay tareas que si son dependiente y otras que no porque es inevitable, eso depende)
Depende de la intuición y experiencia de los administradores.
ESTRUCTURA DE PLAN DE GESTIÓN PROYECTO
Por lo menos tiene una estructura de la siguiente manera (puede tener más):
Introducción
Organización del Proyecto
Análisis de Riesgo
Requerimientos del Software y Hardware
Distribución del Trabajo (Determinó responsable y quienes son los que van a hacer)
Planificación del Trabajo
Monitorización y mecanismos de reporte.
PROBLEMA DE PLANIFICACIÓN
Es difícil estimar la dificultad de las tareas → Más difícil la estimación de costo (Cuando uno habla de estimación ya habla de un rango de error para más o para menos pero ya hay. La idea es ir mejorando esa estimación a medida que se avanza con el proyecto)
Productividad no es proporcional al N° de Personas que trabaja en una tarea
Incluir personas en un proyecto avanzado, pensando que se puede terminar más rápido, puede retrasar el proyecto por “overheads” en la comunicación.
Lo inesperado siempre sucede (cosas que no estaban previstas), entonces hay que considerar contingencias.
DETERMINACIÓN DEL PLAZO DE ENTREGA DEL SISTEMA
PUNTO DE VISTA INFORMÁTICO
El sistema es el objetivo que tengo a través del desarrollo
El proyecto es el medio para alcanzar el objetivo
PUNTO DE VISTA DEL USUARIO Y CLIENTE
El sistema es lo que hace falta para poder alcanzar los objetivos empresariales
El proyecto es un mal trago que hay que pasar.
“Quieren la aplicación ya, quieren resultados”
→ Entre estas dos cosas hay que hacer equilibrio que es fruto de negociaciones para hacer entender de que no todo se puede hacer para hoy y para mañana, sino que tiene un proceso para llegar al objetivo de forma exitosa.
EQUILIBRIO entre:
¿Cuánto tiempo y plata consumirá el proyecto?
¿Cuándo estará disponible para el usuario?
Importante el equilibrio de triple restricción que depende del tipo de proyecto, necesidades de negocio, etc.
LÍMITES DE LA DURACIÓN DEL PROYECTO Y ASIGNACIÓN DE RECURSOS
Un proyecto de 165 meses/hombre si nos vamos a los extremos (prácticamente imposible) podemos decir:
Si trabaja una persona → 15 años para desarrollar el proyecto
Ya no hará falta
costos de oportunidad
obsoleto para cuando lo entreguemos
puede hacer falta especialistas
Si trabajan 3300 personas → terminó el proyecto en un dia
orden de las tareas (no todo lo puedo hacer de forma paralela)
imposible
DURACIÓN DEL PROYECTO
Se debe ajustar a varios aspectos como:
Negociación (vemos las necesidades, la forma de desarrollo, etc)
Técnicas de desarrollo (vemos la cantidad máxima de recursos en cada tarea , ej: mi equipo de desarrollo, el de incluir especialistas, etc.)
Aspectos de gestión:
Los equipos deben ser pequeños (Ej: en proyectos grandes tenemos estructuras de equipos que se pueden armar donde esos equipos pequeños hacen referencia a tareas específicas)
Evitar problemas de comunicación y coordinación
DETERMINACIÓN DEL PLAZO
Negociación
Es un tema que es complicado
Tiene un espíritu comercial pero es peligrosa si:
Negociamos sin tener claro las especificaciones del cliente
El usuario tiene noción de la parte técnica de desarrollo actual donde creen saber decirnos cómo se hace eso u muchas veces no están acertados.
El cliente quiere la aplicación lo mas antes posible
El director o el jefe de proyectos negocia con un usuario de mayor nivel jerárquico (Es la única persona que negocia y donde muchas veces los equipos de atras no están de acuerdo)
Negociar mal plazos lleva a:
Tener fuertes niveles de COMPROMISO PERSONAL del jefe de proyectos
ESCASA PARTICIPACIÓN en la de fijar plazos con el equipo de trabajo. (Esto sucede por lo de arriba que muchas veces la gente que desarrolla no comparte todo con los jefes de proyectos o directores)
Esto nos lleva a un Marco Ideal para el Fracaso
El desconocimiento de las necesidades del usuario suele hacer que se subestimen
El compromiso unilateral del jefe (es una decisión que toma sola el jefe), en estas condiciones, difícilmente es respaldado por sus subordinados (Los equipos de desarrollo).
Selección de alternativas
Podemos ofrecer y analizar:
Distintos diseños
Distintos planificación para un diseño dado
Distintos enfoques al desarrollo que puede ser:
Desarrollo propio,
Con subcontrataciones o outsourcing, o
Compra de paquetes (enlatados).
Tenemos → Muchas posibilidades de Alcanzar el éxito donde nos basamos en
Datos históricos de productividad, es decir de cosas que ya hicimos
El compromiso de los desarrolladores es alto porque formaban parte de las estimaciones.
Método de Putman
Es un método que determina la cantidad de gente que hace falta en el proyecto en un determinado momento de tiempo.
donde:
Esfuerzo (t) = cantidad de meses/hombres que se aplica en un momento determinado
K : esfuerzo total del proyecto, en meses/hombre
a: es el factor de aceleración que indica el incremento inicial de la curva (es una constante)
t: un instante de tiempo a lo largo de la realización del proyecto.
dónde “eje y” son las personas y “eje x” es el tiempo, eso quiere decir que la cantidad de personas crece en el tiempo hasta un punto donde estamos en plena ejecución del desarrollo del proyecto y baja la curva.
Esfuerzo malgastado: tenemos 10 personas que no todos tienen tareas para hacer
Esfuerzo no disponible cuando hacía falta: Empiezan a faltar personas porque 10 probablemente no era suficiente.
Esfuerzo Aplicado demasiado tarde: cuando pasa esa etapa de crisis y sigo con las 10 personas la curva se desplaza, porque hubo pérdida de tiempo y el esfuerzo que aplico ya es tarde donde las personas después se quedan sin nada que hacer.
Esfuerzo Extra necesario para compensar la asignación incorrecta: Todo esto es para compensar tiempos para poder a tener algo coherente dentro de lo perfilado
Esto me dice que tengo que tener claro cómo haré para colocar las personas según el tiempo y las tareas que vaya realizando en la planificación. Voy viendo en qué momento necesito de los recursos y de ahí voy viendo.
Podemos adoptar la cantidad de gente disponible. Este sería el mismo proyecto y podemos ir viendo cómo varían las gentes.
Curva amarilla → tiene muchas personas y tiene un tiempo mínimo para desarrollo
Curva roja → pocas personas y me demoro más.
BOHEM
Duración del proyecto → Desde la especificación a la entrega del producto, no puede pasar menos de :
A esto se le denomina Región Imposible. El 99% de los proyectos cumplen esto. Cuando tenemos que negociar debemos tener muy claro el tiempo, y no debemos negociar por debajo de este T porque si lo hago por debajo vamos a tener que renegociar o capaz tenga problemas
DURACIÓN DE LAS TAREAS
Este esfuerzo en base a los recursos que me asignaron puedo saber el tiempo.
Realizó asignación de tareas
Determinó duración de tareas en función de la cantidad de personas asignadas
INTERFERENCIAS
Nos referimos a algo que no planificamos bien.
Repetición de trabajo o muchas corrección de defectos
Vacaciones, fiestas, feriados, etc. (Cosas que capaz no tuvimos en cuenta)
Consulta de otros equipos de empresa (Nos hace perder tiempo)
Papeleo que debería haber sido delegado (Capaz no tenemos a las personas)
Falta de formación en el personal del Proyecto
Falta de reuniones del equipo
Interrupciones como telefonicas
Tiempo de espera en reuniones
El tiempo que tarda el personal en cambiar de tarea, no se puede esperar que sea instantáneo. (No es automático pasar a hacer otra tarea)
Puede perder entre un 30% y un 50% de los tiempos planificados, debo analizar estas interferencias.
EXPERIENCIA
La gente con más experiencia:
Deben enseñar y administrar al personal del proyecto en temas no previstos
Son consultores de otros proyectos
Se les puede pedir que asistan a reuniones, presentaciones (Puede ser que no tengan relación con el proyecto)
ASIGNACIÓN DE TAREAS A PERSONAS
Es mejor disponer de un equipo pequeño con buenos profesionales.
Con herramientas, lenguajes y procesos capaz no buenos pero con la gente correcta, pueden tener éxito.
Lo contrario parece imposible. Es decir, tener los últimos lenguajes, tecnología y no tenemos gente capacitada entonces nos va a ir mal.
Trabajamos con equipos de desarrollo y no con personas puntuales. Si confiamos todo a unas pocas personas también nos irá mal. Tenemos que tener un EQUILIBRIO DEL PERSONAL!!!
Ver por ejemplo una personas que tiene menor experiencia que este con una que tenga mucha.
ASPECTOS RELACIÓN EMPLEADO- TAREA
Cognitivo (KAS), la capacidad técnica
Los conocimientos
La capacidad
La experiencia
para realizar la tarea
Conativo (MAC), la voluntad
La motivación
El compromiso
La seguridad
para realizar la tarea
Es importante combinar estos dos aspectos para lograr un buen resultado. Podemos tener variantes como ser:
Puede realizar el trabajo y quiere realizarlo → IDEAL
Puede realizar el trabajo y accede a realizarlo:
Habrá que pensar en otras tareas que motiven más a esa persona para que quiera realizar el trabajo que estamos proponiendo
Puede realizar el trabajo pero no quiere realizarlo:
Tenemos problemas, posiblemente nos encontremos en otra situación. No tenemos que obligar porque nos podemos retrasar más o complicarnos más. Buscamos otra tarea.
Puede ser formado para realizar el trabajo:
Supone:
Gastar dinero para la formación
Modificar la programación con la formación (trabaja menos seguro para formarse)
Estar dispuesto a la sobrecarga que suponga
Afrontar el Riesgos de que no funcione bien
No es cosa fácil porque se invierte para formación. Suele pasar de que capacitamos y capaz se va a otro lado, entonces corremos también ese Riesgo.
No puede realizar el trabajo
Tenemos problemas serios
Tenemos que identificar otras tareas para esta persona
Tenemos que detectar eso e ir conociendo a la gente, porque son factores que influyen en los tiempos.
CANTIDAD DE PERSONAS ASIGNADAS
A una tarea → asignó cantidad de personas determinada
Proporción de cantidad de personas asignadas y el esfuerzo de tarea → No tiene relación Lineal
2 semanas → 5 personas y 5 semanas → 2 personas (No es así)
Por ejemplo: asignar más personas al proyecto, porque me retrase en tareas con la idea de que se reduzca la duración. Es parcialmente cierto, puede suceder de que haya mala comunicación y coordinación y menos puede suceder si está bastante avanzado el proyecto.
A medida que agregue más personas, se achica el tiempo
La tarea no se puede partir (para que nazca un niño se requiere nueve meses, no importa cuantas mujeres se asignen). No tenemos que poner gente que no aporte a ese desarrollo.
Puedo poner todas las personas que quiera pero no varía el tiempo.
La tarea se puede partir, pero requiere comunicación entre las personas
Es como el primero prácticamente, pero tiene un descenso hasta determinado límite. Por ejemplo tenemos 3 meses por más que agregue personas es igual el tiempo.
La tarea se puede partir pero las interrelaciones son complejas donde cuesta más tiempo realizar la tarea con muchas personas.
Es tanto el esfuerzo de comunicación y coordinación, que donde más personas agregue más tiempo me voy a demorar.
Es distinta la visión del Director que las de los empleados en relación a las asignaciones:
Asignar tareas a quienes quiere hacerla
Trabajar las asignaciones con los empleados
Hacer una lista de objetivos
Ir haciendo reuniones hasta que esté clara la asignación (comunicación para saber que tenemos que hacer)
CONSIDERACIONES:
Productividad de programadores es muy variable
Es habitual la relación de 1 a 5
En un estudio puede haber de 1 a 26 (Tenemos que realizar algo para motivar que no afecten la productividad del equipo con factores externos )
En tareas críticas conviene poner al personal con mayor experiencia ya que se espera que sean más productivos.
Esto agregó en ficha de tarea
Pensamos en:
COSTE MÍNIMO DE DESARROLLO
En tiempo donde tenemos especialistas formados en cada área
En dinero donde usamos el personal necesario para que se lleven a cabo las tareas y ya conozcan las áreas donde se les asignó.
COSTE MÍNIMO A LARGO PLAZO
Pensando a largo plazo, debemos pensar en Mantenimiento
Hacer que el personal con menos experiencia trabaje en el desarrollo, dando formación en caso de ser necesario
Hacer que el personal se sienta promocionado (Buscamos un premio dando motivación) donde detectamos objetivos de cada empleado y hacemos que cada nuevo proyecto sea un paso en consecuencia de estos.
CALENDARIO TEMPORAL ACEPTABLE - PLANIFICACIÓN TEMPORAL
Se identificó hasta este punto:
los entregables,
las fases
las tareas (WBS y las fichas de tareas)
los recursos a asignar a cada tarea
las personas asignadas a esas tareas.
Tendremos que crear un calendario de realización (todo el equipo podrá ir viendo, mejorando y controlando el progreso), con dos objetivos:
Debe quedar claro que se espera y para cuando (tiene un tiempo finito)
Comprobar que es posible en un día (24h), pero consideramos horas laborables. No debemos subestimar los tiempos ni estimar mal.
Creación del Calendario y Camino Crítico.
ORDENAR LAS TAREAS
(tenemos que ver como están las tareas en los tiempos de desarrollo, que es lo que hacemos primero y después; y poder identificar tareas que se hagan en paralelo)
De forma genérica, agarramos una ficha y nos preguntamos:
¿qué debe haberse hecho antes de esto?
¿qué puede hacerse a la vez?
¿qué debe seguir a lo que hacemos ahora?
Ya empezamos a ordenar y añadimos a las fichas la lista de tareas precedentes.(para determinar qué tarea se debe realizar). Identificamos y documentamos dependencias:
Restricciones
Son todos los factores que limitan al equipo de desarrollo. Son impuestas por el cliente o la dirección de la empresa que trabajamos.
Ej: Lenguajes de Programación, equipos en que deberá funcionar, personal del que dispondrá.
(Si no conozco el LP me debo capacitar antes)
Supuestos
Son factores que se consideran verdaderos durante la planificación (después cuando vamos desarrollando nos damos cuenta que no es así, hay que estar seguro)
Tienen un grado de riesgo
Están directamente relacionados con los riesgos del proyecto
Ejemplo: se dispondrá de un ordenador en casa del cliente.
Que pasa si esa máquina la ocupa el hijo o le pasa, y haber supuesto que esa máquina estaba a mi disposición, estaba mal.
Dependencias obligatorias
Son inherentes a la naturaleza del trabajo (es decir son aspectos técnicos que no hay formas de salvarlos pero si de predecir)
Se suelen deber a la necesidad de disponer de un entregable que es punto de partida en la tarea
Ejemplo: “para probar el programa XYZ debe ser antes programado el programa XYZ”. Es una dependencia obligatoria de que antes de probar debo codificar que debo tener en cuenta
Dependencias discrecionales
Son las que definen el equipo de proyecto.
Hay que ser cautelosos, puede condicionar la programación del proyecto en el futuro
Se basan en:
Las “mejores prácticas”
se prefiere una secuencia porque será más fácil de controlar
Limitaciones en la asignación de personal
Dependencias externas
vienen impuestas desde el exterior
se refieren a la interdependencia:
con otros proyectos
con empresas externas o contratos y no podemos ejercer ninguna presión
pero si debemos tener muy en cuenta los contratos y tiempos para que no haya demoras
Una actividad no puede comenzar hasta que no se disponga de un producto ajeno. Ejemplo: pruebas de programas sobre el HW en particular.
Completamos la Ficha de tarea:
Tenemos la ficha, una parte de predecesoras que son tareas que necesito que se hagan antes.
Representación Gráfica de la Ordenación de Tareas
DIAGRAMA DE GANTT
Def: Es uno de los diagramas más antiguos y es uno de los más usados. Se representa en un cuadro de doble entrada
En el eje vertical están las tareas
En el eje horizontal está el tiempo
Cada tarea se representa con un rectángulo.
Si me demoro en una tarea que tiene sucesoras, las sucesoras se van a tener que correr también donde todo el proyecto demora más de lo que planifique inicialmente.
Lo de celeste son las Holguras porque si en esa tarea nos demoramos un poco más de lo que se planificó, en realidad no pasa nada porque nadie está esperando que se termine esa tarea para poder empezar, pero si me llego a demorar mas de 6, en el ejemplo del gráfico si voy a tener problemas.
Diseño de base de datos es una tarea que es predecesora de realización de esquema por eso también tiene holgura si se demora.
Programas: Microsoft Project donde se puede ver horas de trabajos, feriados, recursos asignados, todas esas cosas que hay que tener en cuenta. Esta es una se pueden usar otras
Ventajas
Es fácil de entender por todo el mundo (Uno le puede mostrar al cliente y lo pueden entender fácil)
Se puede aplicar para representar la utilización de recursos (Con diagrama de cargas)
Desventajas
No muestra explícitamente la relación entre tareas
En proyectos con muchas tareas es complicado de crear
DIAGRAMA DE PRECEDENCIAS
Def: es un grafo ordenado donde:
las tareas se representan como nodos. Todos los nodos tienen el mismo tamaño y pueden contener mucha información sobre la tarea..
Las relaciones entre tareas son los arcos. Los arcos van desde la tarea antecesora a la predecesora, indicándose con una flecha.
Uso más habitual en programas informáticos(junto al Gantt)
Al utilizar sistemas informáticos para generar los diagramas, se pueden establecer relaciones del tipo:
Fin a Comienzo y
Comienzo a Fin,
Comienzo a Comienzo y
Fin a Fin
Haremos lo de comienzo a fin y después hacemos retorno, en nuestro caso.
DIAGRAMA DE FLECHAS
Def: Es una representación dual a lo anterior donde
Las tareas se representan como arcos
Los nodos son sucesos puntuales en el tiempo donde muestra que se alcanzó un estado y al concluir todas las tareas que llegan a él.
Pueden aparecer actividades ficticias para asociar estados parciales (Por esta razón no es muy usado en planificación de sistemas informáticos)
El cálculo de calendarios se basan en modelos formales
Parece menos intuitivo que otros gráficos, debido fundamentalmente al uso de actividades ficticias.
Este es más usado en desarrollos formales donde hay más cosas científicas y diseños formales
CALCULAR FECHAS y CREAR CALENDARIO
Hay diversas formas de abordar estos cálculos. Veremos una muy intuitiva donde vemos las fechas importantes en cada tarea. Pasos:
Calcular fechas para cada tarea en un proyecto.
Definir el camino crítico.
Aquí es el paso donde nos sentamos con el almanaque y empezamos a ver los días hábiles, feriados, eventos, etc. para tener una buena planificación. En el diagrama de precedencia, podemos ver un nodo:
Descripción de la actividad: es un nombre dado a la actividad
Etiqueta de la actividad: es un número que identifica a cada actividad
Duración: es el tiempo que calculamos que se tardará en completar la tarea
Inicio temprano: es la fecha más temprana en que se puede comenzar la tarea
Final temprano: es la fecha más temprana en que se puede finalizar la tarea (fecha óptima de finalización)
Inicio tardío: es la fecha más retrasada en la que se puede comenzar sin afectar la fecha de terminación del proyecto.
Final tardío: es la fecha más retrasada en la que se puede terminar la tarea sin afectar la fecha final del proyecto.
Máximo tiempo disponible: es el tiempo máximo que puede durar una tarea en caso de colmenar en su inicio temprano y concluir en su final tardío.
Holgura: es el tiempo que disponemos para jugar con el inicio de la tarea, sin afectar el proyecto.
3.1 no puedo hacerla hasta que no termine 2.2 y 3.2
El inicio temprano es “0” si las tareas no tienen predecesor.
El final temprano de cada tarea es el inicio temprano más su duración.
Si la tarea tiene predecesoras, y todas estas tienen calculado su final temprano, asignamos como inicio temprano el máximo de todos ellos.
Obtenemos la fecha de final del proyecto,
la máxima fecha de final temprano,
O la indicada por el cliente si es posterior (No me conviene que sea esto porque lo calculado es más realista. Aquí tenemos que negociar). Habitualmente se toma la primera, el cliente siempre lo quiere para ayer.
A todas las tareas que no tengan sucesoras se le asigna esta fecha como final tardío.
El inicio tardío se calcula restando al final tardío la duración.
Aquellas tareas con sucesoras, se les asigna como final tardío el mínimo de los inicios tardíos de estas.
Máximo tiempo disponible y Holgura:
- Máximo tiempo disponible = Final tardío - Inicio temprano
- Holgura = Máximo tiempo disponible - Duración
Definición de Camino Crítico
Un Camino Crítico es un conjunto de tareas con holgura cero. Si la duración es mínima hay camino crítico. (Al camino crítico es donde tengo que prestar toda la atención y hay que tener cuidado)
Parte de una tarea sin predecesoras, atraviesa el grafo por tareas con holgura cero y termina en una tarea sin sucesoras
Cuando una tarea del camino crítico se retrasa, también lo hace el proyecto.
Esta tabla es todo el trabajo previo que hay que hacer antes.
Las holguras son las que tengo que prestar atención, porque si tengo una que se corra en el tiempo, se corre el tiempo del proyecto. A diferencia de las otras que están arriba que tienen holguras de 0.5. Lo del final es la duración del proyecto con todos los cuidados, dependencias, restricciones, feriados, etc.
DIFERENCIA ENTRE PERT Y CPM (OTRA FORMA)
REPRESENTACIÓN GRÁFICA DEL USO DE RECURSOS DE UN PROYECTO
Es muy útil el poder ver tan solo las tareas que hay asignadas a cada recurso, para:
comunicar a los participantes el uso de un recurso compartido,
verificar que se utilizan de forma equilibrada,
verificar que ningún recurso se pretende utilizar más de lo posible.
Se usa el Diagrama de Gantt
Además se usa el Diagrama de Cargas
Puedo hacer este diagrama con cualquier actividad de las que están el proyecto. El diagrama de cargas me permite saber en qué momento necesito saber que cantidad de personas necesito y qué tipos de personas.
Revisión y ajuste del calendario
(el primer bosquejo capaz dejamos de lado cosas que se deben tener en cuenta):
La primera planificación suele hacerse con criterios técnicos, con dos enfoques:
En función de los recursos: equilibrar la disponibilidad de personal, vemos la posibilidad de si podemos sacar una persona de una tarea y ponerla en otra más crítica.
En función de las necesidades del usuario: habitualmente siempre desea que se termine lo más pronto posible.
Algunos puntos a tener en cuenta en revisión de planificación:
Sobre la secuencia de las tareas:
¿Es posible sacar una tarea de la secuencia?
Aumentar el paralelismo entre tareas: Existe la posibilidad que una tarea pueda comenzar cuando la precedente se ha realizado al 60%. Esto es peligroso , es válido y lo puede hacer, pero puede llevar a retrabajos en caso de que salga mal.
Sobre la duración de las tareas:
Utilizar mejores técnicas y herramientas
¿Existe software que pueda dar soporte a una tarea?
Tenemos que ver precios y tener en cuenta la curva de aprendizaje.O podemos usar herramientas que ya conocemos
Incentivar la productividad de las personas.
Ejemplo: dos personas no pueden ser parejas por una cuestión de productividad y de problemas personales.
Modificar la cantidad de personas asignadas a una tarea.
No meter más gente en un proyecto avanzado, podemos hacerlo pero debemos pensarlo bien como hacerlo y a quién metemos. Podemos reducir la duración de las tareas del camino crítico y las del proyecto.
Cuando el reducir la duración de una tarea lleva a un coste mator, debemos ajustar la reducción al máximo con coste mínimo.
Horas extras
Esto en principio puede suponer un coste adicional o no. Si al principio ya pensamos en esto, ¡estamos mal!
Se recomienda hacer uso de las horas extras solo en caso puntuales, como consecuencia de una desviación
Pensar esto en la planificación es poco razonable.
Aceptación generalizada del plan
(debe estar el líder y el equipo para no tener conflictos a futuro, todas aquellas personas involucradas deben estar de acuerdo)
Una planificación buena es:
aceptada por todos los participantes
Todos los miembros crean en ella , para esto hay que ser realista.
La probabilidad de éxito es más en función de la fe y confianza.
Comentarios
Publicar un comentario