Quase toda equipe faz um post-mortem quando um projeto dá errado. Muito menos equipes fazem a reunião que poderia ter salvado o projeto: um pre-mortem, antes de o trabalho começar. Uma reunião é o espelho da outra. O pre-mortem imagina que o projeto já fracassou e pergunta por quê. O post-mortem olha para um projeto que já terminou e pergunta o que de fato aconteceu.
Este guia trata dos dois: o que é cada um, como conduzir cada reunião e as vinte perguntas que usamos em ambas. Fazer as mesmas perguntas no início e no fim é justamente a ideia. Quando o projeto termina, dá para ver quais problemas a equipe previu, quais ela previu e enfrentou mesmo assim, e quais ninguém imaginou.
Pre-mortem e post-mortem lado a lado
| Pre‑mortem | Post‑mortem | |
|---|---|---|
| Quando | Depois que o plano está pronto, antes de o trabalho começar | Depois da entrega, ou depois de um marco importante ou de um incidente |
| Ponto de partida | “Faz um mês que o prazo venceu, e o projeto fracassou.” | O projeto como ele realmente foi |
| A pergunta | Por que ele fracassou? | O que aconteceu e por quê? |
| Quem participa | As pessoas que vão fazer o trabalho e o responsável pelo plano | A equipe, mais as partes interessadas que conviveram com o resultado |
| O que você obtém | Uma lista de riscos priorizada e mudanças no plano | Lições aprendidas e itens de ação para o próximo projeto |
| Duração | Cerca de uma hora | Uma a duas horas, mais o tempo de reunir os fatos |
O que é um pre-mortem?
O pre-mortem é uma reunião de planejamento em que a equipe parte do princípio de que o projeto já fracassou e descobre por quê. O psicólogo Gary Klein descreveu a técnica no artigo “Performing a Project Premortem” (em inglês), na edição de setembro de 2007 da Harvard Business Review.
O segredo está na forma de perguntar. Perguntar “o que pode dar errado?” rende algumas ressalvas educadas, porque ninguém quer parecer pessimista sobre um plano que a equipe acabou de aprovar. Dizer “fracassou, me diga por quê” faz da busca por problemas a tarefa de todos, e quem tinha dúvidas finalmente tem um motivo para falar. Klein cita um estudo de 1989 de Deborah Mitchell, Jay Russo e Nancy Pennington segundo o qual imaginar que um evento já aconteceu, o que eles chamaram de prospective hindsight, aumenta em 30% a capacidade de identificar corretamente os motivos de resultados futuros.
Como fazer um pre-mortem
- Escolha o momento. Faça a reunião quando o plano estiver pronto, mas antes de o trabalho começar: tarde o bastante para haver algo concreto a analisar, cedo o bastante para mudar o plano.
- Convide quem vai fazer o trabalho. Essas pessoas sabem onde o plano é frágil. Se um cliente ou outro departamento puder afundar o projeto, chame alguém que os conheça bem.
- Monte o cenário. Escolha uma data depois do prazo e descreva o fracasso sem rodeios: “Estamos em março. O novo site foi lançado com seis semanas de atraso e acima do orçamento, e o cliente está conversando com outras agências.”
- Escreva primeiro, sozinho. Dê a todos cinco minutos para listar, em silêncio, todos os motivos que conseguirem imaginar. Escrever antes de falar evita que a primeira voz, ou a mais sênior, defina a pauta.
- Faça uma rodada. Cada pessoa lê um motivo por vez, até que todos estejam na lista compartilhada. Não discuta os motivos ainda; apenas registre.
- Priorize e escolha. Junto com a equipe, marque os motivos que são ao mesmo tempo prováveis e graves. A maioria das equipes termina com três a cinco que merecem alguma ação.
- Mude o plano. Cada risco escolhido vira uma mudança com responsável e data: um prazo mais cedo para os textos, um segundo aprovador, uma conversa de alinhamento com o cliente. Deixe a lista onde você vai vê-la de novo a cada marco.
O que é um post-mortem?
O post-mortem é uma análise feita depois que um projeto termina, para entender o que aconteceu e o que mudar da próxima vez. Dependendo da equipe, ele também é chamado de retrospectiva, reunião de lições aprendidas ou revisão pós-ação (after action review). E não serve só para os fracassos: um projeto que deu certo também deixa lições, e é mais fácil falar delas.
O que faz um post-mortem funcionar é não procurar culpados. O livro Site Reliability Engineering do Google (em inglês), que trata o post-mortem como uma prática central, diz que, para ser de fato livre de culpa (blameless), um post-mortem precisa se concentrar em identificar as causas que contribuíram para o incidente, sem acusar nenhuma pessoa ou equipe. O livro também lembra que a cultura sem culpa nasceu na saúde e na aviação, setores em que os erros podem ser fatais. Se as pessoas esperam ser culpadas, elas defendem as próprias decisões em vez de explicá-las, e a reunião não ensina nada.
Como fazer um post-mortem
- Faça logo. Uma ou duas semanas depois da entrega, enquanto as pessoas ainda lembram por que tomaram as decisões que tomaram.
- Reúna os fatos antes. Antes da reunião, monte a linha do tempo: datas planejadas x reais, orçamento previsto x realizado e as decisões que mudaram o rumo. Se o projeto foi gerenciado no Redbooth, as listas de tarefas, os prazos e os comentários já guardam a maior parte desse registro.
- Abra com a regra básica. Diga em voz alta que o objetivo é corrigir o processo, não descobrir de quem é a culpa.
- Comece pela lista do pre-mortem. Passe por ela primeiro: quais riscos a equipe evitou, quais aconteceram mesmo assim e o que ninguém previu. Essa comparação é a forma mais honesta de medir se a equipe planeja bem.
- Percorra as quatro categorias abaixo, falando tanto do que deu certo quanto do que deu errado.
- Termine com itens de ação, não com observações. Cada um ganha um responsável e um lugar onde o próximo projeto vai encontrá-lo, como o plano desse projeto ou o pre-mortem dele.
As 20 perguntas para as duas reuniões
Agrupamos as perguntas em quatro categorias: planejamento, execução, resultados e comunicação. As perguntas são as mesmas nas duas reuniões; só o tempo verbal muda. No pre-mortem, você pergunta por que a equipe não vai atingir o objetivo principal, e no post-mortem, por que ela não atingiu.
Planejamento
- Plano do projeto: O que está faltando no plano? Quais partes estão vagas?
- Recursos: Dimensionamos e alocamos pessoas, orçamento e ferramentas corretamente?
- Prazos: Os prazos são realistas e ligados a objetivos específicos? Há margem para atrasos inesperados?
- Tarefas: Todas as tarefas necessárias estão planejadas, com as dependências e as entregas bem definidas?
- Documentação: A forma como documentamos as decisões e o trabalho é boa o suficiente?
Execução
- Atrasos: Como podemos lidar melhor com atrasos inesperados?
- Fluxo de trabalho: Onde estão os pontos fracos na passagem do trabalho de uma pessoa para outra?
- Pessoas: Como deixar os papéis e as responsabilidades claros e consistentes?
- Tarefas: O que dificulta concluir as tarefas no dia a dia?
- Gestão: Em que pontos a gestão atrapalha o trabalho?
Resultados
- Objetivo principal: Por que não vamos atingir (não atingimos) o nosso objetivo principal?
- Objetivos secundários: Por que não vamos atingir (não atingimos) os outros?
- Qualidade: Em que o nosso trabalho vai ficar (ficou) abaixo da qualidade prometida?
- Desempenho externo: Por que o cliente está insatisfeito? O que há de errado na forma como medimos o sucesso com ele?
- Desempenho interno: O que há de errado na forma como medimos o sucesso internamente?
Comunicação
- Canais: Quais são as desvantagens dos principais meios que usamos para nos comunicar?
- Equipe: Que dificuldades de comunicação os membros da equipe vão ter (tiveram)?
- Gestores: Que dificuldades de comunicação os gestores vão ter (tiveram)?
- Reuniões: O que há de errado na forma como fazemos reuniões?
- Partes interessadas: Onde a nossa comunicação com as partes interessadas vai falhar (falhou)?
Responda com fatos, não com veredictos. “O plano era ruim” não ajuda ninguém. “O plano não reservou tempo para a revisão do jurídico do cliente, que levou nove dias” ajuda.
Exemplo: o relançamento de um site, antes e depois
Veja como as duas reuniões se encaixam, com um projeto fictício: uma equipe de marketing relançando o site da empresa, com oito semanas até o lançamento.
O pre-mortem. No kickoff, a equipe imagina que é o dia do lançamento e o novo site não está no ar. Entre os motivos que ela lista:
- As páginas de produto dependiam de textos de três departamentos, e os textos atrasaram.
- O jurídico revisou a nova página de privacidade na última semana e pediu mudanças.
- Ninguém cuidava dos redirecionamentos das URLs antigas, e o tráfego orgânico caiu depois do lançamento.
- O CEO viu o layout pela primeira vez na semana 7.
Cada um entra no plano como uma tarefa com responsável: os textos com prazo duas semanas antes do code freeze, a revisão do jurídico agendada para a semana 4, um mapa de redirecionamentos para o desenvolvedor e uma revisão de quinze minutos do layout com o CEO na semana 2.
O post-mortem. O site é lançado com uma semana de atraso. Começando pela lista do pre-mortem, a equipe descobre que:
- Evitado: os redirecionamentos estavam prontos no dia do lançamento, a revisão do jurídico coube na semana 4 e o feedback do CEO chegou a tempo de ser usado.
- Previsto, mas aconteceu mesmo assim: os textos de um departamento atrasaram de novo, porque o responsável estava de férias e ninguém mais tinha sido designado.
- Ninguém previu: as licenças das novas fotos da página inicial só foram aprovadas na semana do lançamento.
Os itens de ação saem daí: cada entrega ganha um responsável substituto, e “imagens e licenças” passa a ser um item fixo no próximo pre-mortem.
Faça os dois no Redbooth com o modelo gratuito
O nosso modelo Project Post-mortem Analysis (em inglês) coloca as vinte perguntas em um espaço de trabalho do Redbooth: uma lista de tarefas por categoria e uma tarefa por pergunta.
Uma forma de usá-lo ao longo de um projeto:
- No kickoff, abra o modelo, clique em Create Workspace e faça o pre-mortem no novo espaço de trabalho. Você precisa estar logado no Redbooth; se ainda não tiver uma conta, crie uma antes. Registre cada motivo como subtarefa da pergunta que ele responde e adicione os riscos que decidir tratar ao espaço de trabalho do próprio projeto, como tarefas com responsável e prazo.
- Durante o projeto, mantenha o espaço de trabalho. Uma olhada rápida a cada marco mostra se os riscos que a equipe priorizou estão sob controle.
- No fim, reabra o espaço de trabalho para o post-mortem. Ao lado de cada resposta do pre-mortem, anote o que de fato aconteceu e depois acrescente os itens de ação para o próximo projeto.
Como o espaço de trabalho fica guardado, o pre-mortem do próximo projeto pode partir das lições do anterior em vez de uma página em branco.
Erros que tornam as duas reuniões inúteis
- Fazer o pre-mortem depois que o plano está fechado. Se nada pode mudar, as pessoas param de apontar problemas.
- Deixar a pessoa mais sênior falar primeiro. Todo mundo ajusta a própria lista para combinar com a dela. Escreva sozinho primeiro.
- Procurar culpados. O próximo post-mortem vai ser mais curto, mais educado e mais vazio.
- Itens de ação sem responsável. “Precisamos nos comunicar melhor” não é um item de ação.
- Nunca reler o último post-mortem. Lições que ninguém lê no próximo kickoff não são lições. Faça do último post-mortem o primeiro item da pauta do próximo pre-mortem.
Perguntas frequentes
O pre-mortem é a mesma coisa que uma análise de riscos?
Não, embora alimente uma. O registro de riscos lista e acompanha os riscos conhecidos ao longo de todo o projeto. O pre-mortem é uma única reunião, pensada para trazer à tona os riscos que ninguém anotou ainda, principalmente aqueles que as pessoas relutam em mencionar. O que ele encontrar pode então entrar no registro.
Qual a diferença entre post-mortem e retrospectiva?
Principalmente o escopo. Equipes ágeis fazem uma retrospectiva no fim de cada sprint, para ajustar a forma de trabalhar ao longo do caminho. O post-mortem olha para um projeto inteiro, ou para um único incidente, depois que ele termina. As perguntas são parecidas.
Quanto tempo deve durar cada reunião?
Cerca de uma hora basta para a maioria dos pre-mortems. Um post-mortem costuma precisar de uma a duas horas, mais o tempo de montar a linha do tempo antes.
Vale a pena fazer um post-mortem quando o projeto dá certo?
Sim. Um sucesso também tem causas, e saber quais delas dá para repetir é tão útil quanto saber o que evitar. Além disso, é o jeito mais fácil de fazer do post-mortem um hábito, e não um castigo.
Comece pelo próximo projeto da sua lista: reserve uma hora antes do kickoff e copie o modelo (em inglês) para um espaço de trabalho que guarde as respostas.