5 Porquês: Análise de Causa Raiz

Formato de retrospectiva 5 Porquês

Descrição do problema

O que exatamente aconteceu, onde e quando?

Combine uma única descrição do problema antes que alguém adicione uma causa, e mantenha-a em um só cartão. Seja específico: o que aconteceu, onde, quando e qual o tamanho, sem tentar adivinhar a causa. "O release 4.2 saiu com dois dias de atraso" dá ao time algo sobre o que perguntar por quê. "Os releases são uma bagunça" não dá.

O que sabemos

Quais fatos e dados descrevem o problema?

Reúna os fatos antes das causas, como linhas do tempo, métricas, logs, relatos de clientes e o que mudou recentemente. Cada resposta na cadeia de porquês deve se apoiar em algo daqui ou em algo que o time possa verificar. Se faltar um fato, anote e transforme a busca por ele em uma ação.

Por que aconteceu?

O que causou o problema diretamente?

Cada cartão aqui é um primeiro porquê, uma causa direta da descrição do problema. Mantenha as respostas no que aconteceu, não em quem. Depois de agrupar, votem na causa que mais provavelmente explica o problema. Na fase de discussão, abra o cartão mais votado e faça os próximos quatro porquês como uma sequência de comentários, com cada resposta sendo uma réplica à anterior. Se duas respostas fizerem sentido no mesmo nível, responda duas vezes ao mesmo comentário e siga cada ramificação.

Quando utilizar esta retrospectiva

• Um problema continua voltando depois de corrigido, e você quer encontrar a causa que a última correção não resolveu.
• Depois de um incidente, um defeito que escapou ou um prazo perdido, quando o time precisa entender o porquê antes de decidir o que mudar.
• Um item de uma retrospectiva recebeu a maioria dos votos e merece uma análise de verdade em uma sessão própria.
• O problema parece ter uma linha principal de causa e efeito. Se ele tiver muitas causas contribuintes, mapeie-as primeiro com um diagrama de Ishikawa.

Perguntas sugeridas para quebra-gelo

• Qual pequena correção que você fez já resolveu um problema muito maior?
• O que você só entendeu depois de perguntar por quê mais de uma vez?

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

• Combine a descrição do problema em voz alta antes do brainstorm e adicione-a como o único cartão em Descrição do problema. O modelo configura o brainstorm para mostrar as ideias imediatamente, então todos veem cada cartão assim que ele é adicionado. Você pode mudar isso nas configurações da reunião.
• O modelo configura a fase de discussão para discutir todos os itens, assim a descrição do problema e os fatos ficam na tela ao lado da causa mais votada. Você pode mudar isso nas configurações da reunião.
• Conduza a cadeia como uma sequência de comentários na causa mais votada. Esse cartão é o primeiro porquê. Adicione um comentário respondendo "Por que isso aconteceu?", responda a ele com a próxima resposta e continue respondendo. As respostas se aninham em até três níveis, então o cartão, um comentário e três respostas somam cinco porquês.
• Pare quando chegar a uma causa que o time consiga mudar, seja com três porquês ou com sete. Se precisar de um sexto, adicione um novo comentário no cartão que continue a partir da última resposta.
• Pergunte sobre o processo, não sobre a pessoa. Se uma resposta cair em "alguém errou", pergunte por que o processo deixou esse erro passar.
• Transforme a causa raiz em uma contramedida. Abra o menu da última resposta, escolha Copiar para ação e defina um responsável e um prazo para a ação. Revise-a na fase de ações em aberto de uma retrospectiva futura para verificar se a correção funcionou.

Perguntas frequentes