Não dá para negar: por mais que planejemos um projeto, algo que não foi mapeado anteriormente eventualmente aparecerá. Isso é um fato. E quando esses problemas não são compreendidos e resolvidos corretamente, eles podem gerar consequências sérias, como:

• Atrasos nas entregas
• Atrasos no lançamento de produtos ou melhorias
• Problemas com stakeholders
• Times se sentindo sob pressão
• Demissões

Também recomendo a leitura do meu artigo “Como medir a produtividade do seu time e como melhorá-la” para entender melhor a performance do time, e do artigo “Como usar a matriz de stakeholders para aumentar sua influência e melhorar a comunicação do projeto” para melhorar a gestão dos stakeholders envolvidos no seu projeto.

Voltando ao nosso tema, quando enfrentamos um problema, podemos usar técnicas específicas para obter uma compreensão mais profunda do que está acontecendo e buscar soluções que tratem o problema em sua origem. Em ambientes de projeto, os dados também podem apoiar essa investigação. Uma plataforma como o Saint Jude pode ajudar gestores a identificar padrões em atrasos, estimativas incorretas, performance do time, consumo de custos, qualidade das tarefas, desvios em sprints e riscos. Isso não substitui a análise de causa raiz, mas oferece melhores evidências para entender de onde o problema pode estar vindo.

Vamos para a nossa primeira técnica:

Formulação de hipóteses

Para formular boas hipóteses, primeiro precisamos entender o problema, suas características, seu contexto, as pessoas envolvidas, as relações entre elas, os procedimentos conectados ao problema e os resultados esperados em comparação com os resultados reais.

Usar ferramentas como um diagrama de sistema ou um diagrama de rede pode ser um bom ponto de partida para compreender a situação, especialmente quando queremos focar em processos, fluxos e resultados. Vou dar um exemplo e explicá-lo abaixo:

Diagrama de sistema - Diagrama de rede

• Retângulos representam algo acumulado ao longo do tempo, como população
• Setas representam fluxos, como taxas de nascimento e morte
• Círculos representam variáveis auxiliares, como densidade populacional
• Sinais de mais e menos representam se o fluxo está aumentando ou diminuindo

Análise de stakeholders

A análise de stakeholders nos ajuda a entender quem são os atores, como eles se relacionam entre si e, muitas vezes, o contexto em que estão inseridos. Menciono novamente meu artigo sobre esse tema: “Como usar a matriz de stakeholders para aumentar sua influência e melhorar a comunicação do projeto”.

Análise de cenários

Essa parte da formulação de hipóteses é usada para explorar cenários alternativos sobre como o problema pode evoluir e como podemos resolvê-lo. Baseamos essa análise em premissas, variáveis e incertezas. Depois, validamos as implicações e os riscos de cada cenário para apoiar a tomada de decisão. Aqui está um processo passo a passo:

1. Identificar o problema
2. Definir o que está influenciando o problema
3. Estabelecer como o problema pode evoluir no futuro
4. Construir diferentes cenários
5. Comparar os cenários, considerando vantagens, desvantagens, oportunidades, riscos e implicações

Exemplo:

• Problema: meu tech leader pediu um aumento salarial
• Influência: sobrecarga de trabalho e excesso de responsabilidade
• Possível evolução: pedido de demissão e atrasos nas entregas
• Cenários:
  • O tech leader pede demissão e não existe documentação do projeto
  • O tech leader começa a transferir responsabilidades para outra pessoa, mas sem documentação formal
  • Outros membros do time ficam insatisfeitos por causa de demandas inesperadas
  • O tech leader pede demissão e o gestor não tem desenvolvedores sêniores disponíveis

Disclaimer: tenha cuidado ao formular hipóteses com base em processos pouco claros ou stakeholders de alto impacto que não foram corretamente mapeados. A falta de clareza pode nos levar a cometer erros sérios na criação das nossas hipóteses.

Aqui, o Saint Jude pode apoiar a análise mostrando se o projeto já apresenta sinais de sobrecarga, como tarefas concentradas em uma única pessoa, atrasos por nível de senioridade, bugs recorrentes, descrições de tarefas pouco claras ou desequilíbrio entre alocação planejada e trabalho real. Esses indicadores podem ajudar gestores a criar hipóteses melhores em vez de se basearem apenas na percepção.

5 Porquês

Na minha opinião, a técnica dos 5 Porquês é uma das melhores e mais simples formas de descobrir a causa raiz de um problema. No entanto, ela funciona bem apenas quando é usada com transparência, mesmo quando estamos lidando com questões políticas dentro de uma empresa. Às vezes, as pessoas têm medo de dizer aquilo que é óbvio para todos. Quando isso acontece, a técnica perde parte da sua força.

Exemplo:

- Por que não temos acesso às máquinas de produção?

- Porque a área de segurança não nos forneceu o acesso.

- Por que a área de segurança não nos forneceu o acesso?

- Porque disseram que apenas o time de segurança pode acessar produção.

- Por que apenas o time de segurança pode acessar produção?

Todos pensando:

- Porque o CTO exigiu isso.

Mesmo quando a resposta parece óbvia, o exercício de continuar perguntando “por quê” até chegar à causa raiz pode ser revelador. Ele ajuda a separar suposições de fatos e torna o verdadeiro problema mais visível para todos os envolvidos.

Quais são as vantagens dos 5 Porquês?

Identifico vantagens como:

• Identificar falhas de processo
• Analisar baixa performance
• Investigar conflitos
• Compreender tendências
• Compreender o sucesso de um produto
• Compreender o fracasso de um produto

Como fazer o exercício dos 5 Porquês?

Apesar do nome, não é obrigatório parar na quinta pergunta ou chegar exatamente a cinco perguntas. O número cinco foi escolhido porque costuma ser uma boa medida para encontrar a causa raiz. O conceito é continuar perguntando até encontrar o verdadeiro motivo por trás do problema. No exemplo acima, eu poderia ter continuado com: “Por que o CTO exigiu que apenas o time de segurança acessasse produção?”

Outra prática útil é sempre começar a próxima pergunta usando a resposta anterior. Isso cria rastreabilidade e nos ajuda a seguir a lógica do problema. Exemplo:

- Por que as tarefas estão atrasadas?

- Porque os desenvolvedores estão estimando as tarefas de forma incorreta.

- Por que os desenvolvedores estão estimando as tarefas de forma incorreta?

No fim, quando encontramos a causa raiz, podemos avançar para a solução. Deixo aqui outro artigo que escrevi: “Como encontrar as soluções certas para os problemas do seu produto.”

Nesse exemplo, o Saint Jude pode ajudar a apoiar a investigação comparando duração estimada versus duração real das tarefas, identificando quais tipos de tarefas costumam atrasar, quais profissionais ou níveis de senioridade são mais impactados e se os atrasos estão ligados a bugs, user stories, subtarefas, features ou tags específicas. Isso torna o exercício dos 5 Porquês mais baseado em fatos e menos dependente de opiniões.

Diagrama de Ishikawa

O diagrama de Ishikawa, frequentemente chamado de diagrama de espinha de peixe, é uma técnica usada para compreender um problema a partir de uma perspectiva sistêmica. Em outras palavras, ele nos ajuda a dar um passo para trás e enxergar o cenário geral, em vez de olhar apenas para sintomas isolados.

Para usá-lo, podemos começar com um modelo como o da imagem abaixo, que explicarei passo a passo.

Cabeça do peixe – problema inicial

Aqui colocamos o problema inicial para o qual precisamos encontrar a causa raiz. Exemplo: Todas as nossas tarefas estão atrasadas.

Espinha de peixe e 6Ms

Na espinha de peixe, organizamos as possíveis causas relacionadas ao nosso problema principal, verificando se elas pertencem a uma das 6Ms:

• Máquina: todos os equipamentos, ferramentas e máquinas utilizadas
• Método: processos e instruções adotados
• Material: matérias-primas, componentes e informações
• Missão / Meio ambiente: ambiente da empresa, ambiente físico e propósito da empresa
• Medição: inspeções, sistemas de monitoramento e controles
• Mão de obra: pessoas envolvidas

Vamos para o nosso exemplo. Começaremos com o problema principal: “Todas as nossas tarefas estão atrasadas.” A partir desse problema, vamos posicionar possíveis causas na espinha de peixe. Exemplo:

• Máquina: falta de automação DevOps para deploys em staging e produção
• Método: os refinamentos não estão considerando a experiência dos desenvolvedores
• Material: nossos componentes não são reutilizáveis
• Meio ambiente: -
• Medição: -
• Mão de obra: muitos desenvolvedores juniores no time e falta de um profissional DevOps

Nosso diagrama:

Observe dois pontos importantes no nosso exemplo:

1. Nem todos os Ms foram preenchidos, apenas aqueles relacionados ao problema principal
2. Uma causa pode aparecer em dois ou mais Ms, como a experiência do time, que aparece em Método e Mão de obra, ou DevOps, que aparece em Máquina e Mão de obra

Disclaimer: no meu entendimento, quando a mesma causa aparece em dois ou mais pontos, ela é uma forte candidata a ser a causa raiz. Normalmente, eu a priorizo na minha lista de resoluções.

Disclaimer 2: o diagrama de Ishikawa pode ser usado em conjunto com a técnica dos 5 Porquês. Ao fazer isso, conseguimos identificar a causa raiz para cada M e definir subproblemas que precisam ser resolvidos para eliminar o problema principal.

Este é outro ponto em que o Saint Jude pode ajudar. Se o problema é “todas as tarefas estão atrasadas”, a plataforma pode ajudar a separar a análise por área, senioridade, função, tipo de tarefa, tag, custo, horas alocadas, horas consumidas e performance da sprint. Isso ajuda gestores a entender se o problema está relacionado a pessoas, processo, estimativa, qualidade das tarefas, carga de trabalho ou fluxo de entrega.

Problem statement

Por fim, depois de aplicar as técnicas para descobrir a causa raiz, precisamos definir o problem statement. Mas o que é um problem statement?

Um problem statement é uma declaração clara do problema que vamos resolver. É quase como uma declaração de guerra contra o problema. Nessa declaração, especificamos o escopo, por que o problema importa e quais objetivos queremos alcançar ao resolvê-lo. Também precisamos incluir critérios de aceitação e restrições. Abaixo, explicarei como construir esse documento e trarei um exemplo.

Como construir um problem statement

Para construí-lo, devemos:

• Definir o problema com clareza – descrever o que está acontecendo, onde, quando e por quê
• Identificar os stakeholders – definir quem é impactado pelo problema, suas expectativas, comportamentos e posição em relação a ele
• Definir critérios para avaliar a solução – aqui podemos usar critérios de aceitação e objetivos, como redução de custos, redução de tempo, melhoria de qualidade, melhoria de segurança, entre outros
• Quantificar o problema – se possível, quantificar o quanto o problema está prejudicando o projeto. Exemplo: 1 mês de atraso ou US$ 100.000 por semestre em custos adicionais
• Explicar a causa raiz – aqui podemos incluir os resultados encontrados por meio das técnicas explicadas acima

Disclaimer: lembre-se de que o problem statement deve ser SMART:

• Específico (S)
• Mensurável (M)
• Alcançável (A)
• Relevante (R)
• Temporal (T)

Vamos ao nosso exemplo:

“A taxa de atraso nas entregas de user stories do Time X é de aproximadamente 20%, o que gera cerca de 1 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 desses atrasos são a falta de experiência do time e estimativas imprecisas. Como podemos reduzir esses atrasos para 5% em 3 meses?”

Um problem statement forte depende de fatos. O Saint Jude pode apoiar essa etapa consolidando dados sobre cronograma, custos, estimativas de tarefas, performance dos profissionais, bugs, tipos de tarefas, desvios de sprint e indicadores de risco. Com essa visibilidade, gestores podem escrever problem statements baseados em evidências em vez de suposições.

A partir deste ponto, podemos avançar para a resolução. Aqui compartilho outro artigo sobre esse tema: “Como encontrar as soluções certas para os problemas do seu produto.”

Chego aqui ao fim deste artigo. Aqui, você aprendeu as principais técnicas para encontrar a causa raiz de um problema: formulação de hipóteses, análise de cenários, 5 Porquês, diagrama de Ishikawa e problem statement.

O que você achou deste artigo? Gostaria de adicionar alguma ferramenta que considera importante?

Dê um like neste artigo, comente no LinkedIn ou compartilhe nas suas redes sociais.

Até breve!

Erik Scaranello