Desenho De Um Peixe

Como fazer um diagrama de espinha de peixe que realmente funciona

Achei o famoso desenho de um peixe uma dor de cabeça até entender que a maioria das pessoas faz errado desde o começo. O diagrama de Ishikawa é usado em praticamente toda consultoria de qualidade, mas eu vi gente montando espinhas intermináveis com quarenta causas raiz e ainda assim não resolverem nada no chão de fábrica. O problema não é a ferramenta. É que todo mundo tenta enfiar informação demais num espaço que foi feito para síntese. Você provavelmente já viu um. É aquela cabeça de peixe simplificada com espinhos saindo de um osso central. Formalmente é um diagrama de causa e efeito, inventado por Kaoru Ishikawa nos anos 60 na Mitsubishi. A ideia é mapear visualmente todas as causas possíveis de um problema e organizá-las por categoria. Mas na prática serve pra coisa bem mais simples: forçar o time a parar de culpar fatores aleatórios e organizar o que realmente está acontecendo antes de tomar uma decisão. Comece desenhando uma seta horizontal apontando para a direita. Na ponta dela, coloque o problema. Isso é a cabeça do peixe. A linha central é a espinha dorsal. Os grandes espinhos são as categorias de causa. O padrão mais usado no Brasil é o dos seisMs: Método, Máquina, Material, Mão de obra, Meio ambiente e Medição. Tem quem use quatroMs ou até categorias diferentes dependendo do setor. Eu prefiro os seisMs porque cobrem mais terreno, mas em ambientes de escritório isso vira um exercício forçado onde gente inventa categorias artificiais pra caber tudo.

Para o desenho de um peixe em si, traçe linhas diagonais saindo da espinha dorsal em ambos os lados. Não precisa ser bonito. Caneta na lousa, quadro branco, ou até um app como o Miro funcionam. O que importa é que as linhas estejam visivelmente ligadas ao problema.

Preenchendo as causas

Aqui é onde a maioria estraga tudo. A técnica chama-se brainstorming estruturado. O time lista causas sem julgar, depois agrupa cada causa no espinho correspondente. O truque é aplicar o "por quê?" três vezes em cada causa antes de considerá-la completa. Causa superficial é causa que não resolve nada quando você age sobre ela. Eu tive um caso específico numa linha de produção de embalagens onde o defeito era rebarba nas tampas metálicas. O diagrama inteiro apontava para "máquina velha" como causa raiz. Passamos duas semanas pedindo orçamento de troca de equipamento. Ninguém tinha perguntado por quê da rebarba com profundidade real. No final, descobrimos que o parâmetro de pressão da prensa havia sido alterado num ajuste de manutenção dois dias antes e ninguém havia documentado o valor novo. O diagrama estava certo, mas as camadas de causa estavam rasas. A lição que levei: se o seu diagrama não te obriga a questionar o óbvio pelo menos uma vez, você não fez um desenho de um peixe, fez um passatempo.

Onde a maioria erra

Erro número um: transformar o diagrama num muro de texto. Causas devem ser frases curtas, não parágrafos. Se uma causa precisa de explicação, ela pertence a um subespinho, não ao espinho principal. Erro número dois: fazer o diagrama sozinho. Ishikawa mesmo dizia que a ferramenta só funciona com pessoas que conhecem o processo de perto. Um engenheiro escrevendo causas do chão de fábrica de memória vai perder tudo que um operador veria em dez minutos. Erro número três: tratar o diagrama como solução. Ele identifica causas. Não corrige. Depois dele, você precisa escolher as causas mais críticas e criar um plano de ação com responsável, prazo e métrica de verificação. Sem isso, o desenho de um peixe vira arte decorativa pendurada no hall da empresa.

Limitações que ninguém admite

O diagrama de Ishikawa não funciona bem para problemas multifatoriais complexos onde causas se retroalimentam. Ele é linear por natureza. Se o seu problema tem causalidade circular, considere usar um diagrama de relação ou um sistema de dinâmica de sistemas. Também não substitui análise estatística. Co-relacionar variáveis com dados reais continua sendo mais confiável do que consenso de reunião. Ferramenta Visual como o fishbone diagram é excelente para alinhamento inicial, mas se você quer provar causa e efeito, precisa de dado, não de opinião coletada em quadro branco. Use quando o time precisa de um ponto de partida visual para um problema novo ou pouco compreendido. Use antes de uma reunião de resolução onde as opiniões estão confusas. Evite quando o problema já tem dados suficientes para análise estatística direta. Evite também em situações hierárquicas onde operadores não se sentem seguros para criticar processos abertamente — nesse caso o diagrama fica vazio ou reproduz a narrativa da gestão. O desenho de um peixe não é elegante. É útil porque obriga organização visual. Se você seguir os passos básicos sem tentar transformar tudo numa obra-prima, vai conseguir resultados melhores na maioria das vezes.