Pages Menu
Categories Menu

Posted by on Feb 3, 2016 in General | 1 comment

¿Qué es hacer un “Death March”?

Un “death march” vendría a ser algo así como una marcha fúnebre, o marchando hacia la muerte, camino al infierno. Concretamente, en inglés, es una marcha de prisioneros de guerra, con la intención de ejecutarlos o torturarlos.

Y en el mundo del software, es una manera, ya antigua, de llamar a un proyecto que está destinado al fracaso, es un proyecto “death march”. Y por ello, en vez de prisioneros, los presentes allí, a los que les tocará trabajar “de sol a sol” en el proyecto, marchan juntos durante meses o años hacia la muerte (del proyecto, normalmente).

Este post viene a raíz de aquel otro del martes pasado en el que te contaba la pérdida de Ed Yourdon, que no sé si fue quien hizo uso del término por primera vez, aplicándolo a proyectos software, pero sí que desde luego fue el que le dio popularidad, en su famoso libro Death March, en el que reflexionaba y trataba las distintas causas por las que se acaba generando un “death march”, así como diferentes tipologías, desde los “death march” kamikaze, a los suicida, a los misión imposible y los que tienen “mala pinta” .

Por lo general, un “death march” comienza con expectativas poco realistas o demasiado optimistas, pretensiones demasiado complicadas, personal poco preparado, tecnología desconocida, etc., y, en general, con una arranque de proyecto en el que, en silencio, nadie espera que aquello acabe bien.

A menudo, un “death march” implica y se caracteriza por intentos desesperados para evitar el desastre anunciado, concretamente, intentos basados en sobre esfuerzos por parte de los miembros del equipo, del tipo a trabajar muchas horas, fines de semana, etc., e, incluso, del tipo a añadir gente , de manera desesperada, cuando ya va el proyecto retrasado, ya sabes, aquello de “Añadir gente a un proyecto software con retraso hace que se retrase más”.

Más concretamente, un proyecto “death march” es uno en el que “los parámetros del proyecto”, que son calendario, presupuesto, equipo y funcionalidad, superan la norma del “al menos el 50%”, que significa que uno o más de esas restricciones han sido impuestas por debajo del 50% del 100% ideal:

– El calendario se ha comprimido a menos de la mitad de la cantidad estimada como necesaria.

– El equipo se ha reducido a menos de la mitad del número que normalmente se debería asignar a un proyecto de este tamaño y alcance.

– El presupuesto se han reducido a la mitad.

– La funcionalidad, características, requisitos u otros aspectos técnicos del proyecto son el doble de lo que sería en circunstancias normales.

La consecuencia inmediata de dichas limitaciones, en la mayoría de las organizaciones, que decía Yourdon, implica pedir al equipo de proyecto trabajar el doble, acabando, finalmente, en una muerte anunciada.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. Me ha gustado el artículo y me ha hecho gracia la expresión “Death March”. Hay proyectos que nacen así pero los que realizan la penosa marcha son los participantes del mismo. Stress, ansiedad, dolores de cabeza, angustia, fines de semana con trabajos forzados. Y así durante meses hasta la explosión del proyecto o de los integrantes que se van sumando a bajas médicas o deserciones.
    Son los gajes de este sufrido oficio, mal pagados y carne de cañón, cuyos supervivientes de la larga marcha por el valle de la muerte, una vez finalizado el proyecto, son desasignados, remitidos a la “playa” o enviados a la mayor empresa nacional: el INEM.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This