Reunión post mortem: plantilla y preguntas

Un viernes a las 4:50 p. m., un distribuidor de materiales de construcción en Monterrey envió por correo su lista de precios de otoño a 3,800 clientes. El lunes, los contratistas ya estaban pidiendo 140 artículos a precios 12% por debajo del costo, y el equipo de ventas pasó dos días al teléfono para corregirlo. (El distribuidor es un caso compuesto, no una empresa real).

La primera pregunta en la sala fue quién lo había enviado. Esa es justo la pregunta que una buena reunión post mortem nunca hace.

Esta guía te muestra cómo llevar una reunión post mortem que encuentre la causa real sin buscar un culpable: cuándo hacerla, en qué se diferencia de una retrospectiva, una agenda de 60 minutos, los cinco porqués, 20 preguntas ordenadas por etapa y una plantilla de una página llena con el caso de la lista de precios.

¿Qué es una reunión post mortem?

Una reunión post mortem es una revisión única que se hace al terminar un proyecto o después de resolver un incidente. Las personas involucradas acuerdan qué pasó, por qué pasó y qué va a cambiar para que no se repita. El resultado es un post mortem escrito y breve, con una línea de tiempo, la causa raíz y tareas con responsables.

El libro de Site Reliability Engineering de Google describe ese documento como un registro escrito de un incidente, su impacto, las acciones tomadas para mitigarlo o resolverlo, sus causas raíz y las acciones de seguimiento para evitar que se repita. La idea no es solo para software. Un lanzamiento fallido, una cuenta clave perdida o una feria comercial que no trajo prospectos merecen el mismo análisis.

Cuándo hacerla. El libro de SRE recomienda definir los criterios para un post mortem antes de que ocurra un incidente, para que todos sepan cuándo hace falta uno. El manual de incidentes de Atlassian los hace para sus dos niveles de severidad más altos. Fuera de la ingeniería, buenos disparadores son un cliente que perdió dinero, una fecha o un presupuesto que se pasó por un margen definido, o un proyecto terminado con otro parecido en camino. Haz la reunión dentro de la semana siguiente, cuando la memoria sigue fresca pero los ánimos ya se calmaron.

Post mortem o retrospectiva

Las dos miran hacia atrás y cambian algo. La diferencia está en el ritmo y la profundidad.

Para un chequeo regular del equipo, usa una reunión retrospectiva. Usa un post mortem cuando un solo evento necesita una explicación completa.

Antes de la reunión: arma la línea de tiempo

Un post mortem sale mal cuando la hora se va en discutir qué pasó. Deja los hechos claros antes.

Nombra a una persona responsable del post mortem, por lo general quien coordinó la respuesta o dirigió el proyecto. Antes de la reunión, prepara un resumen de tres oraciones, el impacto (a quién afectó, cuánto tiempo, cuánto costó), una línea de tiempo con horas desde la primera señal de alerta hasta la solución, y una primera hipótesis de causas, marcada como borrador.

Escribe la línea de tiempo con roles, no con nombres. El manual de Atlassian pide referirse a las personas por su rol (por ejemplo, "el ingeniero de guardia de Widgets") en lugar de por su nombre. En el caso de la lista de precios, eso es "la coordinación de marketing" y "el analista de precios". Comparte el borrador un día antes.

¿Vas a reconstruir la línea de tiempo de memoria? Graba las conversaciones de revisión cuando ocurren, y ParrotNotes convierte cada una en transcripción, resumen y tareas. Prueba ParrotNotes gratis.

Agenda de 60 minutos para la reunión post mortem

La agenda que sugiere Atlassian empieza recordándole al equipo que los post mortem son sin culpables, y por qué; luego confirma la línea de tiempo y las causas raíz y genera acciones. Con tiempos:

1. Reglas básicas (5 minutos). Quien facilita dice en voz alta que el objetivo es arreglar el sistema, no encontrar a una persona.
2. Recorrer la línea de tiempo (15 minutos). La persona responsable la lee. Todos corrigen hechos y agregan lo que sabían en cada momento.
3. Encontrar la causa raíz (15 minutos). Aplica los cinco porqués a la falla principal.
4. Qué salió bien, qué no, dónde tuvimos suerte (10 minutos). Son las tres preguntas de Atlassian. "¿Dónde tuvimos suerte?" es la que más se salta, y muchas veces apunta al próximo incidente.
5. Acordar acciones (10 minutos). Cada una tiene una persona responsable y una fecha.
6. Cierre (5 minutos). Lee las acciones en voz alta, nombra a quien aprueba y fija la fecha en que se compartirá el informe.

Encuentra la causa raíz con los cinco porqués

El manual de Atlassian indica usar la técnica de los "cinco porqués" para recorrer la cadena causal hasta encontrar una verdadera causa raíz. Pregunta por qué, toma la respuesta y vuelve a preguntar por qué. Detente cuando la respuesta sea un proceso que puedes cambiar.

La cadena del correo con la lista de precios:

1. ¿Por qué los clientes recibieron precios equivocados? El PDF se armó con la pestaña de costos del año anterior.
2. ¿Por qué esa pestaña? Tras la fusión de un proveedor, el archivo tenía dos pestañas con nombres casi iguales.
3. ¿Por qué nadie lo detectó? Nadie comparó el PDF con el sistema de precios antes de la fecha límite del viernes.
4. ¿Por qué no hubo revisión? Los pasos los conocía una sola persona, y estaba de vacaciones.
5. ¿Por qué solo una persona? El proceso nunca se escribió ni tuvo una segunda revisión.

La causa raíz no es "la coordinación eligió la pestaña equivocada". Es un proceso sin pasos escritos y sin segunda revisión.

Un post mortem sin culpables

Según el libro de SRE, un post mortem sin culpables debe identificar las causas que contribuyeron al incidente sin acusar a ninguna persona ni a ningún equipo. Su razón es práctica: a las personas no se les puede "arreglar", pero a los sistemas y procesos sí.

John Allspaw defendió lo mismo en 2012 en el blog de ingeniería de Etsy, en Blameless PostMortems and a Just Culture: la gente cuenta con detalle lo que hizo y lo que supuso solo si puede hacerlo sin miedo a castigos ni represalias.

La culpa se cuela por las palabras. Cambia estas frases:

Preguntas para la reunión post mortem, por etapa

Veinte preguntas para usar. Elige algunas por etapa.

Línea de tiempo

1. ¿Cuándo apareció la primera señal de que algo andaba mal?
2. ¿Quién lo notó y cómo?
3. ¿Qué sabía cada persona en ese momento?
4. ¿Hubo alertas previas que pasamos por alto?

Impacto 5. ¿A quién afectó: clientes, colegas, socios? 6. ¿Cuánto costó en dinero, tiempo o confianza? 7. ¿Sigue habiendo algún impacto?

Causas 8. ¿Qué hizo esto posible? 9. ¿Por qué nuestros controles no lo detectaron? 10. ¿Ya había pasado algo parecido? 11. ¿Qué supuesto resultó falso? 12. ¿Qué presión (fecha límite, personal, traspaso) influyó en las decisiones?

Respuesta 13. ¿Qué salió bien en nuestra respuesta? 14. ¿Qué nos frenó? 15. ¿Dónde tuvimos suerte? 16. ¿Cómo pudimos haber reducido a la mitad el tiempo de respuesta?

Acciones 17. ¿Qué cambio lo habría evitado? 18. ¿Qué nos ayudaría a detectarlo antes? 19. ¿Quién es responsable de cada acción y para cuándo? 20. ¿Quién necesita leer este post mortem?

La pregunta 16 está adaptada del manual de Atlassian, que plantea como ejercicio cómo se habría podido reducir el tiempo a la mitad.

Plantilla para la reunión post mortem

Copia esta plantilla de una página:

POST MORTEM
Evento:              Fecha del evento:      Fecha de la reunión:
Responsable:         Aprueba:               Asistentes (roles):

1. RESUMEN (3 oraciones)
2. IMPACTO: a quién | cuánto tiempo | costo
3. LÍNEA DE TIEMPO (roles, no nombres): hora | qué pasó | qué sabíamos
4. CAUSA RAÍZ (cinco porqués)
5. SALIÓ BIEN / NO SALIÓ BIEN / TUVIMOS SUERTE
6. ACCIONES: acción | responsable | fecha | prevenir, detectar o responder
7. COMPARTIDO CON:                         Fecha:

Llena con el caso del correo de precios (un ejemplo compuesto):

POST MORTEM
Evento: Lista de precios de otoño enviada con precios equivocados
Fecha del evento: vie 26 de sep.   Fecha de la reunión: jue 2 de oct.
Responsable: Gerente de operaciones de ventas   Aprueba: Dirección de ventas

1. RESUMEN: Lista enviada a 3,800 clientes desde la pestaña de
   costos del año anterior; 140 artículos 12% bajo costo. Se
   respetaron 31 pedidos y el resto se corrigió por teléfono en
   dos días.
2. IMPACTO: 31 pedidos con pérdida; unas 60 horas de llamadas
3. LÍNEA DE TIEMPO
   vie 16:50  La coordinación de marketing envía la lista
   sáb 09:12  Primer pedido al precio equivocado
   lun 07:40  Un vendedor de campo nota la diferencia en una cotización
   lun 09:30  Se envía la lista corregida; empiezan las llamadas
4. CAUSA RAÍZ: pasos de publicación nunca escritos, sin segunda
   revisión; la única persona que los conocía estaba de vacaciones
5. SALIÓ BIEN: un vendedor lo detectó rápido; un solo guion de llamada
   NO SALIÓ BIEN: no hubo revisión antes del envío
   TUVIMOS SUERTE: los errores eran en artículos de poca venta
6. ACCIONES
   Checklist escrito de publicación   | Analista de precios     | 10 oct. | prevenir
   Segunda revisión de cada lista     | Gerente de operaciones  | 10 oct. | prevenir
   Envío de prueba a 5 vendedores     | Coordinación marketing  | 17 oct. | detectar
7. COMPARTIDO CON: todo el equipo de ventas, 6 oct.

Cada acción cambia un proceso, no a una persona.

Convierte las acciones del post mortem en trabajo terminado

El libro de SRE advierte que un post mortem que nadie revisa es como si nunca hubiera existido. Atlassian registra cada acción en el backlog del equipo responsable y les da a las correcciones de causa raíz, sus "acciones prioritarias", un plazo de cuatro u ocho semanas según el servicio.

Copia la idea: una persona responsable con nombre por acción, una fecha real, alguien que aprueba y se asegura de que las acciones tengan tiempo, y una fecha para comprobar que funcionaron. Nuestra guía de seguimiento de tareas de reuniones muestra cómo darles seguimiento entre reuniones. Si el post mortem cambia una regla, anótala en un registro de decisiones para que quien entre al equipo sepa por qué existe.

Un mes después, la siguiente lista de precios del distribuidor salió tras un envío de prueba a cinco vendedores. Uno encontró un cargo de flete equivocado. Ningún cliente llegó a verlo.

¿Conviene grabar la reunión post mortem?

Una grabación deja que quien facilita dirija la sala en lugar de escribir, y evita discusiones posteriores sobre lo que se acordó. Pero las personas van a hablar de sus propios errores, así que pregunta antes: explica por qué grabas, quién lo va a escuchar y cuánto tiempo lo vas a guardar, y detente si alguien se opone. Para lo básico de la ley en Estados Unidos, consulta nuestra guía sobre el consentimiento de una parte en Estados Unidos.

Si el equipo está de acuerdo, ParrotNotes graba en el teléfono o la Mac que ya está en la sala, sin bot de reuniones, y te da la transcripción, el resumen y las tareas. Pégalos en las secciones 3, 5 y 6 de la plantilla y cambia los nombres por roles. Chatea con la transcripción para revisar un detalle. Con Pro, la identificación de hablantes marca quién dijo qué, la búsqueda con IA encuentra respuestas en todos los post mortem anteriores, y 99+ idiomas con traducción cubren a los equipos que trabajan en varios idiomas.

Aprende una vez, corrígelo para siempre

Define los disparadores con anticipación. Arma la línea de tiempo antes de la reunión. Mantén la hora sin culpables, encuentra la causa raíz con los cinco porqués y sal con pocas acciones, cada una con responsable, fecha y aprobación. Después comparte lo que aprendieron.

Al distribuidor no le hacía falta una coordinación más cuidadosa. Le hacía falta un checklist y un segundo par de ojos.

Haz tu próximo post mortem sin una persona dedicada a tomar notas. ParrotNotes captura la conversación en la sala y te entrega el resumen y las tareas. Descarga ParrotNotes gratis.