Ishikawa e pensamento sistêmico na análise de problemas
O projeto corrigiu o problema três vezes e ele voltou nas três. Cada correção atacou uma causa real, levantada numa reunião bem conduzida, e mesmo assim o efeito reapareceu duas sprints depois. Situações assim mostram a fronteira entre o diagrama de Ishikawa e pensamento sistêmico: a espinha de peixe ajuda a enxergar o problema como fruto de um sistema, mas sozinha não mostra como as causas se alimentam umas às outras.
A ligação entre os dois é uma busca comum entre estudantes e profissionais da qualidade, e a resposta tem duas partes. O Ishikawa contribui com o pensamento sistêmico porque tira a análise da caça ao culpado e espalha o olhar por várias partes do processo. E ele tem limites claros, que aparecem justamente nos problemas que mais custam ao projeto. O jeito prático de completar a espinha de peixe é o diagrama de laço causal, que aparece no fim com um exemplo aplicado.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
O que é pensamento sistêmico, para quem gerencia projetos
Pensamento sistêmico é a forma de analisar um problema olhando para a estrutura que o produz, e não só para o evento visível. A ideia foi popularizada no meio empresarial por Peter Senge em A Quinta Disciplina, publicado em 1990, em que o pensamento sistêmico é justamente a quinta disciplina que integra as outras.
Três noções bastam para aplicar a ideia num projeto:
- O comportamento vem da estrutura. Atrasos, defeitos e conflitos repetidos não são azar. São o resultado previsível de como o trabalho, as metas e as informações estão organizados.
- As causas se realimentam. Uma causa gera um efeito que volta e reforça a própria causa (laço de reforço) ou que a freia (laço de equilíbrio).
- Existem atrasos. O efeito de uma decisão aparece semanas depois, e por isso a equipe raramente liga uma coisa à outra.
No projeto, isso significa trocar a pergunta "quem errou?" por "que estrutura faz esse erro ser provável?".
Como o diagrama de Ishikawa contribui com o pensamento sistêmico
O diagrama de Ishikawa foi criado para análise de causa e efeito em processos produtivos, e várias das suas regras empurram a equipe na direção sistêmica.
- Amplia o campo de busca. As categorias, como os 6M do diagrama de Ishikawa, obrigam a procurar causas em método, materiais, máquinas, pessoas, medição e ambiente. O problema deixa de ter um único dono.
- Separa efeito de causa. A cabeça do peixe guarda o efeito medido; as espinhas guardam hipóteses. Essa separação já é um treino de não confundir sintoma com estrutura.
- Junta vários pontos de vista. A montagem em grupo reúne quem conhece cada parte do processo. Nenhuma pessoa sozinha enxerga o sistema inteiro.
- Tira a culpa do indivíduo. Quando a causa aparece em "método" ou "medição", a conversa muda de pessoa para processo, o que é a base da melhoria contínua.
- Torna a estrutura visível. Um desenho na parede, com dezenas de causas organizadas, mostra que o efeito tem muitas raízes, e isso por si só muda a qualidade da discussão.
Essas contribuições já justificam o uso da ferramenta em qualquer análise de causa raiz em projetos. O problema começa quando a equipe trata o desenho pronto como retrato fiel do sistema.
Onde a espinha de peixe para
A forma do diagrama impõe algumas simplificações. Elas não são defeitos da ferramenta, mas precisam ser conhecidas.
| Limite | O que acontece na prática |
|---|---|
| Causalidade em linha reta | Cada causa aponta para o efeito em um só sentido. O desenho não mostra que o efeito, depois, piora a causa. |
| Categorias isoladas | Uma causa em "pessoas" que nasce de uma causa em "método" aparece em dois ramos sem ligação entre eles. |
| Sem tempo | O diagrama é uma foto. Não diz se a causa age já ou daqui a um mês, nem se o efeito está crescendo. |
| Sem peso | Todas as espinhas têm o mesmo tamanho. A causa que explica metade do problema parece igual à que explica quase nada. |
| Ponto de parada arbitrário | A equipe para de perguntar "por quê?" quando chega a algo que parece razoável, não quando chega à estrutura. |
O primeiro limite é o mais caro. Problemas que voltam depois de corrigidos quase sempre têm um laço de reforço por trás: uma ação para aliviar o efeito agrava a causa original. A espinha de peixe lista as peças, mas não mostra a engrenagem.
Diagrama de laço causal: o complemento da espinha
O diagrama de laço causal é a ferramenta clássica do pensamento sistêmico para mostrar realimentação. Ele usa poucas variáveis, ligadas por setas com sinal:
| Elemento | Significado | Exemplo |
|---|---|---|
| Seta com "+" | As duas variáveis andam no mesmo sentido | Mais pressão de prazo, mais atalhos nos testes |
| Seta com "−" | As variáveis andam em sentidos opostos | Mais testes automatizados, menos defeitos na homologação |
| Laço R (reforço) | O ciclo amplifica o efeito a cada volta | Atraso gera pressão, que gera defeito, que gera atraso |
| Laço B (equilíbrio) | O ciclo tende a estabilizar | Mais defeitos levam a mais revisão, que reduz defeitos |
| Marca de atraso (||) | O efeito demora a aparecer | Treinamento feito hoje melhora a qualidade em semanas |
Os nomes das variáveis devem ser quantidades que sobem e descem ("defeitos abertos", "horas de teste por entrega"), não ações ("testar mais"). Essa regra simples evita metade dos desenhos confusos.
Passo a passo: Ishikawa com olhar sistêmico
O roteiro abaixo usa a espinha de peixe como matéria-prima e acrescenta duas etapas sistêmicas. Antes de começar, confira se o caso pede mesmo essa profundidade; o artigo sobre quando usar o diagrama de Ishikawa ajuda nessa decisão.
- Desenhe o efeito ao longo do tempo. Antes da reunião, faça um gráfico simples do efeito por semana ou por entrega. Se ele cresce, oscila ou volta depois de cair, há boa chance de realimentação.
- Monte a espinha de peixe normalmente. Efeito com número na cabeça, causas por categoria, porquês até onde a equipe conseguir ir.
- Marque as repetições. Circule causas que aparecem em mais de um ramo com nomes diferentes. Elas costumam ser o mesmo fator visto por áreas diferentes.
- Pergunte para os dois lados. Para cada causa principal, além de "o que causa isso?", pergunte "o que esta causa provoca, além do efeito?" e "o efeito volta a mexer com ela?".
- Desenhe o laço com quatro a seis variáveis. Pegue as causas mais citadas e o próprio efeito, ligue com setas e sinais e identifique se o ciclo é de reforço ou de equilíbrio.
- Procure o ponto de alavancagem. É a ligação em que uma mudança pequena quebra o ciclo. Raramente é a causa mais visível.
- Verifique com dados. O laço é uma hipótese. Confirme cada ligação com registros do projeto antes de montar o plano de ação.
Exemplo: homologação que nunca termina
Contexto (exemplo ilustrativo). Uma secretaria estadual implanta um sistema de protocolo eletrônico em entregas mensais. Nas últimas quatro entregas, a homologação, planejada para uma semana, levou de duas a três, e o número de defeitos encontrados subiu a cada mês.
A espinha de peixe da equipe levantou, entre outras, estas causas:
| Categoria | Causa levantada |
|---|---|
| Pessoas | Usuários-chave com pouco tempo para testar |
| Método | Roteiros de teste incompletos; desenvolvedores pulando testes unitários |
| Máquinas | Ambiente de homologação instável |
| Materiais | Massa de dados de teste desatualizada |
| Medição | Critério de aceite vago em parte das funcionalidades |
As correções anteriores atacaram causas isoladas: mais usuários convocados, ambiente reiniciado antes de cada rodada. O efeito voltou. Ao perguntar "o que o atraso provoca?", a equipe montou este laço:
- Atraso na homologação (+) aumenta a pressão sobre o prazo da próxima entrega.
- Pressão de prazo (+) aumenta os atalhos no desenvolvimento, como testes unitários pulados.
- Atalhos (+) aumentam os defeitos que chegam à homologação.
- Defeitos na homologação (+) aumentam as rodadas de teste e, portanto, o atraso.
É um laço de reforço. Há ainda um segundo ciclo: muitos defeitos (−) reduzem a confiança dos usuários-chave no sistema, que passam a dedicar menos tempo aos testes, o que alonga a homologação.
O ponto de alavancagem não estava em convocar mais testadores, a ação mais óbvia, e sim em proteger os testes do desenvolvimento contra a pressão de prazo: a equipe tornou o teste unitário uma condição para a entrega sair do desenvolvimento e aceitou reduzir o escopo de uma entrega para recuperar o fôlego. Nas entregas seguintes, os defeitos na homologação caíram e o laço passou a girar no sentido contrário. Os números deste exemplo não importam; o que importa é que a espinha de peixe, sozinha, levava a equipe a repetir a mesma correção.
Quando a espinha basta e quando ir além
| Situação | Ferramenta indicada |
|---|---|
| Problema pontual, causa provável num só processo | Ishikawa ou 5 porquês |
| Muitas causas possíveis, sem histórico de recorrência | Ishikawa completo, com verificação de causas |
| Problema que volta depois de corrigido | Ishikawa seguido de laço causal |
| A solução de uma área piora outra | Laço causal com as áreas envolvidas |
| Efeito que cresce ao longo do tempo | Gráfico ao longo do tempo e laço causal |
Na dúvida, comece pela espinha. Ela é rápida, todo mundo entende e gera a lista de variáveis que o laço causal precisa. O guia de ferramentas da qualidade em projetos mostra como encaixar as duas na sequência das demais.
Erros comuns ao misturar as duas abordagens
- Desenhar laço para tudo. Problema simples com causa clara não precisa de modelo sistêmico. O excesso cansa a equipe e desacredita o método.
- Laço com vinte variáveis. Ninguém lê. Quatro a seis variáveis explicam a maior parte dos ciclos que importam no projeto.
- Variáveis como ações. "Contratar testador" não sobe nem desce. Escreva quantidades.
- Confundir hipótese com fato. Cada seta é uma afirmação sobre o projeto e precisa de evidência, como qualquer causa da espinha.
- Esquecer os atrasos. Sem eles, a equipe conclui que a ação não funcionou porque o efeito não mudou na semana seguinte.
Leve a análise para o próximo problema recorrente
Escolha um problema do seu projeto que já foi corrigido mais de uma vez. Refaça a espinha de peixe com a equipe, marque as causas repetidas e pergunte o que o efeito provoca de volta. Se aparecer um ciclo, você encontrou o motivo das correções que não duram. Para aplicar esse tipo de análise junto com escopo, prazo, custos e riscos no ciclo completo do projeto, o curso Gerente de Projetos Expert trabalha a gestão integrada com exercícios práticos.
