Quando usar o diagrama de Ishikawa no projeto
Saber quando usar diagrama de Ishikawa poupa duas reuniões ruins: a de duas horas para um problema que se resolvia com três perguntas, e a de quinze minutos para um problema com seis causas, que termina com a equipe culpando a primeira que apareceu. A ferramenta é boa, mas tem um tipo de problema em que rende e outros em que só ocupa a agenda.
A regra curta: o Ishikawa serve para abrir o leque de causas possíveis de um efeito bem definido, quando essas causas são várias e a equipe não concorda sobre elas. Abaixo estão os sinais de que o problema pede o diagrama, os casos em que ele é exagero, a comparação com Pareto e 5 porquês e os momentos do projeto em que ele costuma aparecer. Como montar o diagrama passo a passo está em diagrama de Ishikawa: o que é e como fazer.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
Para que serve o diagrama de Ishikawa, na prática
O diagrama de causa e efeito faz uma coisa: organiza hipóteses. Ele coloca o efeito na cabeça do peixe e distribui as causas possíveis em categorias, como os 6M (método, máquina, mão de obra, material, medida e meio ambiente). O ganho vem das categorias, que obrigam a equipe a olhar para frentes que ela não olharia por conta própria.
O que ele não faz: provar causa. O diagrama termina com uma lista de suspeitos, e o trabalho seguinte é verificar quais deles realmente produzem o efeito. Quem espera que o desenho entregue a resposta usa a ferramenta na hora errada.
Quando usar diagrama de Ishikawa: os sinais do problema
Use o diagrama quando pelo menos dois destes sinais aparecem juntos:
- O problema se repete. Já foi corrigido uma ou duas vezes e voltou. A correção atacou um sintoma ou uma das causas, não todas.
- Há muitas causas possíveis. O efeito depende de pessoas, processo, fornecedor, ferramenta e ambiente ao mesmo tempo.
- A equipe discorda. Cada área tem uma explicação diferente, normalmente apontando para outra área. O diagrama põe todas as explicações no mesmo quadro e tira a conversa do terreno da culpa.
- O efeito é bem definido. Dá para escrever o problema numa frase com número e lugar: "40% das medições mensais devolvidas pela fiscalização desde março". Sem isso, o diagrama vira uma tempestade de ideias sobre tudo.
- Vale o esforço. O problema custa prazo, dinheiro ou relação com o cliente o suficiente para justificar uma ou duas horas de várias pessoas.
Quando o Ishikawa é exagero ou a ferramenta errada
| Situação | Por que o Ishikawa não ajuda | O que usar |
|---|---|---|
| Falha pontual, recente, com registro do que aconteceu | A causa segue uma cadeia única; o diagrama espalha a atenção | 5 porquês |
| Muitos tipos de problema e nenhum escolhido | O diagrama precisa de um efeito só | Diagrama de Pareto para escolher o foco |
| Causa já conhecida e comprovada | Não há hipótese para levantar | Plano de ação direto, com 5W2H |
| Problema que é decisão, não defeito ("qual fornecedor contratar?") | Não existe efeito indesejado para explicar | Matriz de decisão ou análise de alternativas |
| Variação de um número ao longo do tempo, sem saber se é anormal | Primeiro é preciso saber se há um problema | Gráfico de controle ou histograma |
| Ninguém da equipe conhece o processo | As causas levantadas serão palpites | Observar o processo antes, com fluxograma e coleta de dados |
O caso mais frequente de uso errado é o segundo. A equipe tem uma lista de vinte tipos de chamado, defeito ou atraso e tenta colocar tudo num diagrama só. O resultado é um peixe com espinhas sobre assuntos diferentes, que não leva a ação nenhuma.
Ishikawa, Pareto e 5 porquês: quem entra em que momento
As três ferramentas respondem a perguntas diferentes, e é isso que define quando usar cada uma:
| Pergunta | Ferramenta | Saída |
|---|---|---|
| Qual problema atacar primeiro? | Diagrama de Pareto | Os poucos tipos que concentram a maior parte das ocorrências |
| Quais são as causas possíveis deste problema? | Ishikawa | Hipóteses organizadas por categoria |
| Por que esta causa acontece? | 5 porquês | Uma cadeia até uma causa em que dá para agir |
A sequência típica num problema com muitas ocorrências é Pareto, Ishikawa e 5 porquês nas causas mais prováveis. O detalhamento da combinação entre os dois primeiros está no artigo sobre Pareto e Ishikawa juntos; a comparação direta com os porquês, com tabela e roteiro de decisão, está em Ishikawa ou 5 porquês.
Em que momentos do projeto o Ishikawa costuma aparecer
Na execução, diante de um problema recorrente. É o uso clássico: retrabalho que não para, entregas reprovadas no aceite, atraso repetido de um fornecedor. Exemplo ilustrativo: numa implantação de sistema, a homologação de cada módulo reprova na primeira rodada. Pessoas, ambiente de teste, massa de dados, critérios de aceite e o processo de passagem entre desenvolvimento e teste podem ter culpa. É um caso típico de diagrama.
Numa análise de causa raiz formal. Quando um incidente grave pede investigação estruturada, o Ishikawa entra na etapa de levantar causas possíveis, depois da coleta de fatos e antes da verificação. O roteiro completo está em análise de causa raiz em projetos.
Na retrospectiva ou na reunião de lições aprendidas. Se o tema da retrospectiva é um problema concreto ("as estimativas da sprint erraram por mais de 40% em três sprints seguidas"), o diagrama organiza a conversa melhor do que a lista livre de "o que deu errado". Para retrospectivas genéricas, sem um efeito definido, ele não serve.
Na identificação de riscos. Há equipes que usam o desenho ao contrário: colocam um efeito indesejado que ainda não aconteceu ("atraso na entrega do projeto executivo") e levantam o que poderia causá-lo. É um uso legítimo para estimular a identificação de riscos, desde que as causas levantadas virem riscos registrados, com dono e resposta.
Antes de uma decisão de mudança cara. Antes de trocar fornecedor, ferramenta ou pessoa por causa de um problema, vale um diagrama rápido para conferir se o problema não está em outra categoria. Trocar o fornecedor quando a causa era a especificação mal feita custa caro e não resolve.
Teste rápido antes de marcar a reunião
Responda às cinco perguntas. Três "sim" justificam o diagrama:
- O problema já aconteceu mais de uma vez?
- Consigo escrever o efeito numa frase, com número e onde acontece?
- Existem pelo menos três frentes que poderiam estar causando o problema?
- As pessoas envolvidas têm explicações diferentes?
- Existe dado, ou dá para coletar, para verificar as causas depois?
Se a resposta à segunda for "não", pare antes de tudo e defina o efeito. Se a quinta for "não", planeje a coleta: uma folha de verificação simples durante duas semanas costuma bastar.
Erros de momento mais comuns
- Usar o Ishikawa para descobrir qual é o problema. Ele precisa de um efeito. Se a equipe ainda discute qual é o problema, a reunião certa é outra.
- Montar o diagrama depois de decidir a solução. Quando a ação já foi escolhida, o diagrama vira justificativa, e as causas levantadas confirmam o que já se queria fazer.
- Fazer o diagrama sozinho. O valor está nas visões diferentes. Um diagrama feito pelo gerente do projeto na mesa dele reflete as hipóteses de uma pessoa.
- Parar no diagrama. Sem verificação e sem plano de ação, a reunião produziu um desenho. Para ver um caso completo, do efeito à verificação, veja o exemplo de diagrama de Ishikawa preenchido, publicado nesta mesma série.
O Ishikawa é uma entre várias ferramentas da qualidade, e saber quando ele entra fica mais fácil olhando o conjunto. O guia de ferramentas da qualidade em projetos mostra qual usar em cada situação.
Do diagrama à prioridade
Se o teste rápido indicou o Ishikawa, marque uma hora com quem conhece o processo, leve o efeito escrito e as categorias definidas, e saia com as causas mais prováveis marcadas para verificação. Quando a verificação confirmar mais de uma causa, decida por qual começar pela gravidade, urgência e tendência de cada uma: a matriz GUT gratuita da Projeto Diário faz essa priorização em poucos minutos e deixa registrado o motivo da escolha.
