Los programadores de verdad no necesitan dormir

...Es una de las frases geniales con las que Rodolfo nos comenta el libro "Death March" de Ed Yourdon, y nos invita a identificar (igual que lo hacemos con los caminos críticos u otros elementos esenciales para controlar un proyecto) y a prevenir las “marchas de la muerte” en las que se convierten algunos proyectos.

Hace días que leí su post y me he descubierto a mi misma varias veces pensando en su texto y rememorando situaciones parecidas a las que él describe.

Creo que todos los que nos hemos participado en proyectos de ingeniería de software podemos identificar situaciones donde: “la gente muchas veces se siente desprotegida ante el fuego (o mas bien intereses) cruzado o luchas de poder, donde se considera que se debe poner un esfuerzo adicional para contrarrestar los problemas derivados de la falta de planificación, la falta de presupuesto, o la falta de calidad en los procesos”

En algunos casos, reconozco que he favorecido o permitido esas situaciones donde sabes que estás exigiendo a un equipo más de lo razonable, atribuyéndoles una responsabilidad sobre el éxito de un proyecto en el que la mayoría de las variables dependieron de otros.

Una vez, en un equipo negociamos las horas que cada uno necesitaba dormir. Diseñamos un plan desesperado donde uno de los elementos a considerar era la variedad en esa necesidad Fisiológica. Luego, los que dormían más, compensaban de otra forma, menos agresiva para ellos, al resto del equipo. Hubo que echar mano de ideas muy extravaganntes para sacar aquello adelante. Se consiguió y recuerdo aquel proyecto como una experiencia apasionante (sé que ellos también), pero me he recriminado muchas veces utilizar la pasión de un equipo para suplir carencias en otros puntos de la cadena de creación de un proyecto.

Después de aquello siempre he defendido no segmentar tanto la venta, conceptualización, definición, diseño, planificación y ejecución de un proyecto en función de cómo está organizada una empresa. El que vende un proyecto, es el que ha entendido al cliente y es el mejor para darle forma y seguramente el que va a ser capaz de gestionarlo para que el producto o servicio resultante se parezca lo más posible a lo que el cliente esperaba. 

Está claro que necesitamos especialistas en diferentes disciplinas en cada una de las fases, pero para mi, el director del proyecto es alguien que ha de estar de principio a fin, asumiendo la venta y responsabilizándose de la producción. Lo contrario genera brechas peligrosas, segmentación de responsabilidades y conflictos de intereses (si al comercial le premian el volumen de ventas y al jefe de proyectos la rentabilidad, estamos condenamos a enfrentarnos y a sufrir).

Luego, los equipos están para sacar el trabajo adelante, y la mayoría de veces con entusiasmo y compromiso. Pero la “mentalidad de soldados de la marina” sirve para excepciones, no como regla. Planificar proyectos asumiendo estas dinámicas además de ineficaz es irrespetuoso.

Rodolfo apunta dos buenas prácticas para erradicar las "marchas de la muerte": Proyectos basados en prototipos donde el esfuerzo se concentre en aquello realmente esencial y rápido que aporte valor añadido y usar metodologías ágiles al servicio del proyecto y no al revés.