Foco na causa e não nos sintomas…

• E como está a gestão dos problemas no seu time?
• Quando novos bugs ou retrabalhos são gerados, há um método para avaliar a causa e consequência, como espinha de peixe de Ishikawa?
• O plano de ação tem dedicado esforços para resolver os problemas mais críticos? Como a matriz GUT (Gravidade, Urgência e Tendência)
• O follow-up garante a transparência no processo? De fato as causas dos problemas estão sendo atacadas?
• Já trabalha com Pareto na análise de distribuição das ocorrências? 20% dos problemas são responsáveis por 80% das ocorrências?

Hoje vamos falar sobre o 5 porquês (5-Why) e como utilizar para determinar a causa raiz do problema. Trata-se de uma uma técnica criada por Taiichi Ono, um dos responsáveis pela criação do sistema Toyota de produção, funcionando muito bem para problemas simples.

Embora tenha surgido como ferramenta de gestão da qualidade total e melhoria contínua na indústria, também é muito aplicável no contexto de serviços, como de desenvolvimento de sistemas na área de TI. Reunindo a equipe, deixe a comunicação aberta para participação de todos os envolvidos no processo.

Problema: cadastro de novos produtos não está funcionando
(aberto um bug no VSTS de problema no módulo de produtos)

Ao analisar a causa raiz do problema, percebemos que o erro encontrado no sistema era referente a um procedimento que deveria ser realizado, e que um treinamento ou informativo poderiam ter ajudado a evitar o problema.

Concluindo o post, vale lembrar que o 5 porquês possui limitações e deve ser utilizada com outra ferramenta, por exemplo espinha de peixe – Ishikawa, para análise detalhada de problemas de maior complexidade.

Mais detalhes: https://leonardo-matsumota.com/2018/12/13/analise-de-causa-e-efeito-em-projetos-ageis-com-fishbone-ishikawa-e-azure-devops/