En esta vida no puedes tenerlo todo. Lo mismo pasa en el desarrollo de software. No se pueden tener todas las funcionalidades que quieras, muy rápidamente y casi sin coste y encima esperar que el programa funcione.

Esta dicotomía se conoce como el triángulo de la gestión de proyectos. Esta simple figura ilustra muy bien dos condicionantes que conviene tener muy presentes al empezar cualquier desarrollo software:

  1. La calidad del software depende del alcance (scope en inglés) del proyecto, su presupuesto y los plazos (deadline) del desarrollo
  2. Puedes buscar un equilibrio entre las diferentes restricciones. Teniendo en cuenta que cualquier cambio en una de ellas obliga a ajustar las otras para compensar si no quieres que la calidad se vea afectada.
Triangulo de la gestión de proyectos software

El triángulo que conviene tener siempre presente en toda gestión de proyectos software

Por ejemplo, si el tiempo es la restricción más importante, puedes acelerar el proyecto reduciendo el número de funcionalidades del proyecto o incrementando el presupuesto (hasta cierto punto, recordad las leyes fundamentales de la programación, hay un momento que añadir más gente no acelera el proyecto). Si necesitas muchas funcionalidades entonces el software será más caro y necesitará más tiempo para completarse.

La verdad es que a mí me parece muy de sentido común pero, ¡la de veces que hemos visto proyectos totalmente irreales!. Muchas veces porque la persona que tiene que “vender” el proyecto al cliente no es que lo tiene que desarrollar después con lo que va a aceptar plazos y costes imposibles de cumplir si consigue cerrar la venta. Todo el qué ha trabajado en grandes consultoras sabe de lo que hablo 🙂

Y en esos casos pues pasa lo que pasa:

o este otro ejemplo:

Hay modelos más complejos y variaciones de este triángulo (ej, el modelo estrella con dos triángulos superpuestos del PMBOK) pero si tenemos éste claro ya conseguiremos mejorar la gran mayoría de problemas en el desarrollo de software.

Un problema relacionado (pero que ya dejamos para otro día) es que aún cuando queremos hacerlo bien, somos muy malos estimando la complejidad de un proyecto, normalmente subestimándola. Por ejemplo, en mis tiempos de programador, recuerdo que cuando me tocaba estimar la complejidad (en tiempo) de nuevas funcionalidades a añadir al sistema interno que estábamos desarrollando, lo hacía lo mejor que podía y al final siempre multiplicaba el resultado por dos. A mi me funcionaba aunque no tiene ningún fundamento científico. La explicación intuitiva (¡a la que llegué a posteriori!) era que mi estimación inicial no tenía en cuenta el número de interrupciones y “fuegos” que tendría durante el desarrollo de la funcionalidad con lo que necesitaba un margen para acomodar ese tiempo perdido.

Imagen de cabecera por Jo Szczepanska on Unsplash