Modelo de Post-Mortem de Projeto

Revise qualquer projeto ou incidente e registre aprendizados

Experimente esta apresentação ao vivo retrospectiva

Visão geral, objetivos e escopo do projeto

O que o projeto pretendia fazer, e até quando?

O objetivo era migrar todo o faturamento de clientes para a nova plataforma até o fim do Q3, sem indisponibilidade para contas enterprise.
Entregamos o portal do cliente três semanas depois da data original, com duas das cinco funcionalidades planejadas cortadas.
Os critérios de sucesso nunca foram escritos em nenhum lugar que eu pudesse encontrar, então eu tinha minha própria versão na cabeça.
O que foi bem

Quais conquistas e processos vale repetir?

Sincronizações diárias de quinze minutos durante o período de aperto mantiveram todos alinhados sem aumentar a carga de reuniões.
Nosso runbook de plantão estava correto, o que fez a correção levar minutos em vez de horas para ser aplicada.
Pareá os desenvolvedores novos com revisores desde o início os deixou produtivos mais rápido do que eu esperava.
O que não foi bem

Onde travamos, quebramos ou perdemos metas?

Os requisitos mudavam constantemente e ninguém era claramente responsável por decidir quando estavam finalizados.
Os testes foram comprimidos nos últimos dias, e é por isso que dois defeitos chegaram aos clientes.
Nosso monitoramento não cobria a profundidade da fila, então ficamos cegos até que as coisas já tivessem acumulado.
Análise de causa-raiz

Por que deu errado, e não apenas que deu?

A causa-raiz foi uma mudança de configuração implantada direto em produção porque nosso pipeline não tinha uma etapa obrigatória de revisão.
Subestimamos porque a estimativa foi feita antes do spike técnico e depois tratada como compromisso.
Ninguém era responsável pela integração entre os dois times, então a lacuna ficou invisível até a semana de integração.
Lições aprendidas

Quais são os principais aprendizados que levamos adiante?

Fazer o spike técnico antes de nos comprometermos com qualquer data e então re-estimar abertamente.
Escrever os critérios de sucesso no kickoff. Se não conseguimos concordar sobre eles, não estamos prontos para começar.
Mudanças de escopo precisam de um checkpoint escrito em vez de serem silenciosamente absorvidas pelo time.
Itens de ação, responsáveis e prazos

Quem faz o quê, e até quando?

Adicionar uma etapa obrigatória de revisão ao pipeline de deploy em produção. Responsável: Priya. Prazo: fim da próxima sprint.
Rascunhar um modelo de project charter de uma página com critérios de sucesso. Responsável: Sam. Prazo: dia 15.
Adicionar alertas de profundidade de fila e taxa de erro direcionados à escala de plantão. Responsável: Dev. Prazo: esta semana.
Reconhecimento e kudos ao time

Quem merece reconhecimento antes de encerrarmos?

Obrigado à Priya por manter a calma na call de crise e manter todos focados na correção.
Kudos à equipe de suporte que absorveu os contatos dos clientes praticamente sem aviso.
Grande reconhecimento ao Sam, que discretamente escreveu o runbook que ninguém pediu e depois nos salvou com ele.

O que é uma retrospectiva post-mortem?

Um post-mortem é a conversa que seu time tem depois que algo termina. Às vezes esse algo é um incidente: um sistema quebrou, uma release saiu dos trilhos, um cliente sentiu a dor. Com a mesma frequência, é um projeto comum que simplesmente foi concluído e você quer um modelo de postmortem claro para conduzir a reunião de revisão sem inventar uma agenda do zero. Este formato atende aos dois casos. Você define o enquadramento com os objetivos e o escopo do projeto, percorre o que foi bem e o que não foi, investiga as causas-raiz onde isso importa e transforma as partes honestas em lições aprendidas que sua organização realmente consegue reutilizar. Veja como funciona no TeamRetro. Todos adicionam suas próprias observações de forma privada primeiro, para que a voz mais alta da sala não defina a narrativa antes de as pessoas mais quietas terem escrito qualquer coisa. As ideias são então agrupadas, discutidas e votadas, o que permite priorizar o punhado de temas que realmente importa em vez de mastigar quarenta comentários sem ordem alguma. Essa é a diferença entre isso e um modelo de post mortem estático que você preenche sozinho: é um debrief de time ao vivo que todo o grupo conduz junto, e termina com responsáveis e prazos ligados a ações reais em vez de um documento que ninguém abre novamente. Use-o como sua revisão de projeto padrão no encerramento de uma entrega, uma campanha, uma migração ou um trimestre, e como sua revisão de incidente quando algo deu errado e você precisa de um relato sem culpados sobre a linha do tempo e suas causas. O último tópico abre espaço para os kudos, porque reconhecer as pessoas que carregaram o trabalho faz parte de encerrá-lo adequadamente. De qualquer forma, o objetivo é o mesmo. Você quer que o time saia sabendo o que repetir, o que parar de fazer e quem faz o quê em seguida. Seu relatório é exportado automaticamente, então as lições aprendidas continuam pesquisáveis para o próximo time que entrar na mesma situação.

Formato da retrospectiva post-mortem

Visão geral, objetivos e escopo do projeto

O que o projeto pretendia fazer, e até quando?

Este tópico define o enquadramento antes que alguém julgue qualquer coisa. Peça o objetivo original, o escopo acordado, o cronograma e os critérios de sucesso, além do que foi realmente entregue em relação a eles. Para uma revisão de incidente, use-o para os fatos da linha do tempo: o que quebrou, quando foi detectado, quem estava envolvido e como foi resolvido. Mantenha interpretações fora desta coluna e deixe as opiniões para os tópicos seguintes. Se as pessoas discordarem sobre quais eram os objetivos ou critérios de sucesso, essa discordância já é em si um achado que vale registrar.

O que foi bem

Quais conquistas e processos vale repetir?

Os times passam correndo por este tópico, especialmente depois de um projeto difícil ou de um incidente estressante, então proteja o tempo dele. Você está buscando práticas repetíveis, não elogios, e os kudos têm um tópico próprio mais adiante. Quando alguém publicar um elogio, pergunte o que especificamente fez aquilo funcionar, para que a resposta possa ser reutilizada. Fique atento a conquistas que vieram de heroísmos individuais e nomeie-as como riscos, não como sucessos.

O que não foi bem

Onde travamos, quebramos ou perdemos metas?

É aqui que está o valor real, então estabeleça em voz alta a regra do sem culpados antes de começar: você está examinando sistemas e decisões, não pessoas. Incentive especificidades em vez de reclamações vagas, já que "a comunicação foi ruim" não pode gerar ação, mas "soubemos da mudança de prazo em uma conversa de corredor" pode. Use a votação aqui para evitar que a discussão se espalhe por cada irritação dos últimos três meses.

Análise de causa-raiz

Por que deu errado, e não apenas que deu?

Opcional para uma revisão de projeto simples, essencial para um incidente. Pegue os problemas mais votados do tópico anterior e continue perguntando por quê até chegar a uma condição em vez de a uma pessoa: uma proteção ausente, um responsável indefinido, uma pressão de cronograma, uma premissa que ninguém testou. Os Cinco Porquês funcionam bem aqui, assim como perguntar o que fez a ação errada parecer razoável na hora. Pare quando chegar a algo que você realmente pode mudar e registre os fatores contribuintes separadamente do gatilho.

Lições aprendidas

Quais são os principais aprendizados que levamos adiante?

Este é o "e daí" que transforma observações em conhecimento reutilizável. Pressione cada ideia até que ela nomeie um comportamento, um gatilho ou uma proteção, para que sobreviva ao contato com o próximo projeto. Distinga entre coisas que este time pode mudar por conta própria e coisas que precisam subir para um gestor ou outro grupo, e seja honesto sobre a segunda categoria. Formule os aprendizados de modo que alguém de fora da sala possa lê-los no relatório exportado e entendê-los sem você lá para explicar.

Itens de ação, responsáveis e prazos

Quem faz o quê, e até quando?

Um post-mortem sem ações atribuídas não vale, então reserve tempo real para isso em vez de espremê-lo nos últimos dois minutos. Converta os aprendizados mais votados em um pequeno número de ações específicas, cada uma com um responsável nomeado e um prazo registrado no TeamRetro para que apareçam na próxima sessão. Duas ou três ações bem apropriadas valem mais do que dez aspiracionais. Se uma ação pertence a alguém de fora da sala, combinem quem vai levá-la a essa pessoa e até quando.

Reconhecimento e kudos ao time

Quem merece reconhecimento antes de encerrarmos?

Encerre com as pessoas, não com os problemas. Convide todos a nomear uma pessoa específica e algo específico que ela fez, o que é muito mais significativo do que agradecimentos genéricos e funciona bem até depois de um projeto difícil. Isso importa mais quando a revisão foi dura, porque lembra ao time que examinar uma falha não é o mesmo que se culpar mutuamente. Mantenha rápido, leia alguns em voz alta e deixe o relatório exportado carregar o resto.

Quando utilizar esta análise retrospectiva

  • Um projeto, entrega, migração ou campanha acabou de terminar e você quer uma revisão de projeto estruturada em vez de uma conversa informal que se dissolve.
  • Um incidente, indisponibilidade ou release falha precisa de um post-mortem sem culpados cobrindo a linha do tempo, as causas-raiz e as ações preventivas.
  • Um programa de longa duração concluiu uma fase e você quer registrar as lições aprendidas enquanto os detalhes ainda estão frescos.
  • Um grupo multifuncional está se desfazendo e esta é sua última chance de fazer um debrief de time e reconhecer os contribuidores antes que as pessoas se espalhem por novos trabalhos.
  • Algo foi inesperadamente bem e você quer entender por quê, para que a prática possa ser repetida em vez de tratada como sorte.

Perguntas sugeridas para quebra-gelo

  • Em uma palavra, como você se sentiu durante este projeto ou incidente?
  • Se você pudesse enviar uma frase de conselho para você mesmo no primeiro dia, o que ela diria?

Quer um exercício de aquecimento em que sua equipe participe ativamente, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

  • Faça a sessão dentro de uma ou duas semanas após o encerramento do projeto ou a resolução do incidente. As memórias desaparecem rápido e os detalhes úteis vão com elas.
  • Enuncie a regra do sem culpados no início. Você está olhando decisões, sistemas e pressões, não procurando alguém para responsabilizar.
  • Gaste alguns minutos acordando a visão geral do projeto antes que as opiniões comecem. Um enquadramento comum evita que a sessão se torne um debate sobre qual era o objetivo.
  • Pule ou encurte a análise de causa-raiz em uma revisão de projeto tranquila, e aprofunde-a em incidentes onde a prevenção é o ponto central.
  • Priorize com votação e não deixe a reunião terminar sem responsáveis e prazos nas principais ações, senão suas lições aprendidas ficam teóricas.
  • Traga as ações do post-mortem anterior para a sala e revise-as primeiro. Nada melhora o acompanhamento como saber que será verificado.

Perguntas frequentes

O que é um post-mortem de projeto?
Um post-mortem de projeto é uma revisão estruturada que seu time conduz quando um trabalho é concluído, seja o lançamento de um produto, uma migração, uma campanha ou uma entrega para cliente. Você olha os objetivos e o escopo originais, o que foi bem, o que não foi e as lições aprendidas que valem levar adiante. Diferente de um postmortem de incidente, nada necessariamente deu errado. O gatilho é simplesmente que o trabalho terminou e há conhecimento que vale preservar.
Como um post-mortem de projeto difere de um post-mortem de incidente?
O formato é parecido, mas o foco é diferente. Um post-mortem de incidente é disparado por uma falha, então se apoia bastante na reconstrução da linha do tempo, na detecção, na resposta e na análise de causa-raiz, tendo a prevenção como objetivo. Um post mortem de projeto é disparado pela conclusão, então cobre objetivos, estimativa, escopo, colaboração, handover e entrega, tendo a melhoria no próximo projeto como objetivo. Ambos devem ser sem culpados e ambos precisam terminar em ações com responsáveis.
O que incluir em um post-mortem de projeto?
Comece com a visão geral do projeto: objetivos, escopo, cronograma, critérios de sucesso e o que foi realmente entregue. Depois cubra o que foi bem, o que não foi bem e as causas-raiz dos problemas que mais importam. Termine com lições aprendidas, itens de ação com responsáveis e prazos, e uma rodada de kudos ao time. Todos os sete tópicos cabem em uma sessão do TeamRetro, e a votação ajuda a priorizar em vez de sair com quarenta observações sem ordem.
Preciso usar o tópico de análise de causa-raiz?
Não, ele é opcional. Ele se justifica em revisões de incidentes e indisponibilidades, onde entender por que algo falhou é todo o objetivo, e em projetos que ficaram muito longe de metas importantes. Para uma entrega tranquila, você pode pulá-lo, ou simplesmente pegar os dois problemas mais votados e perguntar por quê algumas vezes antes de seguir para as lições aprendidas.
Quanto tempo leva um post-mortem?
Reserve de sessenta a noventa minutos para a maioria dos projetos e incidentes. Incidentes contidos ou projetos pequenos podem ser revisados em quarenta e cinco minutos se você pular a análise de causa-raiz. Programas grandes muitas vezes precisam de duas horas ou de duas sessões, uma para a visão geral factual e as causas e outra para melhorias e ações. Como todos fazem o brainstorming em paralelo no TeamRetro, a fase de coleta fica curta.
Quem deve participar de um post-mortem?
Inclua as pessoas que fizeram o trabalho e as pessoas afetadas por ele: o time de entrega, o líder de produto ou de projeto e representantes de suporte, design ou operações que herdaram o resultado. Para um incidente, inclua os respondentes, o pessoal de plantão e quem cuidou da comunicação com clientes. Mantenha o grupo pequeno o suficiente para uma conversa honesta e oriente eventuais participantes seniores a ouvir em vez de defender decisões.

Modelos relacionados

Retrospectiva de Fim de Ano

Reflita sobre as conquistas, desafios e aprendizados do ano.

Retrospectiva Pós-Lançamento

Analise sucessos, desafios e melhorias após lançamentos.

Revisão de Fim de Ano Fiscal

Avalie o desempenho financeiro e planeje o próximo ano.

Planejamento de Início de Projeto

Alinhe a equipe nos objetivos do projeto e planeje a execução.

Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva