O objetivo dos 5 porquês é chegar à causa implícita do problema eliminando as camadas superficiais que, na verdade, são sintomas do problema, não a causa. Ao perguntar "por quê?" várias vezes e examinar as respostas, você descobre as causas mais profundas e muitas vezes negligenciadas do problema.
A meta é chegar ao ponto em que novas perguntas já não tragam mais informações úteis porque a causa raiz foi identificada. Depois de identificar a causa raiz, você pode trabalhar na implementação de soluções práticas para resolver o problema e evitar que se repita.
Exemplo do template dos 5 porquês em uso
Veja um exemplo de como aplicar o template de análise dos 5 porquês a um problema:
Definição do problema: o aplicativo de software trava com frequência durante uma alta carga de usuários, o que gera uma experiência ruim para os usuários.
1. Por que o software trava durante uma alta carga de usuários?
2. Por que o servidor fica sobrecarregado com solicitações simultâneas de usuários?
3. Por que a capacidade do servidor não foi escalada para lidar com altas cargas tráfego?
4. Por que não foram feitos o monitoramento proativo e os testes de carga durante o desenvolvimento?
5. Por que a equipe de desenvolvimento não tinha as ferramentas e a experiência necessárias para o teste de carga?
Causa raiz: as falhas de software durante altas cargas de usuários são causadas pela ausência de testes de carga no escopo inicial do projeto e pela falta de acesso aos recursos e conhecimentos necessários para o teste de carga.
Solução: para evitar novas falhas durante altas cargas de usuários, a equipe precisa incluir o teste de carga como parte padrão do processo de desenvolvimento de software e garantir o acesso aos recursos e conhecimentos necessários para testes de carga. Essa medida vai ajudar a identificar e resolver problemas de desempenho no início do ciclo de desenvolvimento, garantindo uma experiência de usuário mais fluida quando o software for implantado.
Neste exemplo, a análise dos 5 porquês revelou que a causa raiz das frequentes falhas de software durante uma alta carga de usuários foi a ausência de testes de carga no escopo inicial do projeto e a falta de recursos para fazer testes de carga durante o desenvolvimento.
A solução resolve esse problema, o que cria um efeito dominó que resolve os sintomas subsequentes e, por fim, a definição inicial do problema.
Ao tornar o teste de carga uma parte padrão do processo de desenvolvimento de software e garantir a disponibilidade dos recursos e dos conhecimentos necessários, novas falhas vão ser evitadas. Assim, a equipe vai poder melhorar a experiência do usuário.
