Plantilla de Post Mortem de Proyecto

Revisa cualquier proyecto o incidente y captura aprendizajes

Pruebe esta retransmisión retrospectiva

Visión general, objetivos y alcance del proyecto

¿Qué se proponía el proyecto y para cuándo?

El objetivo era migrar toda la facturación de clientes a la nueva plataforma antes de que acabara el Q3, sin caídas para las cuentas enterprise.
Lanzamos el portal de clientes tres semanas más tarde de la fecha original, con dos de las cinco funcionalidades planificadas recortadas.
Los criterios de éxito nunca se escribieron en ningún sitio que yo pudiera encontrar, así que tenía mi propia versión en la cabeza.
Qué fue bien

¿Qué logros y procesos merece la pena repetir?

Las sincronizaciones diarias de quince minutos durante el periodo de más presión mantuvieron a todo el mundo alineado sin añadir carga de reuniones.
Nuestro runbook de guardia estaba correcto, lo que hizo que aplicar la solución llevara minutos en lugar de horas.
Emparejar a las personas nuevas con revisores desde el principio las hizo productivas más rápido de lo que esperaba.
Qué no fue bien

¿Dónde nos atascamos, rompimos o fallamos objetivos?

Los requisitos cambiaban constantemente y nadie era claramente responsable de decidir cuándo eran definitivos.
Las pruebas se comprimieron en los últimos días, y por eso dos defectos llegaron a los clientes.
Nuestra monitorización no cubría la profundidad de la cola, así que estábamos ciegos hasta que las cosas ya se habían acumulado.
Análisis de causa raíz

¿Por qué salió mal, no solo que salió mal?

La causa raíz fue un cambio de configuración desplegado directamente a producción porque nuestro pipeline no tenía un paso de revisión obligatorio.
Subestimamos porque la estimación se hizo antes del spike técnico y luego se trató como un compromiso.
Nadie era dueño de la integración entre los dos equipos, así que el hueco fue invisible hasta la semana de integración.
Lecciones aprendidas

¿Cuáles son los aprendizajes clave que nos llevamos?

Hacer el spike técnico antes de comprometernos con cualquier fecha, y luego re-estimar de forma abierta.
Escribir los criterios de éxito en el kickoff. Si no logramos ponernos de acuerdo en ellos, no estamos listos para empezar.
Los cambios de alcance necesitan un punto de control por escrito en lugar de ser absorbidos silenciosamente por el equipo.
Acciones, responsables y plazos

¿Quién hace qué y para cuándo?

Añadir un paso de revisión obligatorio al pipeline de despliegue a producción. Responsable: Priya. Fecha: fin del próximo sprint.
Redactar una plantilla de una página de carta de proyecto con criterios de éxito. Responsable: Sam. Fecha: día 15.
Añadir alertas de profundidad de cola y tasa de errores dirigidas a la rotación de guardia. Responsable: Dev. Fecha: esta semana.
Agradecimientos y kudos al equipo

¿Quién merece reconocimiento antes de cerrar?

Gracias a Priya por mantener la calma en la llamada de crisis y mantener a todo el mundo centrado en la solución.
Kudos al equipo de soporte, que absorbió los contactos de clientes casi sin aviso previo.
Mucho reconocimiento para Sam, que escribió sin hacer ruido el runbook que nadie pidió y luego nos salvó con él.

¿Qué es una retrospectiva post mortem?

Un post mortem es la conversación que tiene tu equipo después de que algo termina. A veces ese algo es un incidente: un sistema se cayó, una liberación salió mal, un cliente sufrió las consecuencias. Con la misma frecuencia se trata de un proyecto normal que simplemente ha concluido, y quieres una plantilla de postmortem clara para dirigir la reunión de revisión sin tener que inventar una agenda desde cero. Este formato sirve para ambos casos. Estableces el marco con los objetivos y el alcance del proyecto, recorres lo que funcionó bien y lo que no, profundizas en las causas raíz cuando hace falta y transformas las partes más honestas en lecciones aprendidas que tu organización puede reutilizar de verdad. Así funciona en TeamRetro. Cada persona añade primero sus propias observaciones en privado, de modo que la voz más fuerte de la sala no imponga la narrativa antes de que las personas más calladas hayan escrito nada. Luego las ideas se agrupan, se discuten y se votan, lo que te permite priorizar el puñado de temas que realmente importan en lugar de masticar cuarenta comentarios sin ningún orden. Esa es la diferencia con una plantilla de post mortem estática que rellenas en solitario: es un debrief de equipo en vivo que todo el grupo dirige junto, y termina con responsables y fechas asignadas a acciones reales en lugar de un documento que nadie vuelve a abrir. Úsala como tu revisión de proyecto por defecto al cierre de una entrega, una campaña, una migración o un trimestre, y como tu revisión de incidentes cuando algo ha ido mal y necesitas un relato sin culpas de la cronología y sus causas. El último tema deja espacio para los kudos, porque reconocer a las personas que sacaron el trabajo adelante es parte de cerrarlo como corresponde. En cualquier caso el objetivo es el mismo. Quieres que el equipo salga sabiendo qué repetir, qué dejar de hacer y quién hace qué a continuación. Tu informe se exporta automáticamente, así que las lecciones aprendidas quedan buscables para el próximo equipo que se encuentre en la misma situación.

Formato de la retrospectiva post mortem

Visión general, objetivos y alcance del proyecto

¿Qué se proponía el proyecto y para cuándo?

Este tema establece el marco antes de que nadie juzgue nada. Pide el objetivo original, el alcance acordado, el cronograma y los criterios de éxito, además de lo que realmente se entregó frente a ellos. Para una revisión de incidentes, úsalo en cambio para los hechos de la cronología: qué se rompió, cuándo se detectó, quién participó y cómo se resolvió. Deja la interpretación fuera de esta columna y aparca las opiniones para los temas que vienen después. Si la gente no se pone de acuerdo sobre cuáles eran los objetivos o los criterios de éxito, ese desacuerdo es en sí mismo un hallazgo que merece registrarse.

Qué fue bien

¿Qué logros y procesos merece la pena repetir?

Los equipos pasan corriendo por este tema, especialmente después de un proyecto difícil o de un incidente estresante, así que protege el tiempo dedicado a él. Buscas prácticas repetibles, no cumplidos, y los kudos tienen su propio tema más adelante. Cuando alguien publique un elogio, pregunta qué fue exactamente lo que hizo que funcionara para que la respuesta se pueda reutilizar. Presta atención a los éxitos que vinieron del heroísmo individual y nómbralos como riesgos en lugar de como logros.

Qué no fue bien

¿Dónde nos atascamos, rompimos o fallamos objetivos?

Aquí está el valor de verdad, así que establece en voz alta la regla de la ausencia de culpa antes de empezar: estás examinando sistemas y decisiones, no personas. Fomenta la concreción por encima de las quejas vagas, porque «la comunicación fue mala» no se puede accionar, pero «nos enteramos del cambio de fecha límite en una conversación de pasillo» sí. Usa la votación aquí para evitar que la discusión se disperse por cada irritación de los últimos tres meses.

Análisis de causa raíz

¿Por qué salió mal, no solo que salió mal?

Opcional para una revisión de proyecto sencilla, imprescindible para un incidente. Toma los problemas más votados del tema anterior y sigue preguntando por qué hasta llegar a una condición y no a una persona: una salvaguarda ausente, un responsable poco claro, una presión de calendario, una suposición que nadie comprobó. Los Cinco Por Qué funcionan bien aquí, y también preguntar qué hizo que la acción equivocada pareciera razonable en su momento. Detente cuando llegues a algo que realmente puedas cambiar, y anota los factores contribuyentes por separado del detonante.

Lecciones aprendidas

¿Cuáles son los aprendizajes clave que nos llevamos?

Este es el «y entonces qué» que convierte las observaciones en conocimiento reutilizable. Empuja cada idea hasta que nombre un comportamiento, un detonante o una salvaguarda, para que pueda sobrevivir al contacto con el próximo proyecto. Distingue entre lo que este equipo puede cambiar por sí mismo y lo que debe subir a un responsable o a otro grupo, y sé honesto con la segunda categoría. Redacta los aprendizajes de forma que alguien de fuera de la sala pueda leerlos en el informe exportado y entenderlos sin que tú estés ahí para explicarlos.

Acciones, responsables y plazos

¿Quién hace qué y para cuándo?

Un post mortem sin acciones asignadas no cuenta, así que deja tiempo real para esto en lugar de meterlo en los últimos dos minutos. Convierte las lecciones más votadas en un número reducido de acciones específicas, cada una con un responsable con nombre y una fecha límite registrada en TeamRetro para que aparezcan en tu próxima sesión. Dos o tres acciones bien asignadas valen más que diez aspiracionales. Si una acción pertenece a alguien de fuera de la sala, acordad quién la llevará a esa persona y para cuándo.

Agradecimientos y kudos al equipo

¿Quién merece reconocimiento antes de cerrar?

Cierra con las personas, no con los problemas. Invita a todo el mundo a nombrar a una persona concreta y algo concreto que hizo, lo cual es mucho más significativo que un agradecimiento general y funciona bien incluso después de un proyecto difícil. Esto importa sobre todo cuando la revisión ha sido dura, porque recuerda al equipo que examinar un fallo no es lo mismo que culparse entre sí. Mantenlo breve, lee unos cuantos en voz alta y deja que el informe exportado recoja el resto.

Cuándo utilizar este estudio retrospectivo

  • Un proyecto, entrega, migración o campaña acaba de terminar y quieres una revisión de proyecto estructurada en lugar de una charla informal que se acaba diluyendo.
  • Un incidente, caída o liberación fallida necesita un post mortem sin culpas que cubra la cronología, las causas raíz y las acciones preventivas.
  • Un programa de larga duración ha terminado una fase y quieres capturar las lecciones aprendidas mientras los detalles siguen frescos.
  • Un grupo multidisciplinar se está disolviendo y esta es tu última oportunidad de hacer un debrief de equipo y reconocer a quienes contribuyeron antes de que cada uno se vaya a trabajos nuevos.
  • Algo salió inesperadamente bien y quieres entender por qué, para poder repetir la práctica en lugar de tratarla como suerte.

Preguntas sugeridas para romper el hielo

  • En una palabra, ¿cómo se sintió este proyecto o incidente mientras estabas en medio de él?
  • Si pudieras enviarte una frase de consejo a ti mismo en el día uno, ¿qué diría?

¿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

  • Hazlo dentro de una o dos semanas del cierre del proyecto o de la resolución del incidente. La memoria se desvanece rápido y con ella se va el detalle útil.
  • Enuncia la regla de la ausencia de culpa al principio. Estás mirando decisiones, sistemas y presiones, no buscando a alguien a quien responsabilizar.
  • Dedica unos minutos a acordar la visión general del proyecto antes de que empiecen las opiniones. Un marco compartido evita que la sesión se convierta en un debate sobre cuál era el objetivo.
  • Sáltate o acorta el análisis de causa raíz en una revisión de proyecto limpia, y apóyate en él en los incidentes donde la prevención es lo que importa.
  • Prioriza con votación y luego no dejes que la reunión termine sin responsables y fechas en las acciones principales; de lo contrario tus lecciones aprendidas se quedan en la teoría.
  • Trae a la sala las acciones del post mortem anterior y revísalas primero. Nada mejora el seguimiento como saber que se va a comprobar.

Preguntas frecuentes

¿Qué es un post mortem de proyecto?
Un post mortem de proyecto es una revisión estructurada que tu equipo realiza una vez terminado un trabajo, sea el lanzamiento de un producto, una migración, una campaña o una entrega a cliente. Miras los objetivos y el alcance originales, qué fue bien, qué no y las lecciones aprendidas que merece la pena llevarse. A diferencia de un postmortem de incidente, no tiene que haber ido nada mal necesariamente. El detonante es simplemente que el trabajo ha terminado y hay conocimiento que merece conservarse.
¿En qué se diferencia un post mortem de proyecto de un post mortem de incidente?
El formato es similar pero el foco es distinto. Un post mortem de incidente lo desencadena un fallo, así que se apoya mucho en reconstruir la cronología, la detección, la respuesta y el análisis de causa raíz, con la prevención como objetivo. Un post mortem de proyecto lo desencadena la finalización, así que cubre objetivos, estimación, alcance, colaboración, traspaso y entrega, con la mejora del próximo proyecto como objetivo. Ambos deben ser sin culpas y ambos deben terminar en acciones con responsables.
¿Qué debe incluir un post mortem de proyecto?
Empieza con la visión general del proyecto: objetivos, alcance, cronograma, criterios de éxito y qué se entregó realmente. Después cubre qué fue bien, qué no fue bien y las causas raíz de los problemas que más importan. Termina con las lecciones aprendidas, las acciones con responsables y plazos, y una ronda de kudos al equipo. Los siete temas caben en una sola sesión de TeamRetro, y la votación te ayuda a priorizar en lugar de salir con cuarenta observaciones sin ordenar.
¿Tengo que usar el tema de análisis de causa raíz?
No, es opcional. Se gana su lugar en las revisiones de incidentes y caídas, donde entender por qué falló algo es todo el objetivo, y en proyectos que incumplieron objetivos importantes. Para una entrega sin sobresaltos puedes saltarlo, o simplemente tomar los dos problemas más votados y preguntar por qué unas cuantas veces antes de pasar a las lecciones aprendidas.
¿Cuánto dura un post mortem?
Reserva entre sesenta y noventa minutos para la mayoría de proyectos e incidentes. Los incidentes contenidos o los proyectos pequeños se pueden revisar en cuarenta y cinco minutos si te saltas el análisis de causa raíz. Los programas grandes suelen necesitar dos horas o un par de sesiones, una para la visión general factual y las causas y otra para las mejoras y las acciones. Como en TeamRetro todo el mundo hace lluvia de ideas en paralelo, la fase de recopilación se mantiene corta.
¿Quién debería asistir a un post mortem?
Incluye a las personas que hicieron el trabajo y a las afectadas por él: el equipo de entrega, el responsable de producto o de proyecto y representantes de soporte, diseño u operaciones que heredaron el resultado. Para un incidente, incluye a quienes respondieron, al personal de guardia y a quien gestionó la comunicación con clientes. Mantén el grupo lo bastante pequeño para una conversación honesta, y pide a los asistentes senior que escuchen en lugar de defender decisiones.

Plantillas relacionadas

Planificación de Retiro de Equipo

Un enfoque estructurado para planificar un retiro de equipo productivo y atractivo.

Planificación de Inicio de Proyecto

Alinear al equipo en los objetivos del proyecto y planificar la ejecución.

Retrospectiva de Fin de Año

Reflexiona sobre los logros, desafíos y aprendizajes del año pasado.

Retrospectiva Post-Lanzamiento

Analizar éxitos, desafíos y mejoras después de los lanzamientos.

¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión retrospectiva