Causas raíz

¿Cómo describirías la cronología de los hechos?

El despliegue salió a las 14:20 y las primeras alertas de error saltaron unos ocho minutos después.
Los clientes empezaron a reportar fallos de inicio de sesión antes de que lo detectara nuestra monitorización.
Hicimos la reversión a las 15:05, pero la caché tardó otros 20 minutos en vaciarse del todo.
¿Qué salió bien?

¿Qué funcionó y nos ayudó a responder con eficacia?

Nuestras alertas detectaron el pico de errores casi al instante.
El equipo se conectó a la llamada del incidente en cuestión de minutos y mantuvo la calma.
Tener un procedimiento de reversión claro nos ahorró mucho tiempo.
¿Qué salió mal?

¿Dónde fallaron las cosas o no estuvieron a la altura?

No teníamos ninguna prueba automatizada que cubriera esta ruta de configuración.
La monitorización no cubría la dependencia que realmente falló.
La vía de escalado no estaba clara, así que se avisó tarde a las personas adecuadas.
Acciones

¿Qué haremos para evitar que esto se repita?

Añadir pruebas automatizadas que cubran el cambio de configuración que falló.
Actualizar el runbook y verificar los pasos de reversión la semana que viene.
Implantar una congelación de despliegues los viernes para cambios de alto riesgo.

¿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

Preguntas frecuentes

¿Qué es un post-mortem sin culpables?
Es una revisión que analiza los sistemas, procesos y circunstancias que hay detrás de un incidente en lugar de culpar a las personas. La gente es más sincera cuando no tiene que defenderse, así que el equipo encuentra las causas reales y puede solucionarlas.
¿Cuándo conviene hacer una retrospectiva post-mortem?
Hazla después de un incidente importante, una caída del servicio, un plazo incumplido o el final de un proyecto relevante. Celébrala poco después del suceso, mientras los detalles siguen frescos.
¿Cuánto dura una retrospectiva post-mortem?
La mayoría dura entre 60 y 90 minutos, según la complejidad del incidente. Reserva tiempo extra para el análisis de causa raíz y para acordar acciones claras.
¿En qué se diferencia un post-mortem de una retrospectiva de sprint?
Una retrospectiva de sprint revisa un periodo de trabajo fijo y cómo ha colaborado el equipo. Un post-mortem se centra en un único incidente o suceso, empezando por la cronología y remontándose hasta las causas.
¿Quién debería asistir a una retrospectiva post-mortem?
Las personas directamente implicadas en el incidente o el proyecto, además de quien pueda aportar contexto o vaya a ser responsable de alguna acción de seguimiento. Mantén el grupo lo bastante reducido para que todos puedan opinar.
¿Cómo evitar que un post-mortem se convierta en una caza de culpables?
Deja claro al inicio que la sesión es sin culpables, centra la conversación en procesos y sistemas en vez de en personas, y trata los errores como información. Un facilitador neutral ayuda a mantener un tono constructivo.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva