Resposta direta
Problem framing para times de dados é o processo de transformar um pedido ambíguo em problema analítico bem definido antes da execução. Ele explicita decisão-alvo, hipótese, dados necessários, restrições, owner e critério de sucesso.
O maior desperdício de um time de dados costuma começar antes do backlog.
Alguém pede um dashboard, um modelo, uma análise, uma base ou uma automação. O pedido parece claro porque tem nome de solução. Só que a solução nomeada pode esconder um problema mal formulado.
Problem framing é a disciplina de parar antes da execução para formular o problema certo.
O que é problem framing em dados
Problem framing é o enquadramento do problema antes da análise, modelagem ou construção.
Em dados, isso significa transformar uma demanda vaga em decisão-alvo, hipótese analítica, dados necessários, nível de granularidade, restrições, owner e critério de sucesso.
O objetivo não é criar burocracia. É evitar que o time resolva com eficiência uma pergunta que não deveria ter sido feita daquele jeito.
Por que isso importa
Times de dados são frequentemente pressionados por velocidade.
Só que velocidade sem framing aumenta retrabalho. O time entrega rápido, descobre tarde que a métrica não tinha definição comum, que o dado não sustentava a pergunta ou que o resultado não tinha ação possível.
A Slalom descreve problem framing para data scientists como a passagem de um objetivo abstrato para um problema que pode ser tratado com dados. Essa passagem é uma das lacunas mais comuns em empresas que querem ser data-driven.
Onde o pedido costuma quebrar
Pedidos de dados quebram em alguns lugares conhecidos:
- a decisão-alvo não está clara;
- o usuário real não participou;
- a métrica tem definição conflitante;
- a fonte existe, mas não tem qualidade suficiente;
- o resultado não aponta ação;
- o sponsor quer certeza onde só existe probabilidade;
- a solução foi escolhida antes da hipótese.
Cada um desses pontos deveria aparecer antes do backlog.
As 12 perguntas antes do backlog
Use estas perguntas como filtro inicial:
- Que decisão precisa melhorar?
- Quem toma essa decisão hoje?
- Com que frequência essa decisão acontece?
- Que evidência é usada atualmente?
- O que está errado ou insuficiente no processo atual?
- Que hipótese queremos testar?
- Que dados seriam necessários?
- Esses dados existem com qualidade, granularidade e permissão adequadas?
- Que ação será tomada se a hipótese se confirmar?
- Que ação será tomada se a hipótese cair?
- Que métrica mostrará mudança real?
- Quem será dono da adoção depois da entrega?
Se as respostas forem vagas, a demanda precisa de framing antes de virar execução.
Exemplo: pedido de churn
Pedido fraco: "precisamos de um modelo de churn".
Pedido melhor formulado: "queremos identificar contas com risco de não renovar nos próximos 90 dias para priorizar intervenção do time de customer success, reduzindo perda de receita em contas estratégicas".
A segunda formulação altera as decisões técnicas e operacionais seguintes: janela temporal, unidade de análise, custo de falso positivo, ação operacional, métrica de sucesso e owner.
O problema deixa de ser "construir modelo" e vira "melhorar uma decisão de retenção".
Relação com Strategic Framing
Problem framing é uma camada essencial do Strategic Framing em Dados.
O problem framing organiza a pergunta. O strategic framing conecta essa pergunta a prioridade, roadmap, valor, métrica de decisão e narrativa executiva.
Em organizações maiores, as duas coisas precisam andar juntas. Uma pergunta bem formulada ainda pode não merecer prioridade. Uma prioridade executiva ainda pode estar mal formulada.
Como usar em rituais reais
Você não precisa criar uma cerimônia pesada.
Antes de aceitar uma demanda, peça uma ficha de uma página com decisão, hipótese, dado necessário, ação esperada e métrica de sucesso.
Em discovery, use as 12 perguntas para revelar lacunas. Em planejamento, compare iniciativas pelo valor da decisão que cada uma melhora. Em review, volte à hipótese original e veja se ela sobreviveu ao uso real.
Esse ciclo evita que o time vire fábrica de artefato.
O papel do Data Translator
O Data Translator ajuda a sustentar problem framing quando existe pressão por solução rápida.
Ele traduz o pedido do negócio para uma hipótese que dados consiga avaliar e traduz a restrição técnica para uma consequência que liderança consiga decidir.
Esse repertório conecta Análise, BI e Comunicação, Produto de Dados e Estratégia de Negócio.
Critério final
Uma demanda está pronta para o backlog quando o time consegue completar esta frase:
Vamos usar dados para melhorar a decisão de [quem] sobre [qual escolha], porque acreditamos que [hipótese], e saberemos que funcionou quando [métrica de decisão] mudar.
Se a frase não fecha, a melhor entrega agora é formular melhor o problema.
Para aprofundar, leia Como definir uma métrica de decisão e faça o Radar de Competências para identificar onde sua fluência de framing ainda quebra.