Quando uma Análise de Causa Raiz faz sentido
Uma manhã, encontrei um pneu furado no meu carro. Felizmente, consegui trocar a roda rapidamente. No entanto, também gosto de aplicar no meu dia a dia coisas que aprendi no trabalho. E assim decidi fazer uma Root Cause Analysis – ou seja, uma análise de causa raiz. Esperava com isso evitar pneus furados no futuro. Afinal, o tempo que gastei trocando o pneu poderia ter sido melhor aproveitado.
O método "Five Whys" da Root Cause Analysis
O método "Five Whys" é ideal para este tipo de análise de causa raiz. Basta perguntar "Porquê?" cinco vezes seguidas – os meus filhos dominavam isso especialmente bem por volta dos quatro anos! Então comecei a procurar a causa:
Porquê tive um pneu furado?
-Porque havia um prego no pneu.
Porquê havia um prego no pneu?
-Porque aparentemente tinha passado por cima dele no dia anterior.
Porquê passei por cima do prego no dia anterior?
-Porque o estacionamento do meu ginásio (o único lugar onde fui naquele dia) estava a ser repavimentado.
Porquê o estacionamento estava a ser repavimentado?
-Por causa dos muitos buracos.
Porquê havia buracos no estacionamento?
-Por causa da chuva.
Portanto, a causa do meu pneu furado foi a chuva. Logo, não pode mais chover.
Infelizmente, isso não está ao meu alcance. Normalmente, poderia ter encaminhado algo assim para o meu Scrum Master, mas até um Scrum Master não consegue mudar o tempo.
Conclusão da Root Cause Analysis
O que quero dizer com isto? Às vezes, uma Root Cause Analysis simplesmente não vale a pena. Como qualquer outro método ou técnica, nem sempre faz sentido. Muitas coisas no desenvolvimento de software são completamente novas, ou seja, estão a ser feitas pela primeira vez (pelo menos pela pessoa ou equipa). A análise de causa raiz é mais útil em situações recorrentes – por exemplo, na produção. É menos útil em coisas novas e complexas, como as que acontecem no desenvolvimento de software (ou no desenvolvimento de produto em geral).
Não estou a dizer que deves abandonar completamente a Root Cause Analysis e os Five Whys. Apenas lembra-te de que não existe nenhum método que possa ser aplicado sempre.
Este texto é do blog de Mike Cohn e foi traduzido por nós para alemão.
Torne-se Certified Scrum Master!
Para Scrum Master oferecemos os seguintes treinamentos e oportunidades de formação gratuitas:
