¿Qué hace bueno a un postmortem?

Un buen postmortem es sin culpables, específico y produce cambios. Contiene una línea de tiempo fiel, el impacto real en usuarios, cómo se detectó y mitigó el problema, y factores contribuyentes en vez de una única causa raíz. Las acciones son concretas, tienen dueño y se priorizan como cualquier otro trabajo, no son una lista de deseos. Se centra en por qué el sistema permitió el fallo, incluidos los huecos en las alertas y las salvaguardas, y no en quién tecleó el comando.

Sin culpables lo primero, y no como cortesía. Si la gente espera que la señalen, deja de contarte lo que pasó de verdad, y entonces tu línea de tiempo es ficción y no aprendes nada. Así que el encuadre siempre es por qué el sistema permitió esto, no quién lo hizo. En cuanto a contenidos, quiero una línea de tiempo honesta con marcas de tiempo, el impacto real en usuarios en números y no la palabra degradado, cuándo lo detectamos frente a cuándo empezó, y cuándo mitigamos frente a cuándo lo entendimos. Ese hueco entre el inicio y la detección suele ser lo más valioso del documento, y a menudo produce una acción mejor que arreglar el bug original. Evito la expresión causa raíz porque invita a pararse en la primera respuesta plausible; normalmente hay tres o cuatro factores contribuyentes y los interesantes son las salvaguardas que faltaban. Las acciones tienen que tener un nombre con una fecha, un tamaño honesto y un sitio en el backlog real. Un postmortem cuyas acciones nunca se planifican es peor que ninguno, porque enseña a la gente que el proceso es decorativo.