project-management - temporada - death march to the parallel world rhapsody animeyt

Características de un proyecto de Death March (9)

Desafortunadamente, también es un procedimiento operativo estándar en algunas empresas de consultoría que algunos ingenieros calificados estiman las horas hombre reales requeridas para un proyecto, luego tienen un gerente HALVE que en la oferta final para ganar la oferta para el proyecto, asegurando así una dolorosa marcha de la muerte para el equipo.

En el desarrollo de software, un proyecto de Marcha de la Muerte generalmente se refiere a un proyecto que tiene una fecha de lanzamiento fija con funcionalidad fija y recursos fijos, lo que genera una gran demanda por parte de la gerencia de que los desarrolladores trabajen largas horas y fines de semana.

¿Qué crees que es un proyecto de la marcha de la muerte y cómo se produce?

Desde mi experiencia algo limitada, diría que un proyecto de marcha de la muerte es cualquier proyecto que da como resultado que los desarrolladores trabajen horas locas durante un largo período de tiempo. Estos desarrolladores generalmente se agotan antes de la fecha límite.

He visto un par de formas en que ocurren estas situaciones:

Overoptimismo sobre el estado del proyecto.
Presión de tiempo externa al proyecto.
Otros miembros del equipo se relajan, lo que hace que un par de desarrolladores ocupen toda su carga de trabajo.
Cualquier otra patología general de desarrollo de software que pueda imaginar (horarios poco realistas, alcance lento, mala administración, etc.)

Tendría que decir que el número uno es el mejor indicador para mí, porque generalmente es la causa de todos los otros factores. Por ejemplo: el exceso de optimismo lleva a reclamos exagerados del cliente, una voluntad de aceptar el alcance, la pereza, etc.

También creo que vale la pena observar que esto no siempre es culpa de la gerencia, el equipo de diseño o cualquier otra parte que no esté directamente involucrada en la programación. Los programadores a menudo sobreestiman sus capacidades y también pueden escribir código defectuoso que vuelve a establecer un proyecto.

Otro sello distintivo de un deathmarch es que cada vez más personas abandonan el barco a medida que el proyecto se aproxima a la "fecha límite".

Por lo general, se produce a través de una mala planificación y comunicación.

Por lo general, se trata de que la empresa se comprometa con la funcionalidad y los requisitos del cliente para los que creen que el sistema / grupo de desarrollo puede terminar en x cantidad de tiempo ... sin pedir un tiempo estimado, o incluso repasar los requisitos que reunieron para el cliente! Y como es un proyecto tan rentable, los altos mandos de los sistemas lo aceptan porque "para la empresa en general" es un buen generador de ingresos. He estado en alrededor de 4 a 5 marchas de la muerte, que generalmente duran de una a dos semanas. Mi última marca de muerte duró aproximadamente 2 meses y consistió en 9-14 horas de trabajo por día. :( no es divertido.

Wikipedia tenía una definición bastante buena:

En las industrias de desarrollo de software e ingeniería de software, una marcha de la muerte es un disfemismo para un proyecto que está destinado a fallar. Por lo general, es el resultado de expectativas poco realistas o excesivamente optimistas en la programación, el alcance de las características o ambos, y a menudo incluye la falta de documentación adecuada o cualquier tipo de capacitación relevante. El conocimiento de la naturaleza condenada del proyecto pesa mucho en la psique de sus participantes, como si estuvieran mirando impotentes al equipo mientras avanza hacia el mar. A menudo, la marcha de la muerte implicará intentos desesperados de corregir el curso del proyecto pidiendo a los miembros del equipo que trabajen horas especialmente agotadoras los fines de semana (a veces con la cara seria) o intentando "arrojar (suficientes) cuerpos al problema" con resultados variados, a menudo causando agotamiento.
texto alternativo http://www.weyrich.com/bookcovers/death_march.gif
El término " marcha de la muerte " en este contexto se discutió extensamente en el libro de Edward Yourdon Death March: la guía completa del desarrollador de software para sobrevivir a proyectos "Misión imposible" (ISBN 0130146595),

Creo que los "Deathmarches" provienen de personas no técnicas que deciden fechas límite arbitrarias para proyectos / características sin ningún aporte de los desarrolladores en términos de estimaciones. Esto crea plazos irrazonables y, si lo combina con requisitos poco estrictos por parte del cliente, tiene usted mismo un Deathmarch.

Al preguntar al equipo qué tan avanzado piensan el proyecto, un indicador bastante importante es cuando el gerente del proyecto estima que se ha completado el 70%, el analista de negocios cree que se completó un 45-55% y los desarrolladores dicen que se completó un 5-10%.

Esa es una señal de advertencia allí mismo.

Creo que pueden surgir debido a la mala planificación y estimación, a las demandas irrazonables por parte de las empresas, a la implosión del equipo, al alcance y al deslizamiento de las características con plazos de entrega ajustados, y al viejo ser una idea estúpida en primer lugar .

Los proyectos de Deathmarch subrayan la irrelevancia de la organización de TI que permite que esto suceda. Si existe la sensación de que el calendario y el presupuesto prevalecen sobre la funcionalidad, las opciones técnicas o el valor comercial, entonces la administración de TI se ha vuelto irrelevante. Los administradores de TI están ahí solo para supervisar el centro de costos al que informan los programadores.

Si el proyecto no se enfoca realmente en el valor del negocio, avanza hasta el final cuando debe ser cancelado ("Descopado" o "Repriorizado").

La única forma en que esto puede suceder es que la administración de TI (a) podría tener una contribución útil pero el negocio no la valora o (b) no tiene ninguna pista.

Una marcha de la muerte significa que el equipo no está construyendo algo de valor, sino que está construyendo algo que se ajusta al costo y al cronograma.

En general diría que un Deathmarch es realmente una falla sistémica ... por lo que no es solo una cosa que crea un Deathmarch, sino una confluencia de eventos .

Diría que, además de la mala gestión general del proyecto (programación poco realista, errores de gestión, etc., etc.), los proyectos de Deathmarch a menudo implican una nueva tecnología que se está tratando como una especie de "bala de plata". A menudo se combina con una capacitación deficiente y una falta de comprensión.

Sin embargo, en todos los casos, un gran número del equipo necesita saber que el proyecto está condenado a calificar verdaderamente para el título "Deathmarch".