Análise de causa raiz em projetos: como fazer
O defeito foi corrigido, a entrega foi aceita e, duas semanas depois, o mesmo problema apareceu em outra entrega. Esse ciclo é o sinal mais claro de que o projeto trata sintomas. A análise de causa raiz existe para quebrá-lo: é a investigação que procura a origem do problema, aquela que, se eliminada, faz com que ele não volte.
Em projetos, a análise de causa raiz tem uma dificuldade a mais: o tempo. A equipe está pressionada pelo prazo, e parar para investigar parece luxo. Por isso o método precisa ser proporcional ao problema e chegar a ações concretas. O roteiro abaixo tem sete passos e serve tanto para um incidente pontual quanto para um problema crônico.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
O que é análise de causa raiz
Análise de causa raiz, também chamada de RCA (do inglês root cause analysis), é uma investigação estruturada que separa três níveis de explicação para um problema:
| Nível | O que é | Exemplo em projeto de TI |
|---|---|---|
| Sintoma | O que se vê | O sistema ficou fora do ar após a implantação |
| Causa imediata | O que provocou o sintoma diretamente | Um parâmetro de configuração foi publicado errado |
| Causa raiz | O que tornou a causa imediata possível | A configuração de produção é editada à mão, sem revisão nem teste |
Corrigir o parâmetro resolve o incidente. Só mudar a forma como a configuração é publicada impede o próximo. A análise de causa raiz é o trabalho de descer do sintoma até esse terceiro nível e confirmar, com evidência, que ele é de fato a origem.
Um problema pode ter mais de uma causa raiz, e também causas contribuintes, que não provocam o problema sozinhas mas aumentam sua chance ou seu impacto. Uma boa análise registra as duas.
Quando fazer análise de causa raiz no projeto
Nem todo problema merece uma investigação formal. Faça quando houver pelo menos um destes gatilhos:
- Recorrência: o mesmo problema apareceu mais de uma vez.
- Impacto alto: atraso em marco, multa contratual, incidente em produção, risco à segurança.
- Desvio relevante de indicador: prazo, custo ou qualidade fora da tolerância definida.
- Reclamação formal do cliente ou não conformidade apontada em auditoria.
- Lição aprendida importante: problema que outros projetos podem repetir.
Para problemas pequenos e isolados, basta corrigir e registrar. O esforço da análise deve ser proporcional ao custo de o problema voltar.
Como fazer análise de causa raiz em sete passos
1. Defina o problema com dados
Descreva o que aconteceu, onde, quando, com que frequência e qual o impacto. "A qualidade das entregas caiu" não serve. "Três das oito implantações do trimestre foram revertidas por falha em produção, com média de quatro horas de indisponibilidade" serve. Um problema bem definido já elimina metade das discussões.
2. Contenha o efeito
Antes de investigar, proteja o cliente e o projeto: reverta a mudança, isole o lote, faça a inspeção extra. A contenção não é a solução, mas evita que o problema cresça enquanto a análise acontece.
3. Reúna os fatos e monte a linha do tempo
Colete registros, logs, atas, e-mails, versões de documentos e depoimentos de quem estava envolvido. Ordene os eventos numa linha do tempo. Muitas causas aparecem só quando se vê a sequência: o que mudou pouco antes de o problema começar?
4. Levante as causas possíveis
Aqui entram as ferramentas de geração de hipóteses. Os 5 porquês funcionam bem quando o problema tem uma cadeia causal clara. O diagrama de Ishikawa é melhor quando há muitas causas possíveis em áreas diferentes. Monte a análise com quem conhece o processo, não só com a liderança.
5. Verifique as causas com evidência
Toda causa levantada é hipótese até ser confirmada. Para cada uma, pergunte: que dado mostraria que ela é verdadeira? Confira os registros, refaça o teste, compare situações em que o problema ocorreu e em que não ocorreu. Descarte as que os fatos não sustentam. Este é o passo mais pulado e o que mais separa uma análise séria de uma reunião de opiniões.
6. Defina ações sobre a causa raiz
Cada causa confirmada recebe pelo menos uma ação que a elimina ou reduz, com responsável, prazo e forma de verificar. Ações que só reforçam a atenção ("ter mais cuidado") não atacam causa nenhuma. Prefira mudanças no processo: padrão, checklist, automação, verificação independente, bloqueio.
7. Verifique a eficácia e registre o aprendizado
Defina antes como saber se a ação funcionou: o indicador que deve mudar e em quanto tempo. Depois do prazo, confira. Se o problema não voltou e o indicador melhorou, padronize a mudança e registre a lição para outros projetos. Se voltou, a causa raiz não era aquela, e a análise recomeça a partir do passo 4.
Ferramentas de análise de causa raiz e quando usar cada uma
| Ferramenta | Para que serve | Quando usar |
|---|---|---|
| 5 porquês | Descer pela cadeia causal perguntando "por quê?" | Problema com uma linha de causa clara |
| Diagrama de Ishikawa | Organizar muitas causas possíveis por categoria | Problema com várias origens possíveis |
| Diagrama de Pareto | Separar as poucas causas que explicam a maior parte das ocorrências | Muitas ocorrências registradas por tipo |
| Linha do tempo | Mostrar a sequência dos eventos | Incidentes, falhas pontuais, problemas com início definido |
| Análise de mudanças | Comparar a situação com e sem o problema | Algo funcionava e deixou de funcionar |
| Diagrama de dispersão | Testar a relação entre uma causa suspeita e o efeito | Há dados das duas variáveis |
| Árvore de falhas | Combinar causas com lógica "e" e "ou" | Falhas técnicas com várias condições simultâneas |
Para problemas com muitas ocorrências, o diagrama de Pareto costuma vir antes de tudo, para decidir qual tipo de problema investigar primeiro. Para reclamações formais de cliente, a análise geralmente é registrada num formato padronizado, como o relatório 8D.
Exemplo: implantações revertidas em produção
Contexto (exemplo ilustrativo). Uma equipe de TI de uma operadora de planos de saúde publica atualizações do portal do beneficiário a cada duas semanas. No último trimestre, três das oito implantações foram revertidas por falha em produção.
Problema definido: 3 de 8 implantações revertidas no trimestre, média de 4 horas de indisponibilidade, todas na janela de sexta-feira à noite.
Contenção: congelamento das implantações até a conclusão da análise, com exceção de correções críticas, que passaram a exigir aprovação do coordenador.
Linha do tempo: as três falhas aconteceram depois de mudanças em parâmetros de configuração; nenhuma delas envolveu erro no código testado.
Causas possíveis levantadas: configuração editada manualmente em produção; ambiente de homologação com parâmetros diferentes dos de produção; checklist de implantação sem item de configuração; implantação feita por pessoas diferentes a cada vez; janela curta, com pressão para terminar.
Verificação: a comparação entre os ambientes mostrou dezenas de parâmetros diferentes entre homologação e produção. Nas três falhas, o parâmetro errado era um desses. Nas cinco implantações bem-sucedidas, nenhuma mudança de configuração tinha sido feita. A hipótese da pressão de tempo não se sustentou: duas das falhas ocorreram em janelas sem nenhum atraso.
Causa raiz confirmada: a configuração de produção não é versionada nem testada; ela é editada à mão no momento da implantação, num ambiente diferente do que foi homologado.
Ações: versionar a configuração junto com o código; alinhar os parâmetros de homologação aos de produção; incluir a revisão das mudanças de configuração no checklist, feita por uma segunda pessoa. Verificação da eficácia: nenhuma reversão por configuração nas seis implantações seguintes.
Repare que "erro do analista que publicou" seria a resposta fácil e errada. Pessoas diferentes erraram da mesma forma, o que aponta para o processo.
Como escrever uma causa raiz que leve à ação
| Causa mal escrita | Problema | Causa bem escrita |
|---|---|---|
| Erro humano | Não diz o que mudar | Não há verificação independente antes de publicar a configuração |
| Falta de comunicação | Vaga demais | A mudança de requisito aprovada no comitê não é registrada na ferramenta usada pela equipe |
| Fornecedor atrasou | Descreve o evento, não a causa | O contrato não prevê marco intermediário de entrega nem penalidade por atraso |
| Equipe sem treinamento | Pode ser verdade, mas falta o porquê | O procedimento de medição mudou e não houve repasse para a equipe do canteiro |
Uma causa raiz bem escrita aponta para algo que o projeto ou a organização controla e pode mudar.
Erros comuns na análise de causa raiz
- Parar na primeira causa plausível. A pressa leva a escolher a explicação mais confortável.
- Procurar culpado. A investigação vira defesa, e as pessoas escondem informação.
- Não verificar as hipóteses. A causa "votada" na reunião nem sempre é a verdadeira.
- Ações genéricas. "Reforçar a atenção" não muda nada no processo.
- Não conferir a eficácia. Sem verificação, ninguém sabe se o problema foi resolvido ou só ficou quieto.
- Ignorar causas que se alimentam. Quando o problema volta mesmo depois de ações corretas, vale olhar o conjunto com o enfoque do pensamento sistêmico.
Do problema ao plano de ação
Escolha o problema que mais se repetiu no seu projeto nos últimos meses e aplique os passos 1 e 3 ainda nesta semana: defina o problema com números e monte a linha do tempo. Muitas vezes, só isso já mostra onde procurar. Com as causas confirmadas, organize as ações com responsável, prazo e custo na ferramenta gratuita de 5W2H da Projeto Diário. O guia de ferramentas da qualidade em projetos ajuda a escolher a ferramenta certa em cada etapa da análise.
