O que são as regras dos porques
As regras dos porques, mais conhecidas como técnica dos 5 porquês, são um método de análise de causa raiz desenvolvido originalmente pela Toyota nos anos 1950. A premissa é simples: você faz a pergunta "por quê?" repetidamente sobre um problema até chegar à origem real dele, e não apenas aos sintomas.
Como funciona na prática
O processo começa com uma declaração clara do problema. Não adianta ser vago. Se você começar com "o sistema caiu", os próximos porquês vão levar a conclusões genéricas e inúteis. Em vez disso, escreva algo como "o sistema caiu às 14h32 durante o processamento do lote B". Isso muda tudo. Você anota o problema e pergunta por que ele aconteceu. A resposta que você der vira a base para a próxima pergunta. Geralmente, em cinco iterações, você chega a uma causa que pode ser endereçada com uma ação concreta. Às vezes leva três. Às vezes precisa de oito. O número cinco é uma convenção, não uma lei.
Exemplo real. Um cliente meu reportou que os relatórios gerenciais chegavam atrasados toda segunda-feira. Primeiro porquê: porque o processamento do arquivo CSV trava no meio. Segundo porquê: porque o arquivo contém dados duplicados que o script não espera. Terceiro porquê: porque o módulo de importação do ERP não faz deduplicação automática. Quarto porquê: porque essa validação nunca foi implementada na versão atual do sistema. Quinto porquê: porque o requisito original pedia apenas importação bruta, sem regras de qualidade de dados. A causa raiz não era o script nem a segunda-feira. Era um requisito mal definido em 2019 que ninguém revisou depois.
A aplicação correta das regras dos porques
O erro mais comum que eu vejo é as pessoas tratarem cada resposta como isolada. O exercício só funciona se cada porquê depender logicamente do anterior. Se na terceira iteração você mudar de tema ou criar uma nova linha de investigação paralela, a cadeia se quebra e você está fazendo outra coisa, não análise de causa raiz. Outro problema frequente é parar cedo demais. "Por que o servidor caiu? Porque esgotou a memória." OK. Isso é uma causa imediata, não uma causa raiz. Você precisa continuar perguntando até a resposta não for mais acionável com ajuste operacional. Se a resposta for "porque a equipe não tinha expertise para dimensionar o serviço", aí sim você encontrou algo que exige mudança estrutural, não um restart no servidor.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa que poucos mencionam: as regras dos porques funcionam melhor quando aplicadas por um grupo pequeno, não individualmente. Eu sempre recomendo duas a quatro pessoas que conheçam o processo afetado. Quando uma só pessoa faz, há tendência de confirmar viés. Se você já acredita que o problema é de infraestrutura, vai dirigir todas as respostas nessa direção. Com múltiplos participantes, os contrapontos surgem naturalmente e a análise fica mais honesta. Também é importante documentar cada passo. Anotar as perguntas e respostas em um formulário padronizado evita que a conclusão seja reconstruída de memória depois. Eu uso uma planilha simples com três colunas: problema, pergunta, resposta. Leva dois minutos configurar e evita discursos intermináveis em reuniões de follow-up.
Quando a técnica não funciona
As regras dos porques não são bala de prata. Existem cenários em que ela falha completamente, e é importante saber reconhecer esses casos antes de perder tempo. Se o problema envolve múltiplas causas interdependentes, a linha linear dos porquês se perde. Imagine um incidente onde falhou tanto um serviço de terceiros quanto uma configuração interna depreciada. Ao fazer a primeira pergunta "por quê?", você já está escolhendo arbitrariamente qual ramo seguir, e o outro queda ignorado. Nesses casos, métodos como árvore de falhas ou análise de Ishikawa são mais adequados.
Outro cenário problemático é quando os dados não existem. Se não há logs, não há histórico e não há testemunhas, os porquês viram especulação. Eu já perdi duas horas em uma sessão dessas em que todos estavam chutando respostas. A dica prática é verificar a disponibilidade de evidências antes de começar. Sem dados, não há análise, só opinião. Também existe o risco de confundir causa raiz com culpado. As regras dos porques devem apontar para falhas no processo, sistema ou documentação, nunca para pessoas. Quando a cadeia leva a "porque o João errou", o exercício está sendo mal aplicado. Erro humano é sempre sintoma de algo pior: treinamento insuficiente, interface confusa, pressão de prazo. Continue perguntando até chegar nisso.
Em resumo, as regras dos porques são úteis para problemas pontuais com causa única e dados disponíveis. Para sistemas complexos com falhas em cascata, prefira ferramentas mais robustas. O tempo gasto com a técnica varia muito: problemas bem documentados levam cerca de 20 minutos, enquanto investigações com dados escassos podem consumir uma manhã inteira sem chegar a lugar nenhum.
