Como estruturo um problema antes de analisar qualquer coisa
TL;DR
A maioria dos BAs começa a análise antes de entender se a pergunta em si faz sentido. O framework que uso na empresa onde trabalho tem quatro perguntas que faço antes de abrir qualquer SQL - e elas me poupam mais tempo do que qualquer ferramenta de dados que já usei.
O problema com "vou analisar pra ver"
Toda semana, em algum time de produto ou dados, alguém recebe uma tarefa parecida com essa:
"Consegue olhar por que as conversões caíram em março?"
E essa pessoa - talvez você, talvez eu - abre o Metabase, puxa os dados, segmenta por cohort, por canal, por dispositivo, por horário. Passa dois dias nisso. Chega a uma conclusão.
E aí descobre que a queda em março acontece todo ano. Sazonalidade histórica. Ninguém tinha comparado com o março do ano anterior antes de pedir a análise.
Esse exemplo é real. Aconteceu comigo na empresa onde trabalho.
O problema não era falta de habilidade técnica. O problema era que eu tinha começado a responder antes de entender o que estava sendo perguntado de verdade.
"Vou analisar pra ver" é uma armadilha. Parece proativo. Na prática, é uma forma de evitar a conversa mais difícil - a que você precisa ter antes de qualquer análise.
O que a maioria pula
Quando um BA recebe uma solicitação, existe uma sequência implícita que a maioria ignora:
→ Alguém observou algo (ou acha que observou)
→ Alguém formulou uma pergunta a partir dessa observação
→ Essa pergunta chegou até você como tarefa
O problema é que cada etapa dessa sequência pode estar errada.
A observação pode ser baseada em dado com viés de período. A pergunta pode ter sido formulada com um pressuposto falso. E você recebe a tarefa já carregada com todos esses erros embutidos - sem saber.
Se você começa a análise sem questionar a tarefa, você está respondendo a pergunta errada de forma muito competente.
Isso não é análise. É execução.
Existe uma diferença enorme entre o BA que executa e o BA que pensa. O que executa entrega o que foi pedido. O que pensa entrega o que resolve o problema.
As 4 perguntas que faço antes de qualquer análise
Ao longo de projetos na empresa onde trabalho, desenvolvi um hábito: antes de abrir qualquer ferramenta, faço quatro perguntas. Às vezes para mim mesmo, às vezes para o stakeholder diretamente.
1. Qual decisão vai ser tomada com esse resultado?
Essa pergunta parece óbvia mas raramente tem uma resposta clara.
Se a pessoa que pediu a análise não consegue me dizer o que vai fazer diferente dependendo do que eu encontrar, há algo errado com o pedido.
Análise sem decisão atrelada é pesquisa acadêmica. Pode ser valiosa, mas não é o que um BA está sendo pago para fazer.
Na prática: peço para o stakeholder descrever dois cenários - "se os dados mostrarem X, vou fazer Y" e "se mostrarem W, vou fazer Z". Se ele não consegue fazer isso, voltamos um passo.
2. O que precisaria ser verdade para essa decisão mudar?
Essa é a mais poderosa das quatro.
Ela inverte a lógica. Em vez de "o que os dados dizem?", a pergunta passa a ser "o que os dados precisariam dizer para mudar o que já está sendo considerado?"
Às vezes você descobre que a decisão já foi tomada e a análise é só para justificá-la. Isso também é informação útil - muda completamente como você deve conduzir o trabalho.
Outras vezes você percebe que o limiar de decisão é muito baixo. A pessoa já vai mudar de comportamento com qualquer sinal positivo - então você não precisa de um estudo de 30 dias. Uma análise exploratória de 3 dias já resolve.
3. Já tentamos responder isso antes?
Análises repetidas são um desperdício enorme de tempo que ninguém admite.
Antes de começar qualquer coisa, verifico se há análise anterior sobre o mesmo tema - em Confluence, Notion, Google Docs, repositório de notebooks. Não importa onde.
Se existir, começo por lá. Talvez a resposta já exista. Talvez o problema seja que ninguém fez nada com ela da última vez - o que é uma informação diferente e mais relevante.
4. Qual é o dado mais simples que responde essa pergunta?
BAs tendem a superestimar a complexidade da análise necessária.
Antes de construir um modelo ou uma dashboard complexa, pergunto: existe um número, uma razão, uma comparação simples que já responde 80% da pergunta?
Frequentemente existe. E entregar esse 80% em um dia vale mais do que entregar 100% em duas semanas.
Exemplo real: como apliquei na empresa onde trabalho
Um time de produto me pediu uma análise sobre por que usuários de uma feature específica tinham uma taxa de retenção 30% menor do que a média.
A pergunta implícita: "temos que consertar essa feature?"
Apliquei o framework antes de qualquer análise.
Decisão atrelada: o time estava considerando desativar a feature e redirecionar o desenvolvimento para outra coisa. Ok - decisão clara.
O que precisaria ser verdade para mudar: a feature precisaria mostrar retenção pelo menos equivalente à média, ou crescimento acelerado que justificasse o investimento contínuo.
Análise anterior: havia um estudo de 6 meses atrás que concluía a mesma coisa - retenção baixa. Mas o time tinha mudado desde então e ninguém sabia desse estudo.
Dado mais simples: antes de construir qualquer modelo, calculei a retenção por cohort de entrada (mês a mês). Descobri que os cohorts mais recentes tinham retenção crescente - a feature estava melhorando ao longo do tempo.
O estudo de 6 meses atrás estava correto naquele momento. Mas a conclusão era diferente hoje.
Com essas quatro perguntas, entrei na análise com hipótese clara, escopo certo, e consciência do contexto histórico. Duas horas de trabalho evitaram uma decisão de produto equivocada.
Para o BA: como começar amanhã
Você não precisa criar um processo formal para isso. Começa com uma mudança simples de comportamento.
Na próxima vez que receber um pedido de análise, antes de abrir qualquer ferramenta, escreva numa linha:
"Quem vai usar esse resultado, para tomar qual decisão?"
Se você não consegue responder essa frase em uma linha, volte para o stakeholder antes de começar.
E se você não tem acesso direto ao stakeholder? Fala com quem pediu a análise. Pergunte: "Quem vai usar esse resultado e para tomar qual decisão?" Se nem essa pessoa sabe, a análise não deveria ter começado.
Não como burocracia. Como eficiência.
A análise que responde a pergunta certa em dois dias vale infinitamente mais do que a análise perfeita que responde a pergunta errada em duas semanas.
Esse é o trabalho real de um BA. Não é SQL. Não é dashboard. É saber qual pergunta merece ser respondida.
