¿Qué es la retrospectiva post-mortem?
Una retrospectiva post-mortem es una revisión sin culpables de un incidente, un proyecto o una entrega una vez terminados. El equipo analiza qué pasó, por qué pasó y qué debe cambiar para que el mismo problema no se repita. Sirve para incidentes en producción y caídas del servicio, y funciona igual de bien para un plazo incumplido o el cierre de una iniciativa importante. El tablero tiene cuatro columnas. Causas raíz empieza por la cronología: el equipo expone qué ocurrió y cuándo antes de que nadie lo analice, para que todos partan de los mismos hechos. ¿Qué salió bien? recoge lo que ayudó, como alertas que saltaron rápido o una reversión que funcionó. ¿Qué salió mal? cubre las carencias y los obstáculos que empeoraron la situación. Acciones convierte la conversación en soluciones concretas con un responsable y una fecha. En TeamRetro, todos añaden sus observaciones a la vez, agrupan las relacionadas, votan los problemas de mayor impacto y asignan las acciones de seguimiento antes de que termine la reunión. Los post-mortems sin culpables son una práctica habitual en la ingeniería de fiabilidad de sitios (SRE) y en la gestión de incidentes. Cuando el equipo trata un fallo como información sobre el sistema y no como culpa de alguien, la gente cuenta lo que pasó de verdad, y así es como se detectan los puntos débiles de un proceso. Guarda el informe y tendrás un registro que consultar la próxima vez que algo parecido falle.
Formato de retrospectiva post-mortem
Causas raíz
¿Cómo describirías la cronología de los hechos?
Empieza con un relato compartido y basado en hechos del incidente o del proyecto antes de cualquier análisis. Pide al equipo que exponga la secuencia de acontecimientos en orden, ciñéndose a qué pasó y cuándo, no a quién hizo qué. Ponerse de acuerdo primero en la cronología evita malentendidos y da a todos el mismo punto de partida para encontrar las causas.
¿Qué salió bien?
¿Qué funcionó y nos ayudó a responder con eficacia?
Incluso un mal incidente suele tener cosas que vale la pena conservar. Usa esta columna para nombrar las acciones, herramientas y decisiones que ayudaron, para que el equipo sepa qué debe seguir haciendo. Empezar por lo que funcionó también rebaja la tensión de la conversación que viene después.
¿Qué salió mal?
¿Dónde fallaron las cosas o no estuvieron a la altura?
Esta columna recoge los problemas, carencias y obstáculos que empeoraron el incidente o el resultado. Centra la conversación en los procesos y los sistemas, no en las personas, y recuerda al equipo que el objetivo es aprender. Busca carencias que permitieran que fallaran varias cosas a la vez, como una monitorización inexistente o una vía de escalado poco clara.
Acciones
¿Qué haremos para evitar que esto se repita?
Convierte la conversación en mejoras concretas, cada una con un responsable y una fecha límite. Que sean lo bastante realistas como para poder terminarlas. Coloca al principio de la lista los cambios con más probabilidades de evitar que se repita.
Cuándo utilizar este estudio retrospectivo
- Después de un incidente en producción o una caída del servicio, para entender la causa y evitar que vuelva a ocurrir
- Al cierre de un proyecto o una entrega importante, para recoger lecciones mientras los detalles siguen frescos
- Cuando se ha incumplido un plazo o una iniciativa no ha cumplido las expectativas y el equipo necesita una revisión honesta
- Cuando el mismo problema vuelve una y otra vez y quieres encontrar su causa real
- Cuando quieres que tus equipos traten los fallos como algo de lo que aprender, no como una ocasión para culpar a alguien
Preguntas sugeridas para romper el hielo
- ¿Cuál es el «ups» más memorable que has tenido y que acabó siendo una gran lección?
- Si este incidente fuera una película, ¿qué título le pondrías?
¿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
- Deja claro desde el principio que la sesión es sin culpables, para que la gente se sienta segura contando lo que pasó de verdad
- Construye una cronología compartida y basada en hechos antes de que nadie empiece a analizar
- Usa los cinco porqués para ir más allá de los síntomas y llegar a la causa de fondo
- Asigna a cada acción un responsable y una fecha límite para que realmente se lleve a cabo
- Invita a las personas que estuvieron implicadas, pero mantén el grupo lo bastante reducido para no perder el foco
- Documenta el resultado y revisa las acciones anteriores en sesiones posteriores para confirmar que las soluciones se mantienen