El cono de incertidumbre, descrito por Steve McConnel, muestra lo que cualquier profesional del software con experiencia sabe. Que al principio de cualquier proyecto no sabemos exactamente cuánto tiempo va a durar.
Las razones de esto son muchas. No hay dos proyectos que tengan:
- Los mismos requisitos.
- Las mismas personas.
- El mismo contexto empresarial.
- La misma tecnología.
- Las mismas prioridades &limitaciones.
Cada uno es único. Cada línea de código está hecha a mano. Y el trabajo de conocimiento en el que participan personas creativas e inteligentes no se presta a la precisión como lo hace la excavación de zanjas.
Sin embargo, lo que se pide es precisión. Los patrocinadores quieren saber con exactitud cuándo estará terminado el proyecto y cuánto costará.
El tratamiento de este enigma es casi tan antiguo como el propio tiempo. He aquí algunas formas en las que los equipos y las empresas se enfrentan a esta incertidumbre.
Cómo lidiar con el cono
Aumentar la estimación
Después de sentir el aguijón de la subestimación, una reacción común es duplicar o triplicar la estimación la próxima vez. Esto reduce sin duda el riesgo inicial, pero rellenar los números es más difícil de lo que parece.
Da una cifra demasiado grande y los patrocinadores se negarán a aprobar tu proyecto. Si la cifra es demasiado baja, te arriesgas a quedarte sin dinero. Esto se vuelve doblemente peligroso cuando se trata de contratos de oferta fija, en los que hay aún más presión para mantener las cifras bajas.
La mayoría de los proyectos añaden algún tipo de relleno a las cifras finales para tener suficiente margen de maniobra. Otra cosa que pueden hacer los equipos es comparar este proyecto con otros.
Dimensionar el proyecto relativamente
Los humanos somos muy buenos para dimensionar las cosas relativamente. No podemos decir con precisión el tamaño de una roca. Pero podemos decir lo grande que es en comparación con otra cosa. También podemos utilizar esto para dimensionar los proyectos.
Ser franco y honesto
El modo de funcionamiento por defecto de Agile es la transparencia y la visibilidad. Así que no debería sorprender que el modo ágil de tratar con el cono sea ser franco y honesto.
Mira. No sabemos cuánto tiempo va a tomar esto. Esta es nuestra mejor suposición. Pero si nos da un par de iteraciones, podemos construir algo, medir el tiempo que toma, y luego decirle dar un sentido mucho mejor de lo grande que es esta cosa.
Otro enfoque que algunos equipos ágiles tomarán para ayudar a comunicar la incertidumbre es presentar las estimaciones como un rango.
Esto tiene la ventaja de mostrar visiblemente a los patrocinadores la incertidumbre que conlleva el proyecto, y luego dejar que los patrocinadores decidan cuánto riesgo pueden permitirse asumir.
Financiar de forma incremental
Otro enfoque que tiene mucho sentido, pero que por desgracia no veo que se aplique con suficiente frecuencia, es la financiación incremental.
Con la financiación incremental no se pide toda la bolsa de dinero por adelantado. Sólo lo suficiente para realizar una parte del trabajo, para informar de una mejor cifra sobre el tiempo que va a llevar.
No es infalible. Usted todavía puede correr en problemas más adelante. Pero dar a los equipos entre 30 y 50 mil dólares, dejar que construyan algo y ver cuánto tiempo les lleva, puede contribuir en gran medida a reducir la variación de esa cifra inicial.
Puedes leer más sobre esta forma de planificar y las ventajas que aporta en Beyond Budgeting
La causa principal
Vivimos en un mundo de presupuestos anuales. Y, por desgracia, esto impulsa gran parte de la tensión y el drama en nuestro lugar de trabajo. En algunos aspectos, los presupuestos anuales son naturales (vivimos y seguimos el tiempo en ciclos anuales), pero en otros son terribles para la planificación, ya que un año es mucho tiempo en el mercado.
Si te encuentras con el cono de la incertidumbre, recuerda que el objetivo de la estimación de software es determinar si el proyecto es posible.
O como dice Steve McConnell:
El objetivo principal de la estimación de software no es predecir el resultado de un proyecto; es determinar si los objetivos de un proyecto son lo suficientemente realistas como para permitir que el proyecto sea controlado para cumplirlos.
-Steve McConnell, Software Estimation: Demystifying the Black Art