Definición rápida
Post-mortem es el análisis estructurado que se realiza después de un proyecto, incidente técnico o fracaso para identificar qué salió bien, qué falló, las causas raíz y qué acciones se toman para mejorar. En startups, el post-mortem es una herramienta central de aprendizaje organizacional y mejora continua.
¿Qué es un Post-mortem?
El término proviene de la medicina («después de la muerte»), donde describe la autopsia que determina la causa de muerte. En tecnología y startups, el post-mortem se adoptó para analizar «muertes» de proyectos, features, incidentes de producción o decisiones que resultaron en fracasos.
Google popularizó el concepto de Blameless Post-mortem (post-mortem sin culpa): el objetivo no es encontrar al culpable sino entender sistémicamente por qué falló el sistema o proceso. Esta filosofía es fundamental: si el post-mortem se convierte en una caza de brujas, las personas ocultarán información y el aprendizaje no ocurre.
Los post-mortems en ingeniería de software son especialmente importantes para incidentes de producción (caídas del sistema, brechas de seguridad, pérdida de datos). Pero el concepto aplica igualmente a fracasos comerciales, lanzamientos fallidos, churns de clientes importantes o decisiones estratégicas que no dieron resultado.
¿Cómo hacer un Post-mortem efectivo?
- Timeline del incidente: Reconstruir cronológicamente qué ocurrió, con timestamps precisos si es posible.
- Impacto: Cuantificar el daño: usuarios afectados, revenue perdido, SLA incumplido, reputación.
- Causa raíz (Root Cause Analysis): Usar el método de «5 Whys» (5 porqués) para llegar a la causa sistémica, no solo el síntoma. Ejemplo: El servidor cayó → ¿Por qué? → Alta carga → ¿Por qué? → Sin auto-scaling → ¿Por qué? → Nunca se configuró → ¿Por qué? → No había proceso de revisión de infraestructura.
- Qué salió bien: Identificar respuestas efectivas y mecanismos que funcionaron para no eliminarlos.
- Action items: Lista específica de cambios a implementar, con dueño y fecha límite.
- Seguimiento: Revisar en 2-4 semanas si los action items se completaron.
Ejemplos reales en LATAM
- Caídas de plataformas de pago (múltiples países LATAM): Empresas como Transbank (Chile) y SIPAS han publicado post-mortems públicos después de caídas significativas, documentando causas raíz y compromisos de mejora de infraestructura.
- Startups de e-commerce en Black Friday: El pico de tráfico en Cyber Monday/Black Friday frecuentemente genera incidentes. Las mejores startups e-commerce de la región tienen protocolos de post-mortem que mejoran la preparación año tras año.
- Expansiones fallidas a nuevos mercados: Rappi y otras plataformas de delivery han realizado post-mortems internos de ciudades donde tuvieron que retirarse, extrayendo lecciones sobre product-market fit local y unit economics.
Post-mortem de Incidente vs Post-mortem de Proyecto
| Aspecto | Post-mortem de Incidente | Post-mortem de Proyecto |
|---|---|---|
| Trigger | Falla técnica, brecha, outage | Fin de proyecto/sprint, fracaso comercial |
| Urgencia | Dentro de 24-72 horas | En las semanas siguientes |
| Foco | Causa raíz técnica | Decisiones, proceso, estrategia |
| Audiencia | Equipo de ingeniería | Equipo cross-funcional |
Errores comunes
- Post-mortems con culpa: Si el post-mortem se centra en «quién hizo qué», las personas se ponen a la defensiva y la información real no emerge.
- Sin action items concretos: Un post-mortem que termina en «hay que tener más cuidado» no genera cambio real. Los action items deben ser específicos, asignados y con fecha.
- Hacerlo demasiado tarde: Los detalles se olvidan. Los post-mortems de incidentes deben hacerse dentro de las 24-72 horas del evento.
- No compartir los aprendizajes: Si el post-mortem queda en un documento que nadie lee, el conocimiento no se distribuye. Los mejores equipos los documentan en bases de conocimiento accesibles.
Preguntas Frecuentes (FAQ)
¿Con qué frecuencia hacer post-mortems?
Siempre después de cualquier incidente significativo (caída de producción, churn de cliente importante, fracaso de lanzamiento). Para proyectos regulares, al final de cada sprint mayor o proyecto trimestral.
¿Quién facilita el post-mortem?
Idealmente alguien que no estuvo directamente involucrado en el incidente, para evitar sesgos. En equipos pequeños, puede ser el CTO o un manager senior. Lo importante es que sea alguien comprometido con el proceso blameless.
¿Cuánto tiempo debe durar un post-mortem?
Para incidentes técnicos menores: 30-60 minutos. Para incidentes mayores o proyectos fallidos significativos: 2-4 horas, posiblemente dividido en varias sesiones.
