Pero existe un enfoque para analizar los riesgos que me resulta muy práctico y valioso. Muchos de los riesgos de un proyecto convergen en un hecho concreto: no se finaliza el proyecto a tiempo. Puede ser que las personas no estaban capacitadas como se esperaba, que la funcionalidad a desarrollar fue más difícil de lo esperado, que componentes externos se entregaron tarde o cosas por el estilo. Pero todo termina en que el equipo de proyecto dijo que iba a tardar 3 meses, y en la noche del último día se da cuenta que no termino. Ese es el gran resumen de los riesgos de un proyecto de software.
Este concepto está muy bien presentado en el libro Waltzing with Bears: Managing Risk on Software Projects de Tom DeMarco y Timothy Lister. Es lo que ellos llaman la cuantificación de la incertidumbre. Y ponen un ejemplo muy claro. Supongan que llamamos a un consultor para que analice nuestro proyecto y nos dice:
“Escucha, simplemente no hay chance de terminar esto antes de principio de año – cero. La fecha más probable para entregar un producto aceptable es inicio de abril próximo. Aún esta fecha no es tan segura. Probablemente no quieras comunicar ninguna fecha antes del primero de mayo. Al menos con una fecha en mayo o más tarde tienes una probabilidad de cumplir mejor que cincuenta-cincuenta. Si quieres una fecha donde no tengas posibilidad de entregar tarde, vas a tener que irte hasta fines de diciembre próximo.”
Representando la situación gráficamente, obtenemos un diagrama como este:
Este es un diagrama de riesgo donde el area bajo la curva representa la probabilidad acumulada de finalizar en una fecha dada. Si un tercio del area total se acumula a la izquierda del 1 de abril, la probabilidad de terminar antes de esa fecha es 0.33. El area total bajo la curva es 1.
Este es un gráfico revelador porque asocia el riesgo a las fechas. Uno puede observar como aumenta el riesgo a medida que las fechas son mas agresivas. Esto parece muy natural pero no lo es tan comun encontrar gente que actúe en consecuencia. Siempre vemos que la persona que pide la fecha de estimación intenta obtener la fecha más cercana posible, como si esto no incrementara el riesgo o como si las consecuencias no lo afectaran. Pero esa no es la realidad. En nuestro caso, si la persona con poder de decisión sobre el proyecto define que la fecha a comunicar será el 1 de abril, entonces debe estar preparado para entregar tarde, porque existe el 66 % de probabilidad que así suceda. ¿Está realmente dispuesto a afrontar ese riesgo?
DeMarco y Lister utilizan el gráfico para explicar un aspecto repetido hasta el cansancio en los proyectos de software:
“Una queja común que managers comparten con nosotros es que 'la fecha más temprana mencionada automaticamente se transforma en la fecha de entrega'. Publicar el hallazgo del consultor que 'no hay posibilidad de entregar antes de principio de año' puede ponerte en una posición donde el 1 de enero es entonces fijada con concreto como la fecha de entrega. Pero en el diagrama de riesgo, el area bajo la curva a la izquierda del 1 de enero es esencialmente cero. Esto dice que la posibilidad de terminar antes de la fecha de entrega es nula. La patología de definir una fecha de entrega como la fecha más temprana mencionada garantiza esencialmente que la fecha no se cumplirá.”
