Un objetivo de negocio no es necesariamente una estimación software

En el mundo de la planificación y gestión de proyectos software este tema es un clásico. Asunto tan clásico y repetido como desconocido, aun siendo de una obviedad insultante: un deseo de negocio (por ejemplo, “-Queremos la versión 2.7 en mayo-”) no es necesariamente una estimación software.
Estoy seguro, y nadie puede discutirlo, que la gente que rige y decide los objetivos de negocio tienen grandes e importantes razones para establecer objetivos de negocio independientemente de las estimaciones software. Pero un objetivo, un deseo, una obligación, no implica necesariamente que sea algo alcanzable, realista y realizable.
Entre los muchos errores a la hora de gestionar proyectos este debe estar (y de hecho lo está, véase aquello de errores clásicos en el desarrollo software) entre los primeros y entre los más peligrosos.
Y el problema viene cuando un objetivo de negocio “deseable” se convierte en un compromiso, en la promesa de entregar cierta funcionalidad definida, además con un determinado nivel de calidad, unos recursos económicos limitados, y en una fecha determinada… que es imposible.
Todo el mundo con potestad para convertir objetivos e negocio en estimaciones debería saber que en un proyecto se pueden fijar sólo dos de tres dimensiones: presupuesto, alcance y tiempo (el llamado triangulo de hierro).
Si se fija el presupuesto y el alcance, debe dejar que sea el equipo de desarrollo quien diga cuánto tiempo. Si se fija tiempo y alcance, se debe ser flexible en presupuesto. Y si se fija tiempo y presupuesto, debe ser flexible en el alcance.
Si cierras compromisos de entrega de funcionalidad en fechas imposibles y con recursos económicos invariables la cosa explotará por algún lado, siempre pasa, es inevitable.
Normalmente se entregará un desarrollo con menos funcionalidad de la esperada, desarrollado por gente quemada, que por las prisas y de más habrá creado software con mínima calidad. Que normalmente costará mucho más dinero que si se hubiese hecho en el tiempo que razonablemente se necesitaba para ello.
Sucederá que, como hablamos en déjate de probar (o de diseñar, refactorizar, etc.) y ponte a programar, que no tenemos tiempo, al ver que el proyecto se va a retrasar n meses, comenzarán a saltarse y dejarse de hacer las tareas típicas y básicas de, llamemos, calidad software. Se saltarán las pruebas, las buenas prácticas de control de versiones, los mínimos en calidad a la hora de programar, aparecerán los pasos a producción “en caliente”, etc., cosas que al final habrá que volver a hacer, y que el sobre coste de hacerlas en el momento no adecuado está estimado que subre entre un por 10 y un por 100.
Y serán estas, y algunas otras, las razones por las que, como hablamos en ¿Qué es mejor? ¿Sobrestimar (decir tiempo de más) un proyecto o subestimarlo (decir tiempo de menos)?, los sobrecostes de un proyecto que se subestima crecen exponencialmente en función de lo grande que sea el recorte de tiempo que se le haya dado.