A ativação do produto caiu, e em dez minutos de reunião já existem três culpados: o modelo, o onboarding e o marketing. Cada pessoa aponta para a área que conhece melhor, e a primeira explicação convincente tende a encerrar a conversa.
O diagrama de Ishikawa existe para atrasar essa conclusão. Antes de escolher uma causa, o grupo abre o leque, organiza as possibilidades em famílias e enxerga o que ainda não foi considerado. O resultado é um mapa do que investigar, com a ordem em que vale investigar.
O que é o diagrama de Ishikawa
Também chamado de diagrama de causa e efeito ou espinha de peixe, ele coloca o problema na cabeça do peixe e organiza as causas possíveis em ramos ligados à espinha central. Cada ramo é uma categoria, e cada categoria se abre em causas e subcausas.
O diagrama leva o nome de Kaoru Ishikawa, que o popularizou nos anos 1960, ligado ao trabalho de gestão da qualidade nos estaleiros de Kawasaki. Ele aparece em seu Guide to Quality Control, publicado no Japão em 1968. A data do primeiro uso é incerta, e há registros de que a ideia básica é anterior a ele (Wikipedia).
Categorias para software
As categorias da imagem vêm da manufatura. Elas funcionam em produtos digitais depois de uma tradução:
| Categoria | Em software | Exemplos |
|---|---|---|
| Método | Processos e fluxos | Onboarding, deploy, revisão |
| Máquina | Infraestrutura e modelos | Latência, capacidade, versão do modelo |
| Pessoas | Usuários e equipes | Treinamento, carga de trabalho |
| Material | Dados de entrada | Qualidade, formato, volume |
| Meio ambiente | Contexto externo | Perfil de clientes, mercado, regulação |
| Medição | Métricas e instrumentação | Eventos, definições, amostragem |
Essa lista é um ponto de partida. Se o problema é a rotatividade de engenheiros, ramos como liderança, carreira, remuneração, carga de trabalho e cultura servem melhor. Para o diagrama funcionar bem, cada causa deve caber em uma categoria sem dúvida, e o princípio MECE ajuda nessa revisão.
Quando usar e quando evitar
Quando usar
- Falhas recorrentes em produção e degradação de serviço
- Queda de métrica sem explicação clara, como ativação ou retenção
- Retrabalho, defeitos de qualidade e incidentes de processo
- Quando o grupo está preso a uma única explicação
Quando evitar
- Quando a causa é conhecida e o problema é executar a correção
- Quando o efeito ainda não pode ser medido nem descrito com clareza
- Para atribuir responsabilidade a pessoas ou equipes
- Para antecipar falhas de um projeto futuro: use o pré-mortem
Como aplicar
- Defina o efeito. Escreva métrica, período e impacto. “Ativação caiu de 40% para 30% em oito semanas” é melhor do que “o onboarding piorou”, que já embute uma causa.
- Reúna quem conhece o processo. Inclua áreas diferentes, para que as causas não venham de um só ponto de vista.
- Escolha as categorias. Use as tradicionais como base e adapte ao problema.
- Liste causas e subcausas. Em cada ramo, pergunte o que poderia produzir aquele efeito. Nesta etapa, ainda não descarte nada.
- Marque o status e priorize. Classifique cada causa, defina como verificá-la e comece pelas mais baratas de testar e de maior impacto potencial.
Exemplo: a ativação caiu depois do lançamento
Uma plataforma SaaS B2B lançou um assistente de IA junto com um novo onboarding. Uma conta é considerada ativada quando salva ou compartilha o primeiro resultado em até sete dias.
Efeito: a ativação caiu de 40% para 30% nas oito semanas seguintes ao lançamento. A divisão do funil em etapas mostra que a maior perda está entre conectar os dados e gerar o primeiro resultado.
| Categoria | Causa candidata | Status | Como verificar |
|---|---|---|---|
| Medição | Evento de geração mudou no lançamento | Sem suporte | Auditoria dos eventos |
| Máquina | Primeira geração é lenta em contas grandes | Evidenciada | Latência por tamanho de conta |
| Material | Formatos de dados que o assistente trata mal | Plausível | Amostra de gerações com erro |
| Método | Onboarding removeu o exemplo guiado | Plausível | Comparar coortes |
| Pessoas | Usuários não sabem o que pedir ao assistente | Plausível | Sessões gravadas e entrevistas |
| Meio ambiente | Campanha trouxe contas fora do perfil | Sem suporte | Ativação por canal |
Dois detalhes merecem atenção. O primeiro é a ordem: vale começar por Medição, porque, se a instrumentação mudou, a queda pode nem existir. Aqui a auditoria não encontrou mudança nos eventos, e a causa ficou sem suporte.
O segundo é o sentido de “evidenciada”. Os logs mostram que a lentidão existe, mas isso ainda não prova que ela causou a queda. A prova virá do aprofundamento e de um experimento. As duas causas mais promissoras seguem para os 5 Porquês.
Como usar uma LLM
Uma LLM ajuda a sugerir categorias, lembrar causas esquecidas e transformar anotações de reunião em uma estrutura hierárquica. Ela não vê seus logs e pode escrever uma causa plausível como se fosse fato, por isso o status de cada item precisa vir das suas evidências.
Atue como facilitador de análise de causa e efeito.Efeito observado: [problema mensurável, período e impacto].Contexto: [sistema/equipe/processo].Evidências: [dados, relatos e registros].
Estruture um diagrama de Ishikawa em categorias adequadas ao problema.Liste causas possíveis e subcausas, marcando cada uma como evidenciada,plausível ou ainda sem suporte. Só marque como evidenciada o que estiverapoiado nas evidências fornecidas.
Sugira quais dados ou testes permitiriam refutar as hipóteses prioritárias.Entregue uma representação textual hierárquica que possa ser convertidaem diagrama. Não atribua culpa a pessoas.Saída esperada: uma árvore de hipóteses causais, cada uma com status, e um plano de investigação.
Antes de confiar na resposta:
- Confira o status. Causa marcada como evidenciada precisa apontar para um dado real.
- Compare com o que você sabe. Peça ao time para indicar o que está errado ou faltando.
- Procure causas ausentes. Pergunte qual categoria ficou fraca e por quê.
- Sanitize o contexto. Remova dados de clientes e nomes de pessoas de logs e relatos.
Combine com outros frameworks
- 5 Porquês: o Ishikawa mapeia hipóteses em amplitude, e os 5 Porquês aprofundam as mais promissoras. Os dois funcionam bem juntos.
- Princípio MECE: ajuda a definir categorias sem sobreposição e a localizar o problema antes do diagrama.
- Teste de hipótese: confirma ou refuta a causa escolhida com um experimento.
- Análise pré-mortem: antecipa falhas antes da execução, enquanto o Ishikawa investiga um problema já observado.
Referências
- Ishikawa, K. (1968). Guide to Quality Control. Tokyo: JUSE. Edição em inglês: Asian Productivity Organization, 1976.
- Wikipedia. Ishikawa diagram. Link