¿Qué es una marcha de la muerte?
Cultura de ingeniería y práctica de software
Una marcha de la muerte es un proyecto de software cuyo calendario, presupuesto, dotación de personal o alcance es tan poco realista que las horas extra sostenidas y un alto riesgo de fracaso quedan incorporados al plan desde el principio. Va más allá de una época de mucho trabajo o de un esfuerzo heroico para cumplir un plazo. El término se aplica a proyectos en los que las probabilidades son malas desde el inicio, la presión es constante y se espera que el equipo sobreviva a base de sacrificio en lugar de una planificación sólida.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
No todo proyecto estresante es una marcha de la muerte. Los equipos a veces atraviesan un mes difícil, responden a una emergencia real o trabajan duro para cumplir una fecha exigente pero alcanzable. Una marcha de la muerte es diferente porque la imposibilidad es estructural. Los números nunca cuadraron, y se espera que todos finjan lo contrario.
En la cultura del software, la expresión captura un patrón tristemente familiar. El alcance es amplio, el tiempo es escaso, el equipo es reducido, las promesas ya son públicas y la respuesta a cada advertencia es alguna variante de "esforzaos más". Las noches y los fines de semana dejan de ser una medida temporal y se convierten en el modelo de trabajo habitual.
A veces estos proyectos sí se entregan. Aun así, el precio suele pagarse en forma de defectos, rotación de personal, atajos frágiles y un equipo que ha aprendido la lección equivocada sobre lo que significa el profesionalismo.
Por qué importa
La marcha de la muerte importa porque los planes imposibles rara vez se quedan en la diapositiva de planificación. Se convierten en condiciones de trabajo. Los ingenieros pierden tiempo de recuperación, los responsables se convierten en mensajeros de la fantasía, las pruebas se comprimen y las decisiones difíciles se sustituyen por pensamiento mágico. El sistema puede llegar a la meta a duras penas, pero la organización se enseña a sí misma que el esfuerzo extremo es un sustituto del realismo.
El término también importa porque desinfla el glamur que rodea al sufrimiento. Algunos entornos laborales todavía admiran el proyecto que "requirió a todos, todo el fin de semana, todo el trimestre". Esa admiración puede ocultar un fracaso de gestión. Un equipo no debería necesitar el agotamiento crónico para que un plan funcione.
Para quienes no son especialistas, marcha de la muerte es un término cultural útil porque explica por qué los equipos de software pueden parecer a la vez heroicos y alarmados. Con frecuencia se les pide que compensen, a título personal, una estructura de proyecto que debería haberse cuestionado mucho antes.
Cómo funciona
El origen del término
Edward Yourdon popularizó "death march" en la gestión de software durante los años noventa, aplicándolo a proyectos cuyos calendarios o presupuestos eran desproporcionadamente más ambiciosos de lo que cabía esperar razonablemente. También los describió como proyectos cuya probabilidad de fracaso ya había cruzado hacia un territorio incómodo.
Ese enfoque fue importante porque desplazó la conversación desde la presión habitual de los plazos hacia algo más específico: una misión que parece audaz desde lejos pero que operativamente se construye sobre la negación de la realidad.
Cómo los proyectos se convierten en marchas de la muerte
Por lo general, ningún evento único las crea. Se hace una promesa de ventas pronto. Un patrocinador quiere una fecha llamativa. Un responsable joven es optimista. Un fundador cree que la intensidad compensará la falta de estructura. Un cambio de mercado o una regulación genera presión real y el equipo se niega a reducir el alcance. Pronto el calendario se vuelve sagrado y todo lo demás empieza a doblarse a su alrededor.
La política suele hacer el resto. Nadie quiere ser quien diga que el plan es una fantasía, especialmente después de que una fecha de lanzamiento haya escapado hacia presentaciones, llamadas con clientes o expectativas del consejo. Así, la organización deja de preguntarse si el proyecto está bien estructurado y empieza a preguntarse cuánto esfuerzo adicional puede absorber la gente.
Ahí es donde la vieja advertencia de Brooks cobra relevancia. Añadir más personas a un proyecto de software retrasado no lo salva de forma fiable. La comunicación, la incorporación y la coordinación tienen su propia inercia. Bajo presión, las organizaciones suelen descubrirlo por las malas.
Cómo se vive una marcha de la muerte desde dentro
En el equipo, los síntomas son reconocibles. La fecha de entrega se discute antes de que se entienda el trabajo. Cada funcionalidad es urgente. Las pruebas se convierten en "ya lo arreglaremos después". Nadie puede explicar qué se ha recortado porque nada está recortado oficialmente. Las horas extra dejan de parecer excepcionales. Los fines de semana pasan a formar parte de la estimación aunque nadie lo escriba.
El ritmo emocional también es característico. Una semana trae determinación sombría, la siguiente un optimismo frágil, la siguiente reproches, y luego una nueva oleada de discursos sobre el compromiso. Los pequeños logros se celebran como prueba de que el plan sigue vivo. Las advertencias se reencuadran como negatividad.
Y como todos están cansados, el proyecto empieza a producir exactamente lo que producen los equipos agotados: errores evitables, soluciones superficiales, documentación escasa y mayor dependencia de quien todavía parece capaz de mantener todo el conjunto en su cabeza.
Cómo distinguir un proyecto difícil de una marcha de la muerte
Un proyecto difícil todavía tiene un camino viable. El equipo puede identificar las concesiones, reducir el alcance, proteger la calidad donde importa y recuperarse tras el período intenso. Una marcha de la muerte suele carecer de esa honestidad. Trata la presión permanente como algo normal y las restricciones de planificación como algo opcional.
Una respuesta acotada a una crisis puede requerir un esfuerzo extraordinario. También puede hacerlo un lanzamiento genuinamente importante en una ventana estrecha. Esos casos no son automáticamente marchas de la muerte si las restricciones son reales, las concesiones son explícitas y el ritmo es temporal. La pregunta clave es si la organización pide un empuje intenso a través de la realidad o un prolongado acto colectivo de autoengaño.
Ejemplos
Una empresa promete a un cliente empresarial una funcionalidad importante para finales de trimestre antes de que siquiera haya comenzado el trabajo de descubrimiento. El equipo de ingeniería plantea sus dudas, pero la fecha ya figura en una diapositiva y en las notas de la llamada de ventas. El alcance nunca se reduce. Al equipo simplemente se le dice que sea "pragmático" y que "trabaje de forma inteligente", lo que pronto se traduce en noches y fines de semana.
Un plazo regulatorio es real e innegociable, pero la dirección rechaza hacer una selección de prioridades. En lugar de identificar el conjunto mínimo que cumpla los requisitos, cada elemento de la lista de deseos se marca como crítico. Los desarrolladores son convocados a reuniones de estado diarias, el control de calidad se comprime al final y todo el plan asume en silencio el agotamiento del equipo.
Una startup con financiación decide lanzarse en un nuevo mercado, reescribir parte de la plataforma, añadir un nuevo flujo de facturación e impresionar a los inversores con una fecha llamativa. Durante un mes la energía parece electrizante. Al tercer mes, la gente está quemándose en silencio y el producto está lleno de costuras apresuradas.
Malentendidos frecuentes
Un malentendido es que marcha de la muerte simplemente significa "ambicioso". La ambición es normal. Marcha de la muerte significa que el proyecto está organizado en torno a probabilidades que no tienen sentido.
Otro es que si el equipo está suficientemente comprometido, el plan se vuelve viable. El compromiso puede ayudar a un buen plan. No deroga los costes de comunicación, las curvas de aprendizaje ni el cansancio humano.
Un tercero es que entregar el proyecto demuestra que la presión estaba justificada. A veces los equipos arrastran esos proyectos hasta la meta. Eso no significa que la estructura fuera saludable. La factura oculta puede aparecer más tarde en forma de defectos, rotación, problemas para los clientes o una hoja de ruta vaciada.
Un cuarto es que solo las grandes corporaciones hacen esto. Las startups, las agencias, las consultoras y los proyectos de código abierto pueden crear condiciones de marcha de la muerte por razones distintas.
Un quinto es que la expresión debería usarse para cualquier quincena de mucho trabajo. El uso excesivo hace que el término pierda su utilidad. Está pensado para la presión estructuralmente insostenible, no para cualquier bache.
Riesgos y límites
El límite más importante es el que separa la intensidad de la imposibilidad. Algunos trabajos requieren genuinamente un empuje corto e intenso. Las emergencias en producción ocurren. Existen ventanas regulatorias. Los lanzamientos importantes pueden ser exigentes. Si la presión está acotada, el alcance es claro y la recuperación es real, eso es simplemente trabajo duro.
El peligro comienza cuando la organización empieza a tratar esa postura como un estilo de gestión permanente. Entonces lo excepcional se vuelve normal y la vida personal del equipo se convierte en un insumo oculto del proyecto.
También existe un riesgo retórico. Llamar marcha de la muerte a todo puede convertirse en una forma de dramatizar dificultades ordinarias. La expresión debe conservar su fuerza. Hay que reservarla para proyectos en los que el propio plan es el que causa el daño.
Qué hacer a continuación
Actuar antes de que llegue la crisis. Cuando se propone una fecha, hay que poner sobre la misma página el alcance, la dotación de personal, los riesgos y las dependencias. Si los números no encajan, no conviene externalizar el desajuste a las horas extra futuras. Hay que arreglar el plan mientras sigue siendo un plan.
A continuación, practicar la selección de prioridades. Un proyecto bajo presión solo se vuelve manejable cuando los responsables pueden decir qué importa más, qué puede moverse, qué puede esperar y qué nivel de calidad no puede negociarse. Si todo es crítico, nada ha sido priorizado.
Luego, prestar atención a las señales humanas, no solo al diagrama de Gantt. El trabajo en fin de semana, las bajas por enfermedad, los picos de defectos, el aumento de la fricción en los traspasos y una caída brusca en la calidad de las revisiones son señales de que el proyecto está consumiendo al equipo de forma poco saludable.
Por último, dar a los responsables permiso para detener la fantasía. A veces el acto valiente no es motivar al equipo para el siguiente sprint. A veces es renegociar la fecha, recortar el alcance o cancelar el proyecto antes de que consuma a más personas y deje menos valor detrás.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Una marcha de la muerte es simplemente otro nombre para el trabajo duro?
No. El trabajo duro puede ser temporal, realista y bien dirigido. Una marcha de la muerte es presión construida sobre supuestos poco realistas y sacrificio sostenido.
¿Puede recuperarse un proyecto en marcha de la muerte?
Sí, pero generalmente solo si la dirección cambia la forma del proyecto recortando el alcance, reajustando las fechas, mejorando la dotación de personal o deteniéndolo por completo.
¿Las startups son por naturaleza marchas de la muerte?
No de forma inherente. Las startups suelen trabajar bajo incertidumbre y presión, pero se convierten en marchas de la muerte cuando el optimismo reemplaza a la planificación y la intensidad se convierte en el principal modelo de funcionamiento.
¿Qué señales de advertencia aparecen pronto?
Las fechas aparecen antes del descubrimiento, el alcance no deja de crecer, todo es urgente, la revisión y las pruebas se comprimen, y las horas extra se tratan como algo normal antes de que el equipo haya llegado siquiera a la parte más difícil.
¿Añadir más personas tarde ayuda?
A veces ayuda en los márgenes, pero con frecuencia añade costes de coordinación y confusión. La incorporación tardía de personal rara vez es un rescate milagroso.
¿Qué deben hacer los responsables si la fecha realmente no puede moverse?
Recortar el alcance de forma decidida, proteger las verificaciones de calidad críticas, hacer explícitas las concesiones y planificar tiempo de recuperación. Si la restricción es real, la honestidad también debe serlo.
¿Deberían los equipos cancelar alguna vez un proyecto?
Sí. Si el objetivo ya no justifica el daño, o las probabilidades son claramente imposibles, detenerlo puede ser la decisión responsable.
Fuentes
Death March Projects (American Programmer via UC Irvine). Yourdon's definition of death march projects, their excessive ambition, and their human cost.
The Mythical Man-Month (University of Michigan). Primary text access to Brooks's law for the discussion of why adding people late often fails to save impossible projects.