Estruturação
de problemas:
da pergunta vaga ao plano de análise

Diante de um problema, a reação quase automática é pular direto para soluções. "Vendas caíram — vamos dar desconto." "O time está lento — vamos contratar." "O usuário reclama — vamos refazer a tela." O que quase ninguém faz é parar e perguntar: que problema, exatamente, eu estou tentando resolver, e do que ele é feito?

Estruturar um problema é o trabalho que acontece entre "recebi uma pergunta confusa" e "sei o que preciso descobrir". É converter uma névoa ("por que o resultado piorou?") em uma lista finita de sub-perguntas concretas, cada uma respondível com um dado, um cálculo ou uma conversa. Feito bem, o resto — pesquisar, analisar, decidir — vira quase mecânico. Feito mal, você trabalha muito e no fim descobriu a resposta certa para a pergunta errada.

Problema mal definido vs. bem definido

Repare que a coluna da direita não tem nenhuma resposta ainda — mas já diz onde procurar e como saber quando parou. Essa é a função da estrutura.

Sintomas de que falta estrutura

Definição de trabalho (a que usaremos na apostila inteira)

Por que isso independe de competência técnica

Um engenheiro de dados e um coordenador de RH usam a mesma operação mental para destrinchar "por que perdemos gente boa" ou "por que o pipeline está caro". As ferramentas mudam; a árvore, não. É por isso que consultorias contratam filósofos, historiadores e físicos para o mesmo cargo: o que treinam nos primeiros meses é exatamente esta apostila.

Antes de decompor, você precisa de uma frase que todo mundo na sala assine. Ela não é o título do e-mail ("Projeto Churn"); é uma pergunta fechada, com escopo, critério e prazo. Sem ela, cada pessoa decompõe uma árvore diferente.

2.1 O enunciado do problema (problem statement)

Um bom enunciado responde a seis coisas. Preencha todas antes de seguir:

2.2 SCQA: o atalho para chegar à pergunta

Ferramenta de Barbara Minto (ex-McKinsey) para extrair a pergunta central de qualquer situação:

• Situação — o que todos concordam que é verdade e estável.
• Complicação — o que mudou, quebrou ou ameaça essa situação.
• Questão — a pergunta que a complicação naturalmente levanta.
• Answer — (fica para depois; é a sua futura recomendação).

2.3 O teste dos "cinco porquês" para não parar na superfície

O problema apresentado quase nunca é o problema real. Pergunte "por quê?" até bater numa causa sobre a qual você pode agir:

2.4 Reformular: o mesmo problema, molduras diferentes

Como você enuncia o problema já decide metade das soluções possíveis. "Como reduzimos o tempo de fila do caixa?" convida a otimizar o caixa. "Como fazemos o cliente não sentir a fila?" abre espaço para pré-pedido, entretenimento, autoatendimento. Antes de fechar o enunciado, escreva três reformulações e escolha conscientemente — não aceite a primeira moldura que apareceu.

3.1 A árvore de questões (issue tree)

Você pega a pergunta central e a quebra em 2 a 4 sub-perguntas. Cada uma é quebrada de novo, até chegar a perguntas que se respondem com um dado, um cálculo ou uma conversa. O resultado é um mapa: cada folha é uma tarefa, e responder todas as folhas responde a raiz.

3.2 MECE: o critério de um bom corte

Sigla de Mutually Exclusive, Collectively Exhaustive — em português, mutuamente exclusivo e coletivamente exaustivo. Um conjunto de ramos é MECE quando:

• Mutuamente exclusivo: os ramos não se sobrepõem — nenhum caso cai em dois ao mesmo tempo. (Sobreposição = você conta a mesma coisa duas vezes e discute em círculo.)
• Coletivamente exaustivo: os ramos, juntos, cobrem 100% do espaço — não há caso que fique de fora. (Buraco = a causa real pode estar exatamente no que você não listou.)

3.3 Dois jeitos de cortar: por fórmula e por hipótese

3.4 Quão fundo ir?

Pare de dividir um ramo quando: (a) ele já é respondível com uma fonte concreta; (b) dividir mais não muda a ação que você tomaria; ou (c) o ramo já foi despriorizado (cap. 5) e não vale o esforço. Profundidade típica de uma árvore útil: 3 a 4 níveis. Mais que isso costuma ser precisão decorativa.

4.1 Trabalho guiado por hipótese (hypothesis-driven)

Em vez de responder toda a árvore de baixo pra cima, você formula desde o início uma resposta provável ("a queda de receita vem de mais cancelamentos entre clientes do plano básico") e organiza o trabalho para testar essa afirmação: que evidência a confirmaria, e — mais importante — que evidência a mataria?

Vantagem: foco brutal. Você não analisa o que não move a hipótese. Risco: se apegar à hipótese e enviesar a busca (cap. 10). Antídoto: escrever, junto da hipótese, o que você esperaria ver se ela estivesse errada.

4.2 A "resposta do dia 1" (day-one answer)

Prática de consultoria: no primeiro dia, com o pouco que se sabe, escreva a recomendação provável e a lógica que a sustentaria. Não é chute para defender — é alvo para atacar. Ela expõe quais são as 2 ou 3 suposições das quais tudo depende, e essas viram a prioridade da semana. A resposta do dia 1 quase sempre muda até o fim; o valor está em ter um fio desde o começo.

4.3 Dedução, indução e abdução — sem filosofar demais

Na prática você alterna os três: abduz uma hipótese, deduz o que ela implica, e induz a partir dos dados que coletar se o padrão se sustenta.

4.4 Falseabilidade: a pergunta que separa análise de torcida

"Que observação me faria abandonar esta hipótese?"

Se a resposta for "nenhuma", você não tem uma hipótese — tem uma crença. Toda hipótese útil vem com uma condição de morte explícita.

Assim que a árvore existe, a pergunta muda de "o que pode ser?" para "qual ramo, se eu resolver, mais muda a resposta final?". Todo ramo recebe uma decisão consciente: investigar agora, investigar depois ou podar.

5.1 Os dois eixos: impacto e facilidade

"Impacto na resposta" = se este ramo for a causa, o quanto isso muda a recomendação e a ação? Um ramo que explica 2% do problema é verdadeiro e irrelevante.

5.2 Dimensionar antes de analisar (o "sanity check")

Antes de mergulhar num ramo, faça uma estimativa de ordem de grandeza do tamanho dele. Se "aumento de custo de frete" só pode explicar, no máximo, R$ 200 mil de um buraco de R$ 5 milhões, ele sai da fila — sem análise detalhada. Essa poda por magnitude (às vezes chamada de "dividir para conquistar" ou back-of-the-envelope) elimina metade da árvore em minutos.

5.3 O teste do "e daí?" (so what?)

Para cada ramo que você pensa em investigar, pergunte: "se eu descobrir a resposta aqui, e daí? O que eu faço diferente?". Se a resposta for "nada" ou "não sei", o ramo não é prioridade — não importa quão interessante seja.

5.4 Podar em voz alta

Poda silenciosa vira acusação depois ("vocês nem olharam X!"). Registre: "Não investigamos câmbio porque a exposição é <5% da receita e está travada por hedge até dezembro." Uma linha. Protege a análise e mostra rigor.

Na prática, a árvore do cap. 3 depois da priorização fica assim — verde é o que sobrevive, riscado é o que foi podado, com o motivo ao lado:

Um framework é uma árvore pré-cortada para uma classe recorrente de problema. Bom uso: começar com ele e adaptar. Mau uso: forçar o problema a caber nele e apresentar a estrutura como se fosse a análise.

6.1 Catálogo mínimo

6.2 Como escolher

• Pergunta é "por que o número financeiro mudou?" → árvore de lucro, sempre primeiro.
• Pergunta envolve usuários passando por etapas → funil.
• Pergunta é "devemos entrar/sair/investir neste mercado?" → 3 Cs + 5 Forças.
• Pergunta é "por que este defeito volta?" → Ishikawa + 5 porquês no ramo mais provável.
• Pergunta é "por que este time/processo não entrega?" → Pessoas / Processo / Tecnologia.
• Nenhum encaixa → volte ao cap. 3 e corte por fórmula ou por hipótese, na mão.

7.1 O plano de análise (uma linha por folha)

Para cada folha priorizada, escreva antes de começar:

Definir o critério de conclusão antes de ver o dado é o que impede a análise de virar pesca — você não fica "olhando mais um recorte" à procura de um número que agrade.

7.2 A hierarquia da evidência (do barato ao caro)

1. Estimativa / lógica — "isso sequer pode ser grande?" (cap. 5). Minutos.
2. Dado que já existe — relatório, planilha, painel. Horas.
3. Conversa com quem sabe — 3 a 5 pessoas na ponta destravam o que semanas de planilha não mostram.
4. Análise nova sobre dado bruto — quando os três acima não bastaram.
5. Coleta nova (pesquisa, experimento) — só quando a decisão é grande e nada mais responde.

Suba a escada só até onde a decisão exige. Muita gente pula direto para o nível 4 porque parece "sério" — e gasta uma semana no que uma ligação resolveria.

7.3 Quanto rigor é suficiente?

Depende do custo do erro e da reversibilidade. Decisão pequena e reversível: uma estimativa e uma conversa bastam. Decisão grande e irreversível (fechar uma unidade, demitir, contrato de anos): você quer triangular — duas fontes independentes chegando à mesma conclusão. "Precisão proporcional às consequências."

8.1 O Princípio da Pirâmide (Barbara Minto)

Ideias se organizam em pirâmide: no topo, uma afirmação (a resposta à pergunta central). Abaixo, os 2 a 4 argumentos que a sustentam. Abaixo de cada um, a evidência. Regras:

• Ideias de um mesmo nível são MECE entre si (as mesmas regras do cap. 3, agora na resposta).
• Cada grupo de ideias resume o nível abaixo — não é só uma lista, é a síntese dela.
• A ordem dentro de um grupo tem lógica: por tempo, por estrutura, ou por importância.

8.2 Indução ou dedução na hora de agrupar

• Agrupamento indutivo: as ideias-filhas são do mesmo tipo e você as resume ("três razões pelas quais o custo não é o problema"). Mais comum, mais fácil de ler.
• Agrupamento dedutivo: premissa → premissa → portanto. Poderoso, mas frágil: se o leitor discorda de um passo, perde a cadeia toda. Use com moderação no topo.

8.3 O "so what?" em cadeia

Pegue cada achado e pergunte "e daí?" até chegar a uma implicação para a decisão. "O preço médio caiu 11%" → e daí? → "não foi desconto pontual, foi a tabela nova" → e daí? → "é uma mudança de política, então é reversível por decisão, não por mercado" → e daí? → "dá para agir nesta semana, sem depender de recuperação de demanda". O topo da pirâmide é o último "e daí".

8.4 O teste do elevador

Se você tivesse 30 segundos com quem decide, o que diria? Se não couber numa frase de resposta + três de apoio, a síntese ainda não terminou — você tem achados, não uma recomendação.

Uma árvore no seu caderno é ferramenta de pensamento. Apresentada, ela precisa virar sequência: pergunta → como cortamos → onde cavamos → o que sobrou. A demo abaixo mostra esse movimento no problema do lucro que caiu.

9.1 Regras de comunicação da estrutura

• Resposta primeiro (topo da pirâmide, cap. 8), depois o caminho. Quem decide não quer suspense.
• Título que afirma, não que rotula. "Preço, não volume, explica a queda" > "Análise de receita".
• Uma página com a árvore podada e o ramo vivo destacado vale mais que 20 slides de recortes.
• Mostre o que você podou e por quê — é o que responde o cético antes de ele perguntar.

10.1 Os vieses que atacam a estruturação

10.2 MECE teatral e outras patologias de estrutura

• MECE teatral: uma árvore lindamente simétrica que não mapeia a realidade — categorias criadas para fechar a taxonomia, não para explicar. Teste: cada ramo tem um exemplo real e concreto?
• Árvore sem hipótese: decompor exaustivamente e nunca arriscar uma resposta — vira catálogo, não análise (cap. 4).
• Profundidade decorativa: seis níveis de detalhe onde a ação já estava decidida no segundo.
• Análise-paralisia: a árvore vira desculpa para nunca decidir. Antídoto: prazo e critério de "bom o suficiente" definidos antes (cap. 7.3).

10.3 Quando a decomposição linear falha: problemas perversos

Alguns problemas — chamados wicked problems por Rittel e Webber — resistem à árvore porque:

• Não há formulação definitiva: entender o problema e resolvê-lo são a mesma atividade.
• Não há "certo/errado", só "melhor/pior", e não há teste final que encerre.
• Toda intervenção muda o problema (é uma "operação de sentido único" — não dá pra testar e desfazer).
• As causas são interdependentes e formam laços de realimentação, não uma cadeia.

Exemplos: evasão escolar, rotatividade crônica, saúde de um ecossistema de produto, cultura organizacional, mudança climática. Para eles, a árvore ainda ajuda a mapear o terreno, mas você complementa com:

12.1 Plano de treino — 30 dias, ~25 min/dia

12.2 Checklist universal (antes de fechar qualquer análise)

12.3 Como levar isso para o currículo e a entrevista

• Nomeie com o vocabulário do mercado: "raciocínio estruturado", "problem solving", "pensamento analítico", "hypothesis-driven", "síntese executiva".
• Prove com artefatos: uma página de recomendação com árvore podada (antes/depois), um one-pager de decisão, a autópsia de caso do Exercício 11.2. Estrutura visível > adjetivo.
• Nos cases de entrevista: peça 30 segundos, enuncie o problema de volta com número e prazo, desenhe a árvore em voz alta ("vou quebrar isto em receita e custo, porque..."), priorize explicitamente ("começaria por preço, porque é o mais rápido de checar e um dos de maior impacto"), e feche com "resposta primeiro".
• Meça: decisões tomadas no prazo, retrabalho de análise evitado, recomendações aceitas. Raciocínio que não vira decisão vira "soft skill" descartável na triagem.

12.4 Biblioteca essencial para seguir avançando

• Estruturação e síntese: "O Princípio da Pirâmide" (Barbara Minto) · "Bulletproof Problem Solving" (Charles Conn & Robert McLean) · "Cracked it!" (Garrette, Phelps & Sibony)
• Decisão e vieses: "Rápido e Devagar" (Daniel Kahneman) · "Pensando em Apostas" (Annie Duke) · "Noise" (Kahneman, Sibony & Sunstein) · "Superprevisões" (Tetlock & Gardner)
• Pensamento sistêmico: "Thinking in Systems" (Donella Meadows) · "The Fifth Discipline" (Peter Senge)
• Problemas perversos e complexidade: "Dilemmas in a General Theory of Planning" (Rittel & Webber, artigo de 1973) · trabalhos de Dave Snowden sobre o framework Cynefin