Cómo dirigir una reunión de post mortem de proyecto eficaz (+ plantilla)

El lanzamiento se torció a las 2 de la madrugada. Por la mañana el incendio estaba apagado, y alguien programó una reunión titulada «Post mortem». Todos entran preparándose para el momento en que un nombre quede ligado a la caída. Ese temor es precisamente la razón por la que la mayoría de estas revisiones fracasan.

Una reunión de post mortem debería hacer a tu equipo más inteligente, no más pequeño. Bien hecha, convierte un suceso doloroso en una breve lista de correcciones que impiden que el mismo fallo vuelva a ocurrir. Mal hecha, se convierte en un tribunal silencioso donde la gente aprende una sola lección: la próxima vez, no admitas nada. La diferencia entre esos dos desenlaces no está en la agenda. Está en si la sala es lo bastante segura como para decir la verdad.

Qué es realmente una reunión de post mortem

Un post mortem es una revisión estructurada que se celebra después de un suceso concreto para reconstruir lo que pasó y decidir qué cambiar. El detonante es la palabra clave. No se hace según un calendario. Se hace porque algo ocurrió: un producto se lanzó, un servicio se cayó, un proyecto cruzó la meta.

Y aquí hay un punto que los equipos pasan por alto. Un post mortem no es solo para los desastres. Los mejores equipos celebran uno tras un lanzamiento que salió bien, tras un incidente o una caída, y tras el cierre de un proyecto, sin importar cómo acabó. Un lanzamiento sin sobresaltos oculta decisiones que funcionaron esta vez y no funcionarán la próxima. Revisar un éxito es la forma de descubrir qué partes fueron destreza y qué partes fueron suerte.

Conviene saber qué no es un post mortem. Una retrospectiva sigue una cadencia fija, normalmente cada sprint, y examina ampliamente el proceso del equipo, haya habido o no algún fallo. Un post mortem es acotado y está impulsado por un suceso: un incidente, una cronología, una causa raíz. Un documento de lecciones aprendidas es el artefacto, el registro escrito de las conclusiones que archivas para que un equipo futuro pueda recuperarlas. La reunión produce las lecciones; el documento las almacena. Los equipos maduros usan los tres, y no pretenden que ninguno reemplace a los demás.

Lo innegociable: una cultura sin culpa

Si te llevas una sola idea de este artículo, llévate esta. Un post mortem sin culpa se centra en qué salió mal, no en quién se equivocó. Investiga los sistemas, los procesos y la información que faltaba y que dejaron pasar un error, en lugar de cargar el suceso sobre una persona.

Esto no es una preferencia blanda y complaciente. La idea surgió de la sanidad y la aviación, sectores donde un error encubierto puede matar a alguien, y donde cada fallo se trata como una oportunidad de reforzar el sistema. La lógica se traslada limpiamente a cualquier equipo. Cuando la gente teme ser avergonzada o despedida, deja de sacar a la luz los problemas. Los incidentes se barren bajo la alfombra, y la organización carga con más riesgo oculto, no menos. Quita la culpa y quitas el incentivo de ocultar.

El cambio es concreto. En lugar de «tu despliegue tiró abajo el proceso de pago», preguntas «¿por qué fue posible que un solo despliegue tirara abajo el pago sin ninguna salvaguarda?». La primera versión cierra una conversación. La segunda abre una corrección real: quizá hacía falta una compuerta de preproducción, o una alerta que saltara antes, o una reversión que tardara segundos en lugar de una hora. La culpa encuentra un culpable. La ausencia de culpa encuentra la brecha, y la brecha es lo único que de verdad puedes parchear.

Consejo: sustituye «quién» por «qué» en tiempo real. Como facilitador, ten lista una frase: «Reformulémoslo como una pregunta de sistema». Cuando alguien diga «Jordan olvidó activar la bandera», respondes: «Así que el proceso permitió que una versión saliera con un paso manual fácil de pasar por alto. ¿Qué lo habría detectado?». No estás protegiendo a Jordan. Estás dirigiendo la energía hacia lo que sí puedes arreglar.

Una agenda que mantiene la sala en el carril

Un buen post mortem sigue siempre el mismo arco, y eso es parte de por qué funciona. La gente se relaja cuando la estructura es predecible. Apunta a 60 a 90 minutos, y asigna dos roles antes de que entre nadie: un facilitador neutral para mantener el equilibrio de la discusión y un escriba para registrar cada hecho y cada decisión. Este es el flujo.

1. Marcar el tono (2 minutos)

El facilitador abre enunciando el principio sin culpa en voz alta. No como una frase desechable. Dilo con claridad: estamos aquí para entender el sistema, no para repartir culpas, y reconduciré a quien se deslice hacia la culpa. Nombrarlo al principio le da al facilitador permiso para hacerlo cumplir después.

2. Repasar la cronología y los hechos (15 a 20 minutos)

Recorre la secuencia de sucesos en orden, desde la primera señal hasta la resolución completa. Extrae de los registros, el historial de chat, las marcas de tiempo de los tickets y la documentación del proyecto para que la cronología se construya sobre hechos, no sobre la memoria. Incluye sucesos que parezcan triviales; los pequeños detalles a menudo resultan ser el punto de inflexión. Resiste la tentación de diagnosticar aquí. El objetivo es un relato compartido y acordado de lo que pasó antes de que nadie discuta el porqué.

3. Qué salió bien (10 minutos)

Aborda esto con honestidad, incluso tras un mal desenlace. ¿Qué detección funcionó? ¿Quién tomó una buena decisión bajo presión? Nombrar los aciertos protege las prácticas que vale la pena conservar y señala que la reunión no es un castigo.

4. Qué salió mal (10 a 15 minutos)

Enumera los fallos sin rodeos, como sucesos del sistema y no como faltas personales. «La alerta saltó 40 minutos después de que se disparara la tasa de errores» es útil. «Operaciones fue lenta» no lo es.

5. Análisis de causa raíz con los 5 Porqués (15 a 20 minutos)

Aquí es donde profundizas. Los 5 Porqués significan preguntar «por qué» repetidamente, unas cinco veces, hasta llegar al proceso roto que hay detrás de un síntoma en lugar de quedarte en el síntoma mismo. Cinco no es un número mágico; es una forma abreviada de decir «sigue cavando hasta dar con algo estructural».

Una regla de hierro, directa de quienes practican esta técnica a diario: una persona nunca es una causa raíz aceptable. «Error humano», «el fallo del equipo B» y «alguien no estaba prestando atención» son todas señales de que te detuviste demasiado pronto. Si un «por qué» recae en una persona, pregunta por qué el sistema dejó que esa persona fallara. Un ejemplo rápido:

• La página de pago se cayó. ¿Por qué?
• Una configuración defectuosa se desplegó a producción. ¿Por qué?
• Pasó la revisión sin que nadie detectara la errata. ¿Por qué?
• Los cambios de configuración no se validan con una prueba automatizada. ¿Por qué?
• Nunca creamos una porque las configuraciones «cambian rara vez». Causa raíz: no hay ninguna salvaguarda automatizada para un cambio de alto riesgo y baja frecuencia.

Fíjate en que la respuesta es un sistema que falta, no un ingeniero descuidado. Esa es toda la cuestión.

6. Acciones a seguir con responsables (10 minutos)

Termina con cosas concretas o la reunión fue teatro. Cada acción a seguir necesita un responsable con nombre y una fecha límite. Un vago «deberíamos mejorar las pruebas» muere en el documento. «Añadir una prueba de validación de configuración a la CI — responsable: Priya — antes del 10 de julio» se hace. Este es el entregable por el que existe toda esa hora.

Consejo: limita tus acciones a seguir a entre tres y cinco. Un post mortem que genera 20 seguimientos genera cero seguimientos. Obliga a la sala a elegir los pocos cambios que más habrían alterado el desenlace, y asígnalos. Siempre puedes hacer otra revisión más adelante. No puedes hacer realidad una lista sobrecargada.

Una facilitación que protege la seguridad psicológica

La agenda es el esqueleto; la facilitación es lo que decide si sobrevive al contacto con un equipo estresado. Unas pocas prácticas hacen que la seguridad sea real en lugar de meramente declarada.

Invita a todos a quienes tocó el suceso. Ten en la sala a un representante de cada función afectada, para que ningún departamento se convierta en la parte ausente a la que todos culpan. Usa un facilitador neutral que no fuera dueño del trabajo bajo revisión, porque quien defiende sus propias decisiones no puede arbitrar con justicia. Vigila tu lenguaje y encarna el cambio de «tú» a «el proceso» hasta que la sala empiece a hacerlo por sí sola. Y deja que quienes estuvieron más cerca del fallo hablen primero y hablen con seguridad; ellos tienen el detalle más útil, y solo lo compartirán si la primera persona que admite una brecha recibe agradecimiento en lugar de un ataque.

Una cosa más que importa en silencio: escríbelo todo donde todos puedan verlo. Cuando la cronología y las decisiones se capturan en directo y se comparten, nadie reabre el debate sobre los hechos una semana después, y las acciones a seguir no se evaporan. La memoria es enemiga de la rendición de cuentas.

Donde las notas lo hacen o lo deshacen

En un post mortem, los hechos y las acciones a seguir lo son todo. Si la cronología es difusa o los responsables nunca quedaron por escrito, celebraste una sesión de desahogo, no una revisión. El problema es que los momentos más valiosos ocurren mientras el facilitador está plenamente metido en la conversación, no escribiendo, y un escriba distraído se pierde la mitad de la cadena causal.

Aquí es donde un tomador de notas con IA se gana su lugar. Una herramienta como Laxis graba y transcribe la reunión, de modo que la discusión de la cronología se captura palabra por palabra, y luego extrae automáticamente las acciones a seguir, las decisiones y los siguientes pasos con sus responsables. En lugar de que una persona intente frenéticamente escuchar y escribir a la vez, el facilitador permanece presente y las correcciones acordadas aterrizan en un resumen limpio que puedes volcar directamente en tu documento de lecciones aprendidas. Funciona en Zoom, Meet y Teams, admite más de 40 idiomas y se sincroniza con HubSpot o Salesforce si los seguimientos necesitan llegar a esos sistemas. El objetivo no son las notas vistosas. Es que el mismo fallo no se repita porque la corrección de verdad quedó registrada y asignada.

Una plantilla de post mortem lista para copiar y pegar

Coloca esto en un documento o en tu herramienta de reuniones y complétalo sobre la marcha. Se corresponde directamente con la agenda anterior.

Agenda y plantilla de reunión de post mortem

Suceso: [lanzamiento / incidente / nombre del proyecto]
Fecha del suceso: [fecha] | Fecha de la revisión: [dentro de 24 a 72 h]
Facilitador: [nombre] | Escriba / tomador de notas: [nombre o herramienta]
Asistentes: [un representante por función afectada]

0. Regla básica (leer en voz alta): Esto es sin culpa. Nos centramos en los sistemas y los procesos, no en las personas.

1. Resumen del impacto: Qué se vio afectado, durante cuánto tiempo y quién lo sintió.

2. Cronología (solo hechos):
[hora] — [qué pasó]
[hora] — [qué pasó]
[hora] — resuelto

3. Qué salió bien: [conservar esto]

4. Qué salió mal: [sucesos del sistema, no culpa]

5. Causa raíz — 5 Porqués:
¿Por qué? → [ ]
¿Por qué? → [ ]
¿Por qué? → [ ]
¿Por qué? → [ ]
¿Por qué? → Causa raíz: [un sistema que falta, nunca una persona]

6. Acciones a seguir (máx. 3 a 5):
[acción] — Responsable: [nombre] — Fecha límite: [fecha]
[acción] — Responsable: [nombre] — Fecha límite: [fecha]

7. Dónde vive este documento: [enlace al archivo de lecciones aprendidas]

Captura la cronología y las correcciones automáticamente

Laxis graba y transcribe tu post mortem, y luego extrae las acciones a seguir, las decisiones y los responsables para que nada se pierda entre la reunión y la corrección. Permanece presente, facilita bien y deja que las notas se escriban solas.

Prueba Laxis gratis

La conclusión

La verdadera prueba de un post mortem no es la reunión. Es lo que pasa seis semanas después. Si entras en la siguiente revisión y encuentras la misma causa raíz con un disfraz distinto, la primera no funcionó, por buena que se sintiera la discusión. Un post mortem solo cuenta cuando una acción a seguir se entrega y cierra en silencio una puerta que no volverá a abrirse. Trata cada revisión como una promesa a tu yo futuro, y júzgala según si cumpliste esa promesa.

Preguntas frecuentes

¿Qué es una reunión de post mortem?

Una reunión de post mortem es una revisión estructurada que se celebra después de un suceso concreto, como el lanzamiento de un producto, una caída o el cierre de un proyecto, para reconstruir lo que pasó y decidir cómo evitar que las partes malas se repitan. Es específica de un incidente y gira en torno a una cronología basada en hechos, un análisis de causa raíz y una lista de acciones a seguir con responsables y fechas límite.

¿Cuándo debería celebrarse una reunión de post mortem?

Celébrala cuando el polvo se haya asentado pero antes de que se desvanezca la memoria, idealmente dentro de las 24 a 72 horas tras la resolución del suceso. Esa ventana es lo bastante tardía para que las emociones se enfríen y lo bastante temprana para que la gente aún recuerde los detalles. Haz una después de cualquier lanzamiento, incidente o cierre de proyecto, fuera bueno o malo el resultado.

¿Qué significa un post mortem sin culpa?

Sin culpa significa que la reunión investiga sistemas y procesos, no individuos. El principio se originó en la sanidad y la aviación, donde los errores pueden ser fatales. Cuando la gente no teme ser castigada, reporta los problemas con honestidad, lo que te permite corregir las condiciones que permitieron el fallo en lugar de convertir a una persona en chivo expiatorio.

¿En qué se diferencia un post mortem de una retrospectiva?

Una retrospectiva sigue una cadencia regular, como cada sprint, y revisa el proceso del equipo a lo largo de una ventana fija, haya salido algo mal o no. Un post mortem lo desencadena un suceso concreto y profundiza en la cronología y la causa raíz de un solo incidente. Muchos equipos usan ambos: retrospectivas para la corrección de rumbo rutinaria, post mortems tras un hito importante o una interrupción.

¿Qué es la técnica de los 5 Porqués en un post mortem?

Los 5 Porqués son un método de causa raíz en el que preguntas por qué repetidamente, normalmente unas cinco veces, hasta llegar al proceso roto que hay detrás de un síntoma en lugar de quedarte en el síntoma mismo. Una regla central: una persona nunca es una respuesta aceptable. Si «por qué» recae en un error humano, sigue adelante hasta encontrar el sistema que permitió el error.