Fracasó. ¿Por qué?

Han pasado seis meses y el proyecto fracasó. Escribe cada razón como si ya hubiera ocurrido.

Confiamos en el entorno de pruebas del proveedor de pagos y nunca probamos los límites de producción. El tráfico del día del lanzamiento tumbó el proceso de pago.
Solo Priya entendía los scripts de migración de datos. Se fue de baja el tercer mes y todo se paralizó.
Legal revisó los términos del servicio dos semanas antes del lanzamiento y tuvimos que rehacer el flujo de consentimiento.
Señales de alerta temprana

¿Qué notaríamos primero si esto empezara a ocurrir?

Los tickets de soporte del proveedor tardan más de dos días en recibir respuesta.
Siempre se etiqueta a la misma persona en todas las revisiones de pull requests de la migración.
Aparecen tickets nuevos a mitad de sprint con 'petición rápida de ventas' en la descripción.
Cómo lo evitamos

¿Qué podemos hacer ahora para evitar que esto ocurra?

Hacer una prueba de carga contra el entorno de producción del proveedor en el segundo sprint, antes de construir nada encima.
Poner a alguien a trabajar con Priya en los scripts de migración y documentar el runbook antes de final de mes.
Reservar una revisión legal del flujo de consentimiento durante el diseño, no después de desarrollarlo.
Responsables y próximos pasos

¿Quién se encarga de cada riesgo principal y para cuándo?

Marco se encarga de la prueba de carga del proveedor, para el final del segundo sprint.
Trabajaré con Priya en la migración y publicaremos el runbook antes del día 15.
Dana reservará la revisión legal del flujo de consentimiento antes de la aprobación del diseño el próximo viernes.

¿Qué es una retrospectiva pre-mortem?

Un pre-mortem es una sesión de análisis de riesgos que se realiza al arrancar un proyecto, antes de cerrar el alcance, las fechas y el presupuesto. El equipo se sitúa en un futuro concreto: han pasado seis meses y el proyecto ha fracasado. Después, cada persona escribe por qué fracasó, como si el fracaso ya hubiera ocurrido. El psicólogo Gary Klein desarrolló la técnica y la describió en su artículo de 2007 en Harvard Business Review, "Performing a Project Premortem". Se basa en investigaciones sobre la "retrospección prospectiva" (prospective hindsight), que demostraron que imaginar que un acontecimiento ya ha sucedido ayuda a las personas a encontrar razones más concretas que lo expliquen. La clave está en el enfoque. Si le preguntas a un equipo "¿qué podría salir mal?", obtendrás respuestas educadas y genéricas como "cambios de alcance" o "problemas de comunicación". Si preguntas "¿por qué fracasó?", la gente nombra causas reales: la API del proveedor a la que nunca se le hicieron pruebas de carga, la parte interesada a la que nadie consultó, el único ingeniero que concentraba todo el conocimiento. Dar el fracaso por hecho también permite expresar dudas que, en un arranque lleno de optimismo, sonarían negativas o desleales. Esta plantilla de pre-mortem recorre cuatro pasos en TeamRetro. Primero, se enumeran las razones por las que fracasó el proyecto. Después, se identifican las señales de alerta temprana, se acuerdan medidas de prevención y, para terminar, se asigna a cada riesgo principal un responsable y una fecha. Este último paso es el más importante. Un riesgo sin responsable ni fecha límite suele olvidarse antes de que acabe la primera semana. Usa ideas anónimas para que la jerarquía no condicione lo que escribe cada persona y, en equipos distribuidos, recoge las ideas de forma asíncrona durante un día y reuníos solo para votar y asignar responsables.

Formato de retrospectiva pre-mortem

Fracasó. ¿Por qué?

Han pasado seis meses y el proyecto fracasó. Escribe cada razón como si ya hubiera ocurrido.

Esta columna es el núcleo del pre-mortem. Plantea bien la escena: el proyecto ha terminado, ha fracasado y todo el mundo lo sabe. Pide a las personas que escriban en pasado ("No llegamos al lanzamiento porque..."), ya que este enfoque genera causas más concretas que especular sobre lo que podría salir mal. Mantén las ideas anónimas para que las voces con más jerarquía no condicionen al resto. Dedica 8–10 minutos a escribir en silencio, anima a poner una sola razón por idea y, después, agrupa las ideas similares y votad para identificar los riesgos principales que pasarán a las siguientes columnas.

Señales de alerta temprana

¿Qué notaríamos primero si esto empezara a ocurrir?

Las señales de alerta temprana convierten miedos difusos en cosas que el equipo puede vigilar. Para cada riesgo principal de la primera columna, pregunta cuál sería la primera señal observable: una métrica, un hito incumplido, un patrón en las reuniones diarias. Insiste en señales específicas y medibles. "Baja la moral" es difícil de seguir. "Dos sprints seguidos con más de un 30% de trabajo arrastrado" es fácil de detectar. Estas señales serán los indicadores que vigilarán los responsables de cada riesgo.

Cómo lo evitamos

¿Qué podemos hacer ahora para evitar que esto ocurra?

Aquí el equipo pasa de la preocupación a la acción. Céntrate solo en los riesgos más votados, normalmente entre tres y cinco. Para cada uno, pregunta qué puede hacer el equipo esta semana o este mes para reducir la probabilidad o el impacto. Da prioridad a pasos pequeños y concretos frente a grandes cambios de proceso. Si una idea de prevención necesita aprobación o presupuesto, anota a quién hay que pedírselo. Mantén un tono práctico: el objetivo es una lista más corta de acciones que la gente vaya a hacer de verdad.

Responsables y próximos pasos

¿Quién se encarga de cada riesgo principal y para cuándo?

Esta columna es la razón de ser de toda la sesión. Cada riesgo principal necesita un responsable con nombre y una fecha; si no, los miedos recogidos hoy se diluyen antes de que acabe la primera semana. Los responsables no tienen que resolver el riesgo solos: se encargan de vigilar las señales de alerta y de asegurarse de que la medida de prevención se lleve a cabo. Registra cada uno como acción en TeamRetro para que se arrastre a futuras retrospectivas y programa una revisión breve en el primer hito para ver cómo avanza.

Cuándo utilizar este estudio retrospectivo

  • Al arrancar un nuevo proyecto, lanzamiento de producto o iniciativa importante, antes de cerrar el alcance, las fechas y el presupuesto.
  • Antes de un hito crítico, como una migración, una puesta en producción o la firma de un contrato, en el que una sorpresa de última hora saldría cara.
  • Cuando un equipo se muestra especialmente optimista con un plan y las personas más calladas pueden estar guardándose sus dudas.
  • Al empezar a trabajar con un nuevo proveedor, socio o grupo multifuncional cuyas dependencias todavía no se conocen bien.
  • Al inicio de un nuevo trimestre o program increment, para poner a prueba el plan antes de que el equipo se comprometa con él.

Preguntas sugeridas para romper el hielo

  • ¿Cuál es el plan que más recuerdas que saliera mal, en el trabajo o en la vida, y cuál fue la primera señal de alerta?
  • Si este proyecto fuera una película, ¿de qué género sería la versión en la que fracasa?

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

  • Haz el pre-mortem al arrancar el proyecto, antes de cerrar compromisos. Nunca lo hagas en plena crisis, cuando el equipo necesita resolver problemas e imaginar el fracaso solo añade ansiedad.
  • Mantén las ideas anónimas. Si los nombres son visibles, los miedos de la persona con más jerarquía condicionan la sala y los demás se limitan a darle la razón.
  • Insiste en escribir en pasado en la primera columna. "¿Por qué fracasó?" genera riesgos más específicos y realistas que "¿Qué podría salir mal?", así que reformula con tacto las ideas que vuelvan a plantearse como hipótesis.
  • Votad para reducir la lista a entre tres y cinco riesgos principales antes de hablar de prevención. Intentar abordar todas las ideas dispersa al equipo y al final no se hace nada.
  • No termines la sesión hasta que cada riesgo principal tenga un responsable y una fecha. Sin ellos, los riesgos recogidos se olvidan antes de que acabe la primera semana.
  • En equipos distribuidos, trabaja de forma asíncrona: recoge las ideas durante un día en distintas zonas horarias y reuníos 30 minutos solo para agrupar, votar y asignar responsables.

Preguntas frecuentes

¿Qué diferencia hay entre un pre-mortem y un post-mortem?
Un post-mortem se hace cuando un proyecto termina o fracasa y analiza lo que realmente salió mal. Un pre-mortem se hace antes de empezar el trabajo e imagina el fracaso por adelantado, para que el equipo pueda evitarlo mientras aún hay tiempo para actuar.
¿Quién creó la técnica del pre-mortem?
El psicólogo Gary Klein acuñó el término pre-mortem y lo describió en su artículo de 2007 en Harvard Business Review, "Performing a Project Premortem". Se basa en investigaciones que demuestran que imaginar que un resultado ya se ha producido ayuda a identificar razones más concretas que lo expliquen.
¿Cuánto dura un pre-mortem?
La mayoría de los pre-mortems duran entre 45 y 60 minutos para un equipo de cinco a diez personas. Con la opción asíncrona, la reunión en directo puede reducirse a unos 30 minutos, porque las ideas ya se han recogido antes.
¿Cuándo conviene hacer un pre-mortem?
Al arrancar el proyecto, antes de cerrar compromisos como el alcance, los plazos y el presupuesto. Evita hacerlo en plena crisis, cuando el equipo necesita centrarse en resolver problemas reales.
¿Por qué las ideas del pre-mortem deben ser anónimas?
Cuando los nombres son visibles, la gente tiende a repetir las preocupaciones de la persona con más jerarquía en la sala. Las ideas anónimas sacan a la luz los riesgos que de verdad preocupan, incluidos los que afectan a decisiones de la dirección.
¿Se puede hacer un pre-mortem de forma asíncrona?
Sí. Los equipos distribuidos pueden recoger ideas en TeamRetro durante un día y reunirse solo para agrupar, votar los riesgos principales y asignar responsables con fechas.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva