Fracassou. Por quê?

Daqui a seis meses o projeto fracassou. Escreva cada motivo como se já tivesse acontecido.

Confiamos no sandbox do fornecedor de pagamentos e nunca testamos contra os limites de produção. O tráfego do dia do lançamento derrubou o checkout.
Só a Priya entendia os scripts de migração de dados. Ela saiu de licença no terceiro mês e tudo parou.
O jurídico revisou os termos de uso duas semanas antes do lançamento e tivemos que refazer o fluxo de consentimento.
Sinais de alerta

O que perceberíamos primeiro se isso começasse a acontecer?

Chamados de suporte ao fornecedor levando mais de dois dias para ter resposta.
A mesma pessoa é marcada na revisão de todos os pull requests de migração.
Novos tickets aparecendo no meio da sprint com 'pedido rápido do comercial' na descrição.
Como evitamos isso

O que podemos fazer agora para impedir que isso aconteça?

Fazer um teste de carga no ambiente de produção do fornecedor na sprint dois, antes de construir em cima dele.
Colocar alguém para trabalhar em par com a Priya nos scripts de migração e documentar o runbook até o fim do mês.
Agendar a revisão jurídica do fluxo de consentimento durante o design, e não depois do desenvolvimento.
Responsáveis e próximos passos

Quem é responsável por cada risco principal, e até quando?

O Marco fica com o teste de carga do fornecedor, prazo no fim da sprint dois.
Vou trabalhar em par com a Priya na migração e vamos publicar o runbook até o dia 15.
A Dana vai agendar a revisão jurídica do fluxo de consentimento antes da aprovação do design, na próxima sexta.

O que é uma retrospectiva pré-mortem?

O pré-mortem é uma sessão de análise de riscos feita no kickoff do projeto, antes de escopo, prazos e orçamento serem fechados. O time imagina um futuro bem específico: daqui a seis meses, o projeto fracassou. Cada pessoa então escreve por que ele fracassou, como se o fracasso já tivesse acontecido. A técnica foi criada pelo psicólogo Gary Klein, que a descreveu em seu artigo de 2007 na Harvard Business Review, "Performing a Project Premortem". Ela se baseia em pesquisas sobre "retrospectiva prospectiva" (prospective hindsight), que mostraram que imaginar que um evento já ocorreu ajuda as pessoas a apontar motivos mais específicos para ele. O segredo está no enquadramento. Pergunte a um time "o que pode dar errado?" e você recebe respostas educadas e genéricas, como "aumento de escopo" ou "problemas de comunicação". Pergunte "por que deu errado?" e as pessoas apontam causas reais: a API do fornecedor que nunca passou por teste de carga, o stakeholder que não foi consultado, o único engenheiro que concentra todo o conhecimento. Tratar o fracasso como fato consumado também torna seguro expressar dúvidas que, em um kickoff otimista, poderiam soar negativas ou desleais. Este template de pré-mortem percorre quatro etapas no TeamRetro. Primeiro, liste os motivos pelos quais o projeto fracassou. Depois, identifique os sinais de alerta, combine as ações de prevenção e termine definindo um responsável e uma data para cada risco principal. Essa última etapa é a mais importante. Um risco sem responsável e sem prazo costuma ser esquecido antes do fim da primeira semana. Use ideias anônimas para que a hierarquia não influencie o que as pessoas escrevem e, em times distribuídos, colete as ideias de forma assíncrona ao longo de um dia e reúna-se apenas para votar e definir os responsáveis.

Formato da retrospectiva pré-mortem

Fracassou. Por quê?

Daqui a seis meses o projeto fracassou. Escreva cada motivo como se já tivesse acontecido.

Esta coluna é o coração do pré-mortem. Descreva bem o cenário: o projeto terminou, fracassou e todo mundo sabe disso. Peça que as pessoas escrevam no passado ("Perdemos o lançamento porque..."), já que esse enquadramento gera causas mais concretas do que especular sobre o que pode dar errado. Mantenha as ideias anônimas para que as vozes mais seniores não ditem o rumo da conversa. Dê de 8 a 10 minutos de escrita em silêncio, incentive um motivo por ideia e depois agrupe as ideias parecidas e vote para encontrar os principais riscos a levar adiante.

Sinais de alerta

O que perceberíamos primeiro se isso começasse a acontecer?

Os sinais de alerta transformam medos vagos em coisas que o time consegue acompanhar. Para cada risco principal da primeira coluna, pergunte qual seria o primeiro sinal observável: uma métrica, um checkpoint perdido, um padrão nas dailies. Insista em sinais específicos e mensuráveis. "A moral cai" é difícil de acompanhar. "Duas sprints seguidas com mais de 30% de itens não concluídos" é fácil de perceber. Esses sinais se tornam os gatilhos que os responsáveis pelos riscos vão monitorar.

Como evitamos isso

O que podemos fazer agora para impedir que isso aconteça?

É aqui que o time passa da preocupação para a ação. Foque apenas nos riscos mais votados, geralmente de três a cinco. Para cada um, pergunte o que o time pode fazer nesta semana ou neste mês para reduzir a probabilidade ou o impacto. Prefira passos pequenos e concretos a grandes mudanças de processo. Se uma ideia de prevenção depender de aprovação ou orçamento, anote a quem é preciso pedir. Mantenha o foco prático; o objetivo é uma lista menor de ações que as pessoas vão de fato executar.

Responsáveis e próximos passos

Quem é responsável por cada risco principal, e até quando?

Esta coluna é a razão de ser da sessão inteira. Cada risco principal precisa de um responsável nomeado e de uma data, senão os medos levantados hoje se perdem antes do fim da primeira semana. O responsável não precisa resolver o risco sozinho; ele cuida de acompanhar os sinais de alerta e garantir que a ação de prevenção aconteça. Registre cada um como uma ação no TeamRetro para que ela siga para as próximas retrospectivas e agende um check-in rápido no primeiro marco para revisar o andamento.

Quando utilizar esta análise retrospectiva

  • No kickoff de um novo projeto, lançamento de produto ou grande iniciativa, antes de escopo, prazos e orçamento serem definidos.
  • Antes de um marco de alto risco, como uma migração, um go-live ou a assinatura de um contrato, em que uma surpresa de última hora sairia cara.
  • Quando o time está otimista demais com um plano e os membros mais calados podem estar guardando dúvidas.
  • Ao começar a trabalhar com um novo fornecedor, parceiro ou grupo multifuncional cujas dependências ainda não estão bem compreendidas.
  • No início de um novo trimestre ou program increment, para testar o plano a fundo antes de o time se comprometer com ele.

Perguntas sugeridas para quebra-gelo

  • Qual foi o plano mais marcante que você viu dar errado, no trabalho ou na vida, e qual foi o primeiro sinal de alerta?
  • Se este projeto fosse um filme, qual seria o gênero da versão em que tudo dá errado?

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

Ideias e dicas para sua reunião de retrospectiva

  • Faça o pré-mortem no kickoff do projeto, antes de os compromissos serem fechados. Nunca o faça no meio de uma crise, quando o time precisa resolver problemas e imaginar o fracasso só aumenta a ansiedade.
  • Mantenha as ideias anônimas. Se os nomes aparecem, os medos da pessoa mais sênior ditam o rumo da conversa e o resto do time só concorda superficialmente.
  • Insista no tempo passado na primeira coluna. "Por que deu errado?" gera riscos mais específicos e realistas do que "O que pode dar errado?", então reformule com delicadeza as ideias que voltarem para o campo das hipóteses.
  • Vote para reduzir a lista a três a cinco riscos principais antes de discutir a prevenção. Tentar tratar todas as ideias dispersa o time e nada sai do papel.
  • Não encerre a sessão até que cada risco principal tenha um responsável e uma data. Sem isso, os riscos levantados são esquecidos antes do fim da primeira semana.
  • Para times distribuídos, trabalhe de forma assíncrona: colete as ideias ao longo de um dia, em diferentes fusos horários, e reúna-se por 30 minutos apenas para agrupar, votar e definir os responsáveis.

Perguntas frequentes

Qual é a diferença entre pré-mortem e post-mortem?
O post-mortem acontece depois que o projeto termina ou fracassa e analisa o que de fato deu errado. O pré-mortem acontece antes de o trabalho começar e imagina o fracasso com antecedência, para que o time possa evitá-lo enquanto ainda há tempo de agir.
Quem criou a técnica de pré-mortem?
O psicólogo Gary Klein criou o pré-mortem e o descreveu em seu artigo de 2007 na Harvard Business Review, "Performing a Project Premortem". A técnica se apoia em pesquisas que mostram que imaginar que um resultado já aconteceu ajuda as pessoas a identificar motivos mais específicos para ele.
Quanto tempo dura um pré-mortem?
A maioria dos pré-mortems leva de 45 a 60 minutos para um time de cinco a dez pessoas. Na opção assíncrona, a reunião ao vivo pode cair para cerca de 30 minutos, porque as ideias já foram coletadas antes.
Quando fazer um pré-mortem?
Faça no kickoff do projeto, antes de compromissos como escopo, prazos e orçamento serem fechados. Evite fazê-lo no meio de uma crise, quando o time precisa se concentrar em resolver problemas reais.
Por que as ideias do pré-mortem devem ser anônimas?
Quando os nomes aparecem, as pessoas tendem a repetir as preocupações da pessoa mais sênior da sala. Ideias anônimas trazem à tona os riscos que realmente preocupam as pessoas, inclusive os que envolvem decisões da liderança.
É possível fazer um pré-mortem de forma assíncrona?
Sim. Times distribuídos podem coletar ideias no TeamRetro ao longo de um dia e se reunir apenas para agrupar, votar nos riscos principais e definir responsáveis e datas.
Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva