Estimaciones (3)

(este post es parte de una saga que comenzó aquí y siguió aquí)

La estimación y el plan no son lo mismo. Creer que sí es un error común a la hora de planificar un proyecto de software. Son temas muy relacionados pero no son lo mismo.

Mientras la idea de estimar es entender cuánto cuesta, en términos de esfuerzo, construir un determinado software, el objetivo del plan es mostrar la forma en que cumpliremos un determinado objetivo. Por ejemplo el de entregar (en producción funcionando) un determinado software, para una determinada fecha y con un determinado nivel de calidad.

El plan compromete fechas, la estimación no.

El plan necesita una estimación sobre la que basarse pero hay tareas que no tienen que ver con construir el software y que muchas veces el equipo de proyecto desconoce o subestima [1]. Es por esta razón que muchas veces, además de la mirada de desarrollo, se requiere una mirada que vaya más allá. Si el líder del proyecto la tiene, excelente; y si no, hay que complementarlo.

Es clave diferenciar ambos términos durante la planificación, en las conversaciones dentro del equipo y con los stakeholders del proyecto puesto que el principal problema en esa etapa del proyecto es que se produzca un GAP entre ambas cosas.

Cuando el GAP entre el esfuerzo estimado y el plan trazado es pequeño, el PM o el líder pueden tener margen de maniobra para “manejarlo” [2] pero cuando es grande, sencillamente el proyecto está condenado al fracaso.

Seguimos pensando..

Update: Podes seguir leyendo sobre estimaciones aquí.

[1] Por ejemplo, el equipo de proyecto no tiene porque saber que se requieren 2 semanas para rodar el proceso de compra de un servidor nuevo para el producto que está construyendo.

[2] Según Steve McConnell las estimaciones son un ejemplo del principio de incertidumbre de Heisenberg. Dicho principio es la idea de que el mero acto de observar una cosa, la cambia. Debido a esto no podemos estar seguros de su comportamiento si nosotros no estuviéramos observando.