¿Cómo podemos estimar una fecha de finalización para un proyecto utilizando nuestro sistema de pizarra?

Somos un equipo de desarrollo de 8 sin un PM oficial. Hasta ahora, hemos organizado nuestra carga de trabajo al tener siempre alrededor de 20 a 40 tareas próximas ancladas en una pizarra. Básicamente, es una tabla con los nombres de las personas como encabezados y sus tareas en sus columnas.

Esto es útil, ya que está claro en lo que todos están trabajando y en lo que trabajarán pronto. Sin embargo, un problema al que nos enfrentamos es saber cuándo se van a terminar una serie de tareas.

Planificar todo en Excel parece bastante inflexible. Tan pronto como cambia una tarea, parece que hay que volver a trabajar mucho.

¿Existe un método que combine el enfoque de planificación de pizarra simple y su flexibilidad con un método para predecir las fechas de lanzamiento e idealmente respalde un buen método para manejar las estimaciones cambiantes para las tareas individuales?

Respuestas (1)

Estimar hitos de entrega a partir del rendimiento

Ya tienes media solución. Si bien su proceso de programación no es particularmente ágil, puede ampliar lo que ya está haciendo calculando los tiempos de ciclo y usándolos para estimar su programación de lanzamiento.

A riesgo de simplificar demasiado, puede obtener una estimación razonable de su fecha de lanzamiento haciendo lo siguiente:

  1. Haga un seguimiento del tiempo promedio que le toma al equipo completar cada unidad de trabajo. (Nota: estos datos básicos también se pueden usar para calcular el tiempo de entrega, el tiempo de ciclo, el tiempo takt y otras métricas relacionadas).
  2. Cuente todo el trabajo necesario para alcanzar un hito o lanzamiento.
  3. Multiplique el total de unidades de trabajo necesarias para lograr su objetivo por el tiempo promedio necesario para completar las unidades. En otras palabras, ciclo_tiempo * backlog_items = lead_time para cada hito.
  4. Aplicar factores de fudge para dependencias externas, si las hay.
  5. Use el resultado como un pronóstico contra el cual hará un seguimiento del progreso, no como una garantía inquebrantable.

Esta es la base informal de la mayoría de las métricas Kanban y Lean. Es un sistema relativamente liviano para superponer el proceso de programación que ya tiene, y generalmente produce resultados "suficientemente buenos" sin una gran cantidad de gastos generales de proceso que se gastan persiguiendo una precisión falsa.

Si cuenta el tiempo de su ciclo en días, sin prestar atención a las horas reales trabajadas, sino simplemente "Empecé el lunes, fui a producir el jueves, así que son cuatro días. No importa que estuve desviado durante 8 horas en el medio", no debería haber una necesidad de un factor de fudge. A menos que, tal vez, tenga una dependencia externa fuera de lo común. Quizás.