O que faz um bom postmortem?

Um bom postmortem é sem culpados, específico e produz mudança. Ele contém uma linha do tempo precisa, o impacto real no usuário, como o problema foi detectado e mitigado, e fatores contribuintes em vez de uma única causa raiz. As ações são concretas, têm dono e são priorizadas como qualquer outro trabalho, não uma lista de desejos. Ele foca em por que o sistema permitiu a falha, incluindo lacunas de alerta e de proteções, e não em quem digitou o comando.

Sem culpados primeiro, e não como gentileza. Se as pessoas esperam ser apontadas, elas param de te contar o que realmente aconteceu, e aí a sua linha do tempo é ficção e você não aprende nada. Então o enquadramento é sempre por que o sistema deixou isso acontecer, não quem fez. Sobre conteúdo, eu quero uma linha do tempo honesta com horários, o impacto real no usuário em números e não na palavra degradado, quando a gente detectou versus quando começou, e quando a gente mitigou versus quando a gente entendeu. Aquela distância entre início e detecção costuma ser a coisa mais valiosa do documento, e frequentemente gera uma ação melhor que consertar o bug original. Eu evito a expressão causa raiz porque ela convida as pessoas a pararem na primeira resposta plausível; normalmente há três ou quatro fatores contribuintes e os interessantes são as proteções que faltavam. As ações precisam ter um nome como dono e uma data, tamanho honesto, e entrar no backlog de verdade. Um postmortem cujas ações nunca são agendadas é pior que nenhum, porque ensina às pessoas que o processo é decorativo.