¿Cuándo va a estar esto? ¿Cuánto va a llevar?. Estas preguntas son muy habituales en la gestión de los tiempos de un proyecto. Y saber los plazos con exactitud es complicado. La realidad obliga a vivir con (cierta) incertidumbre. Los problemas suelen ser dos:
- Mala definición. Es decir saber (bien) qué hay que hacer. Que sean actividades bien definidas (tareas CAV). Hay que trabajar el diseño del proyecto pero a veces no es tan fácil porque hasta avanzar no se tiene más información.
- Mala Estimación. A nadie le gusta dar plazos, pero son imprescindibles. Y la duración depende de la definición y de tener los recursos disponibles. Y eso tampoco es tan fácil saberlo a priori. Solemos ser demasiado optimistas (los jefes sobre todo).
Como planificar es adivinar, la definición y la estimación de tareas a veces no está clara. Pero una cosa es equivocarse de vez en cuando y otra un retraso repetido en la estimación. Eso no es incertidumbre, es hacer mal tu trabajo. Gestionar un proyecto implica saber conocer la probabilidad de acierto en la estimación. Y eso, generalmente, sólo se sabe con la experiencia.
Y es lo que propone Joel Spolsky en su excelente artículo Evidence Based Scheduling (en inglés, un poco largo y en el contexto software). Habla del concepto de velocidad (tu probabilidad de acierto) como ratio realidad/estimación. Es decir si es mayor que 1, la realidad te supera (vas muy rápido) y si es menor vas muy lento (muy pesimista). Lo ideal, es un equilibrio. Y que si dices 1 días, sea un día (no 2, porque vas muy rápido o 0,5 porque vas lento).
Y con esta información usa un calendario basado en estimaciones pasadas. O lo que es lo mismo: aprende de la experiencia. Si conociéramos la velocidad de cada profesional del equipo podríamos determinar el plazo final (que es el que generalmente más nos interesa). Y era (en el 2007, luego se vendió) una de las funcionalidades de su herramienta FogBuzz. Es lo que hacemos inconscientamente (nos fiamos más de los que aciertan en sus estimaciones).
El concepto es aplicable a cualquier proyecto: estimar una fecha de entrega basándose en la experiencia previa (por trabajador). Y para eso es necesario:
- Responsable. Hay que saber quien es el responsable de la tarea y la estimación
- Estimación. A nadie le gusta dar plazos pero es inevitable. Tanto la original como la real. Así veremos la diferencia. Y si hay errores (o problemas de calidad) se incluyen en la duración real
- Control Frecuente. Con cierta frecuencia (dependerá de los plazos del proyecto) se debe recalcular la fecha de entrega y gestionar las tareas.
Y apuntarlo. Y como es un proceso de mejora continua cada vez será más exacto y las fechas más certeras. O sea, el escenario ideal. Se trata de ir aprendiendo del histórico (es lo que llaman gestión del conocimiento).
Sin embargo, lo habitual es que los plazos suelen ser un auténtico dolor de cabeza y un total descontrol. A medida que llegan los problemas, uno se relaja. Y como todos tenemos mucho que aprender, y los proyectos van cambiando, estas son algunas recomendaciones para gestionar mejor los plazos (y su incertidumbre):
- Una tarea, un responsable. Si hay un equipo de gente, da igual. Tiene que haber un responsable de esa tarea.
- Ninguna Tarea sin Estimación. A nadie le gusta dar plazos pero es inevitable. Para controlar la incertidumbre hay que tener un plan.
- Un responsable, una estimación. La estimación la da el responsable de la tarea (nunca los jefes). Hablar es fácil, lo difícil es hacerlo.
- La realidad es pesimista. Es mejor no pecar de optimista porque, salvo que tengas mucha experiencia en esa tarea, vas a tardar mucho más
- La realidad NO es perfeccionista. Claro que con más tiempo se hace mejor, pero la realidad es que hay limites. Usa la Ley de Parkinson y ajusta el alcance al tiempo (no al revés).
Sabiendo que tú tienes el control (siendo el responsable), haz un control frecuente y detectarás a tiempo los problemas y retrasos. Y vas a ir aprendiendo mucho, y quizá aprender cual es tu velocidad, según qué tareas.
Ya, ya sé que no es fácil y que depende del tipo de proyecto. Pero no esperes al último día para anunciar los problemas. Cuanto antes se conozcan los problemas, mejor (aunque no guste). No mires para otro lado, que después es peor. En un proyecto siempre hay más gente y más agendas involucradas, no eres sólo tú. Los plazos son un un acuerdo que se define entre todos. Retrasarse, sin avisar, es romper la confianza. Ese es el problema de gestionar mal los plazos.
Actualizado del original (2009)