O que é o Diagrama de Ishikawa?

O Diagrama de Ishikawa é uma ferramenta visual utilizada para organizar e investigar as possíveis causas de um problema. Sua estrutura lembra o esqueleto de um peixe: na cabeça colocamos o problema que queremos investigar e, ao longo das espinhas, organizamos grupos de possíveis causas.

É justamente por causa desse formato que ele também ficou conhecido como diagrama espinha de peixe. Outro nome bastante utilizado é diagrama de causa e efeito, porque seu objetivo é nos ajudar a relacionar um efeito observado — o problema — com as diferentes causas que podem estar contribuindo para ele.

A principal vantagem, na minha opinião, é nos obrigar a olhar para o problema de forma sistêmica. Em vez de escolher rapidamente uma explicação conveniente, abrimos diferentes linhas de investigação e começamos a perguntar quais processos, pessoas, ferramentas, informações, métodos ou condições podem estar contribuindo para aquilo que estamos vendo.

Isso é especialmente importante em projetos porque raramente um problema relevante possui uma única causa isolada. Um atraso pode envolver estimativas ruins, baixa experiência do time, dependências externas, atividades mal descritas, excesso de trabalho em andamento, ausência de automação ou vários desses fatores acontecendo ao mesmo tempo.

Para que serve o Diagrama de Ishikawa?

O Diagrama de Ishikawa pode ser usado em praticamente qualquer situação em que precisamos entender por que um determinado resultado está acontecendo. Em projetos, ele pode ajudar a investigar atrasos, aumento de custos, problemas de qualidade, retrabalho, bugs recorrentes, baixa produtividade, conflitos entre áreas, falhas de processo ou qualquer outro resultado que esteja diferente daquilo que esperávamos.

Não dá para negar: por mais que planejemos um projeto, alguma coisa que não foi mapeada anteriormente eventualmente aparecerá. Quando esses problemas não são compreendidos corretamente, podemos gerar atrasos nas entregas, atrasos no lançamento de produtos, conflitos com stakeholders, pressão sobre os times e até decisões mais graves envolvendo pessoas ou orçamento.

A questão é que resolver o efeito não significa necessariamente resolver a causa. Se as tarefas estão atrasadas porque o time não sabe estimá-las, colocar mais pressão sobre os desenvolvedores não corrige o problema. Se a causa está em dependências mal mapeadas, contratar mais uma pessoa também pode não resolver nada. O Diagrama de Ishikawa ajuda justamente a abrir essas possibilidades antes de decidirmos qual ação tomar.

Diagrama de Ishikawa, diagrama de causa e efeito ou espinha de peixe?

Os três nomes normalmente se referem à mesma ferramenta. Diagrama de Ishikawa é o nome associado à técnica; diagrama de causa e efeito descreve sua finalidade; e diagrama espinha de peixe descreve sua aparência.

Independentemente do nome utilizado, a lógica é a mesma: começamos com um efeito que queremos investigar e, a partir dele, organizamos possíveis causas em categorias. Isso nos ajuda a deixar de enxergar o problema como um único bloco e começar a tratá-lo como um sistema de fatores que podem estar relacionados.

Quais são os 6Ms do Diagrama de Ishikawa?

Uma das formas mais conhecidas de organizar as causas dentro do Diagrama de Ishikawa é utilizando os chamados 6Ms. Eles funcionam como categorias que nos ajudam a pensar em diferentes origens possíveis para o problema.

• Máquina: equipamentos, ferramentas, sistemas, infraestrutura e tecnologias utilizadas.
• Método: processos, procedimentos, regras, práticas e formas de executar o trabalho.
• Material: matérias-primas, componentes, documentos, informações ou insumos necessários.
• Meio ambiente: ambiente físico, organizacional, cultural ou qualquer condição externa que influencie o trabalho.
• Medição: métricas, inspeções, sistemas de monitoramento, indicadores e formas de avaliar resultados.
• Mão de obra: pessoas, experiência, capacidade, conhecimento, treinamento e disponibilidade.

É importante entender que os 6Ms nasceram em um contexto bastante relacionado à qualidade e à indústria, mas o raciocínio pode ser perfeitamente adaptado a projetos de tecnologia. “Máquina”, por exemplo, pode representar ferramentas, ambientes, pipelines ou infraestrutura. “Material” pode representar documentação, requisitos, APIs ou componentes de software.

Também não existe obrigação de preencher todas as categorias. Se não identificamos nenhuma possível causa relacionada à medição, não precisamos inventar uma apenas para completar o desenho. O objetivo é melhorar a investigação, não preencher um template.

Como fazer um Diagrama de Ishikawa passo a passo

Para começar, precisamos definir com clareza qual problema queremos investigar. Esse ponto parece óbvio, mas muitas análises de causa raiz começam mal justamente porque o problema foi definido de forma vaga.

“O projeto está ruim” não é um problema suficientemente específico. “As user stories do Time X estão apresentando uma taxa de atraso de aproximadamente 20%” já nos dá uma base muito melhor para trabalhar.

Depois de definir o problema, colocamos esse efeito na cabeça do peixe. Em seguida, criamos as categorias que serão usadas na análise — os 6Ms ou outra classificação mais adequada ao contexto — e começamos a levantar possíveis causas para cada uma delas.

Nesse momento, eu evitaria tentar resolver o problema imediatamente. Primeiro quero ampliar a investigação. Posso conversar com o time, analisar dados históricos, observar processos, verificar dependências e levantar hipóteses. Depois começamos a eliminar aquilo que não encontra sustentação nos fatos e aprofundamos as causas mais prováveis.

Exemplo de Diagrama de Ishikawa em um projeto

Vamos imaginar um problema bastante comum: “Todas as nossas tarefas estão atrasadas.” Se eu simplesmente disser que a causa é baixa produtividade do time, já estou pulando diretamente do problema para uma conclusão. O Ishikawa me obriga a abrir essa análise.

Utilizando os 6Ms, poderíamos começar com algumas hipóteses. Em Máquina, talvez falte automação de DevOps para fazer deploy em staging e produção. Em Método, os refinamentos podem estar ignorando a experiência dos desenvolvedores. Em Material, os componentes utilizados podem não ser reutilizáveis. Em Mão de obra, talvez exista um número muito alto de profissionais juniores ou falte alguém com conhecimento específico de DevOps.

Observe que não precisamos encontrar algo em todos os Ms. Também é perfeitamente possível que a mesma causa apareça em mais de uma categoria. A falta de experiência, por exemplo, pode estar relacionada à mão de obra, mas também pode afetar diretamente o método utilizado pelo time. A falta de um profissional DevOps pode aparecer tanto em mão de obra quanto em máquina, porque também afeta automação e infraestrutura.

Quando uma mesma causa aparece repetidamente em diferentes partes da análise, eu presto atenção especial nela. Isso não prova automaticamente que encontramos a causa raiz, mas costuma ser um excelente sinal de que precisamos investigar aquele ponto com mais profundidade.

Como encontrar a causa raiz de um problema

O Diagrama de Ishikawa nos ajuda a organizar possíveis causas, mas uma análise de causa raiz não deveria terminar no momento em que o desenho fica pronto. O próximo passo é validar quais hipóteses realmente explicam o problema.

Se acreditamos que as tarefas estão atrasando por causa da falta de experiência do time, precisamos procurar evidências. Profissionais juniores estão realmente demorando mais? Quais tipos de atividade apresentam maior desvio entre estimativa e duração real? O atraso está concentrado em determinadas áreas? Existe correlação com bugs, retrabalho ou tarefas pouco claras?

Se a hipótese é que os refinamentos estão ruins, podemos analisar quantas atividades entram em execução sem estimativa, quantas são reestimadas depois de iniciadas, quantas possuem descrições insuficientes e quanto retrabalho aparece depois.

É aqui que deixamos de ter apenas uma opinião e começamos a construir uma análise baseada em evidências.

Como usar os 5 Porquês para encontrar a causa raiz

O método dos 5 Porquês é uma das técnicas mais simples e úteis para aprofundar uma causa identificada no Diagrama de Ishikawa. A lógica consiste em continuar perguntando “por quê?” até conseguirmos chegar a uma explicação mais fundamental para aquilo que está acontecendo.

Apesar do nome, não existe nenhuma regra dizendo que devemos fazer exatamente cinco perguntas. Podemos encontrar a causa na terceira pergunta ou precisar de sete. O objetivo não é cumprir um número; é continuar avançando enquanto as respostas ainda estiverem descrevendo apenas sintomas ou consequências.

Um exemplo simples:

- Por que não temos acesso às máquinas de produção?
- Porque a área de segurança não forneceu o acesso.
- Por que a área de segurança não forneceu o acesso?
- Porque apenas o time de segurança pode acessar produção.
- Por que apenas o time de segurança pode acessar produção?

E aqui talvez cheguemos àquela resposta que todos conhecem, mas ninguém quer dizer:

Porque o CTO exigiu isso.

Esse exemplo também mostra uma limitação importante de qualquer técnica de análise de causa raiz: ela depende de transparência. Se as pessoas evitam respostas porque o problema envolve política, hierarquia ou medo, podemos construir um Diagrama de Ishikawa impecável e ainda assim chegar à conclusão errada.

Como fazer o exercício dos 5 Porquês

Uma prática que considero útil é sempre construir a próxima pergunta a partir da resposta anterior. Isso cria rastreabilidade e reduz a chance de começarmos a pular entre hipóteses sem seguir uma linha lógica.

Podemos começar assim: “Por que as tarefas estão atrasadas?” A resposta pode ser: “Porque os desenvolvedores estão estimando as tarefas incorretamente.” A próxima pergunta então deveria utilizar exatamente essa resposta: “Por que os desenvolvedores estão estimando as tarefas incorretamente?”

Talvez a resposta seja falta de experiência, refinamento insuficiente, requisitos incompletos ou uma técnica de estimativa inadequada. Cada resposta abre a próxima pergunta até chegarmos a um ponto em que conseguimos identificar uma ação concreta capaz de tratar a origem do problema.

O Diagrama de Ishikawa e os 5 Porquês funcionam muito bem juntos. O Ishikawa ajuda a ampliar a investigação e organizar possibilidades. Os 5 Porquês ajudam a aprofundar uma dessas possibilidades.

Diagrama de Ishikawa ou 5 Porquês: qual usar?

Eu não trataria essas técnicas como concorrentes. Elas resolvem partes diferentes da investigação. Quando ainda não sabemos de onde o problema pode estar vindo, o Diagrama de Ishikawa é muito útil porque amplia nosso campo de visão e organiza diferentes famílias de causas.

Quando já temos uma causa candidata e queremos entender o que existe por trás dela, os 5 Porquês podem ser mais eficientes. Muitas vezes começo com Ishikawa e depois aplico os 5 Porquês em uma ou mais causas que parecem relevantes.

No nosso exemplo das tarefas atrasadas, poderíamos identificar “estimativas incorretas” dentro do Ishikawa e depois utilizar os 5 Porquês para investigar por que as estimativas estão erradas. Poderíamos fazer o mesmo com “falta de automação”, “baixa experiência do time” ou qualquer outra causa candidata.

Formulação de hipóteses também faz parte da análise de causa raiz

Antes de confirmar uma causa, normalmente estamos trabalhando com hipóteses. Para formular boas hipóteses, precisamos compreender o problema, seu contexto, as pessoas envolvidas, os processos relacionados e a diferença entre o resultado esperado e aquilo que realmente aconteceu.

Uma hipótese útil precisa ser investigável. Dizer que “o time não está comprometido” é muito abstrato. Dizer que “o aumento do número de atividades simultâneas está fazendo com que o tempo médio de entrega aumente” cria algo que podemos verificar.

Também podemos utilizar uma análise de cenários para compreender como determinadas causas podem evoluir. Imagine que um tech leader esteja sobrecarregado e peça um aumento. A causa pode ser simplesmente salarial, mas também pode existir excesso de responsabilidade, concentração de conhecimento ou ausência de outras pessoas capazes de assumir suas atividades.

Se essa pessoa sair, podemos ter perda de conhecimento, redistribuição inesperada de trabalho, insatisfação do restante do time e atrasos. Construir esses cenários ajuda não apenas a investigar o problema, mas também a compreender o risco de não agir.

Quando essa investigação envolve pessoas com alto poder ou impacto, uma boa análise de stakeholders também pode ser importante. Falo sobre esse assunto em Stakeholders: o que são, tipos e como gerenciá-los em projetos .

Defina bem o problema antes de procurar a causa

Existe um erro que pode comprometer toda a investigação: tentar descobrir a causa raiz de um problema que nunca foi definido adequadamente. Se nossa definição inicial está errada, podemos passar horas investigando as causas de algo que nem sequer representa o verdadeiro problema.

É aqui que gosto de utilizar um problem statement. Um problem statement é uma declaração clara do problema que queremos resolver. Ele delimita o que está acontecendo, quem está sendo impactado, por que aquilo importa, qual é a dimensão do problema e qual resultado esperamos alcançar.

Quanto mais conseguimos quantificar essa declaração, melhor. Em vez de escrever “nossas entregas estão atrasando muito”, podemos chegar a algo como:

“A taxa de atraso nas entregas de user stories do Time X é de aproximadamente 20%, o que gera cerca de um mês de atraso a cada semestre, US$ 100.000 em custos adicionais por semestre e insatisfação do cliente final, CTO, CEO e área financeira. As principais causas identificadas são baixa experiência do time e estimativas imprecisas. Como podemos reduzir esses atrasos para 5% em três meses?”

Agora temos um problema muito mais concreto. Conseguimos medir se melhoramos, sabemos quem está sendo impactado e conseguimos relacionar a solução às causas que foram encontradas durante a investigação.

Como usar dados do projeto para validar a causa raiz

Existe uma diferença importante entre uma causa possível e uma causa sustentada por evidências. Em projetos de tecnologia, temos a vantagem de produzir uma enorme quantidade de dados durante a execução do trabalho. Jira, Azure DevOps, Asana, Monday.com e ClickUp já registram atividades, estimativas, responsáveis, status, sprints, datas, tipos de trabalho e diversas outras informações que podem ajudar na investigação.

É justamente aqui que o Saint Jude Project Intelligence pode apoiar esse processo. Em vez de depender apenas da percepção do gerente, podemos analisar padrões de atraso, estimativas incorretas, performance do time, custos, qualidade das atividades, bugs, desvios de sprint e riscos.

Voltando ao nosso exemplo de “todas as tarefas estão atrasadas”, podemos separar a análise por área, senioridade, função, tipo de tarefa, tag, custo, horas planejadas, horas consumidas ou performance das sprints. Talvez descobramos que o problema não está no time inteiro, mas em um determinado tipo de atividade. Talvez os atrasos estejam concentrados em tarefas sem estimativa ou em profissionais com determinada senioridade.

Isso não substitui o Diagrama de Ishikawa, os 5 Porquês ou o trabalho de um gerente. Pelo contrário: os dados tornam essas ferramentas mais fortes porque ajudam a validar ou rejeitar nossas hipóteses.

A mesma lógica vale para produtividade. Se a investigação indicar que o problema pode estar relacionado à capacidade ou performance da equipe, recomendo também: Indicadores de produtividade: como medir e melhorar a produtividade da sua equipe .

E, quando os atrasos estiverem relacionados a dependências e ao impacto de determinadas atividades sobre a data final do projeto, vale complementar essa análise com: Método do caminho crítico: como identificar dependências que podem atrasar seu projeto .

Encontrar a causa raiz é apenas o começo

O Diagrama de Ishikawa nos ajuda a organizar possíveis causas. Os 6Ms nos dão uma estrutura para explorar diferentes perspectivas. Os 5 Porquês ajudam a aprofundar uma linha de investigação. A formulação de hipóteses e a análise de cenários ampliam nossa compreensão, enquanto um bom problem statement transforma aquilo que descobrimos em um problema claro e mensurável.

Mas nenhuma dessas ferramentas deveria existir apenas para produzir um desenho bonito ou preencher uma planilha. O objetivo final é sair de uma discussão baseada em sintomas e chegar a uma explicação suficientemente sólida para orientar uma decisão.

Se minhas tarefas estão atrasadas, eu não quero apenas saber quantas estão atrasadas. Quero entender por que elas estão atrasadas. Se meu custo aumentou, não quero apenas reduzir despesas; quero descobrir o que está consumindo dinheiro além do esperado. Se a produtividade caiu, quero saber o que mudou no sistema antes de simplesmente concluir que as pessoas estão trabalhando menos.

Depois de encontrar a causa raiz, podemos finalmente começar a discutir soluções. Falo especificamente sobre essa etapa em: Como encontrar as soluções certas para os problemas do seu produto .

No fim, talvez essa seja a principal contribuição do Diagrama de Ishikawa: ele nos força a parar de perguntar apenas “como resolvemos isso?” e começar por uma pergunta muito mais importante:

“Por que isso está acontecendo?”

Até breve!

Erik Scaranello