¿Cómo determinar la fecha de finalización del proyecto?

Como gerente de proyectos, ya trabajé en algunos proyectos tecnológicos con equipos recién formados cada vez. El equipo suele estar formado por 2 o 3 miembros que hacen el trabajo real. Es difícil determinar la velocidad. No somos muy ágiles y tampoco hacemos sprints.

Por lo general, terminamos el trabajo antes o al final del trimestre. Estos recursos están comprometidos con el trabajo pero durante la semana probablemente al 70-80% de su capacidad. El resto del tiempo es para apoyar las necesidades del negocio.

Una vez más, tengo otro grupo de proyectos con diferentes miembros en el equipo. ¿Cómo puedo determinar aproximadamente cuándo se completará el proyecto? Mis 2 desarrolladores han dejado sus estimaciones para todos sus boletos.

Si "no eres realmente ágil" y no usas Scrum, ¿qué haces? Los métodos por los cuales puede estimar la finalización de un cuerpo de trabajo dependen de cómo planifique y ejecute ese trabajo.
Gracias, quería saber si hay mejores enfoques para salir de este patrón al que se enfrentan mis equipos. Mgmt podría sugerirlo, pero se ha estado demorando porque quieren aumentar las ganancias lo antes posible. La mentalidad de los equipos ha sido hacer las cosas. Creo que determinar una fecha aproximada de finalización es difícil, porque no publicamos con frecuencia. Más como proyecto por proyecto basado y eso sucede cada 2-3 meses.
En ágil, a menudo fijamos el cronograma y variamos el alcance. Si el trabajo inicial tiene valor agregado, entonces se discute el trabajo de seguimiento. Es una forma diferente de ver la situación. A veces hay resistencia a variar el alcance por parte de una parte interesada, incluso aunque el alcance siempre varía a medida que se sabe más sobre el proyecto de todos modos. Así como a veces hay resistencia a dar prioridades aunque eso solo signifique que el desarrollador establece las prioridades.

Respuestas (3)

¿Con qué frecuencia hará lanzamientos? Una cosa que podría intentar es agrupar tickets en lanzamientos tentativos (o iteraciones), convertir sus estimaciones en puntos y luego estimar una velocidad de lanzamiento/velocidad de iteración.

La priorización y la minimización de las dependencias también serán importantes, especialmente si su equipo no trabaja a tiempo completo. Etiquetó su pregunta como Scrum. Si desea avanzar hacia Scrum, comience con los propietarios de productos, comparta un trabajo pendiente con ellos y defina algunas prioridades. Es un error centrarse en la fecha de "finalización del proyecto" porque, por lo general, todas las cosas importantes deberían suceder al principio del programa de trabajo, nunca al final.

Lanzamos aproximadamente cada 2 o 3 meses. Sí, muchas personas están obsesionadas con la fecha de finalización del proyecto. Me han dicho que obtenga una estimación del equipo y determine la fecha aproximada. ¿Es eso posible? Mi equipo (tamaño de 2) cree que lleva 20 días completarlo. Al sumar todas las tareas, totaliza hasta 30 días. El lugar aquí ha estado ejecutando el estilo de hacer las cosas. Me gustaría Agile/Scrum pero tomará un tiempo llegar allí.
@user2763930, 30 días para "completar", pero luego tendrá que esperar hasta dos meses antes de lanzarlo. Eso no suena muy realista, pero si tiene razón, su estimación se hace muy fácil. Su estimación solo necesita ser precisa a los 2 o 3 meses más cercanos porque es cuando se publica. Entonces, 20 a 30 días parece que debería estar lo suficientemente cerca como una estimación.
Sí, sorprendentemente, el equipo me da un número bastante preciso/cercano de cuándo se completa el trabajo. Sin embargo, me gustaría liberar o presionar para pinchar con más frecuencia. Mgmt preferiría tener menos lanzamientos con más cosas juntas. He defendido que este proceso ofrece menos valor y que todas las características crean un atasco para entregar a los clientes que esperan. ¿Alguna vez se ha encontrado trabajando en proyectos con este tipo de estilo de estimación/pronóstico? -En el pasado, he trabajado con equipos que son ágiles y entregan constantemente cada 2 semanas. Ahora me enfrento a esta cultura de equipo diferente. ¿Pensamiento/visión?

Realmente depende de la naturaleza de la acumulación/trabajo restante y la metodología que está utilizando, que no está clara en su pregunta.

Si está utilizando SCRUM, tendrá que saber 2 cosas.

  1. Punto de historia estimado(punto de historia /= estimación de punto de historia) toda la cartera de pedidos
  2. La velocidad del equipo dado que el equipo es eficaz y la composición del equipo no cambia.

(Carga atrasada estimada/Velocidad del equipo) * Duración de los sprints + Buffer: los eventos/abandonos planificados deberían brindarle un número aproximado. Recuerde que los cronogramas en Agile son conjeturas informadas, no datos reales.

Si es una cascada, debes volver a tener 2 cosas.

  1. Trabajo restante estimado
  2. Asignaciones de recursos.

En función de las asignaciones de recursos y su capacidad, deberá calcular los plazos, que en la mayoría de los casos son fijos.

Si la metodología es similar a XP, deberá tener en cuenta los planes de lanzamiento y el número de iteraciones en el cálculo.

Gracias. Mi equipo (tamaño de 2) cree que lleva 20 días completarlo. Al sumar todas las tareas, totaliza hasta 30 días. Al principio, pensé que crear un sprint de 2 o 3 semanas ayudaría a mis 2 recursos. No lanzamos a producción después de que se completa un sprint. Lanzamos cuando todo el proyecto está completo, lo que generalmente ocurre dentro de 2-3 meses. El equipo acaba de comenzar recientemente, pero también se involucra para hacer misceláneos. trabajar. Hasta ahora, lo que he estado haciendo es monitorear el número total restante de días para trabajar en todas las tareas, para determinar la fecha completa y agregar 2-3 semanas de tiempo de búfer.

Es difícil asesorar sobre esto sin saber más sobre el modelo de ciclo de vida básico, el paradigma de desarrollo y los métodos de estimación. Pero dices "no somos realmente ágiles", por lo tanto, algo como un CBS/WBS debería ser la columna vertebral de la planificación.

  • Escriba una lista de los elementos/módulos del producto.
  • Estime el esfuerzo para llevar cada uno a un estado liberable. Preferiblemente, ingrese estimaciones de 3 puntos (qv) y calcule las sumas en consecuencia.
  • Compare estas estimaciones con lo que cree que pueden hacer sus recursos.
  • Tenga en cuenta una asignación para el "pegamento" del sistema. Si lo desea, represente esto como un módulo adicional.