Laboratório: transformar um pedido real em especificação
Pegar um pedido vago do seu trabalho e sair com uma especificação que outra pessoa conseguiria executar e chegar ao mesmo número.
O teste de uma boa especificação é simples: outra pessoa do time executa e chega exatamente ao mesmo número.
Use um pedido que chegou para você nas últimas semanas e que você resolveu no impulso. A comparação entre o que você fez e o que a especificação pede costuma ser desconfortável — é justamente o ponto.
- Cole o pedido exatamente como chegou, com a redação original.
- Rode o prompt de abertura da aula 2.1 com o seu dicionário de dados.
- Classifique cada item: decido eu (técnico) / decide o negócio / não dá para responder com os dados que temos.
- Para os técnicos, escreva a decisão e o motivo em uma linha.
- Agrupe os de negócio em no máximo 4 perguntas e mande para quem pediu.
- Escreva a especificação com as respostas.
- Peça a alguém do time que leia e diga se conseguiria produzir o mesmo número. Anote cada dúvida.
- A especificação define numerador, denominador, janela, unidade e exclusões.
- Toda decisão de negócio tem nome e data de quem respondeu.
- Outra pessoa leu e disse que conseguiria reproduzir.
- O que os dados não respondem está escrito, não escondido.
Se travar: Se a análise da IA voltou genérica ("validar os dados", "verificar outliers"), você provavelmente colou o pedido resumido. Cole a mensagem original, com a redação truncada de quem escreveu no celular — a ambiguidade útil está ali.
O documento que transforma "consegue ver por quê?" em trabalho executável e conferível.
# Análise: [título] Pedido por: [nome] em [data] · Analista: [você] ## Pedido original > [cole sem editar] ## Pergunta reformulada [a pergunta específica que esta análise responde] ## Decisão que depende disto [o que vai ser feito com o resultado — define quanta precisão é necessária] ## Definições fixadas | Termo | Definição operacional | Quem decidiu | |-------|----------------------|--------------| | churn | sem pedido há 60 dias | [nome], [data] | ## Recorte - Período: [de/até] · Fuso: [America/Sao_Paulo] - Comparação contra: [período/grupo] — janelas de mesmo tamanho? [sim/não] - Unidade de análise: [cliente / pedido / receita] - Exclusões: [lista] ## Explicações candidatas e como distinguir | Hipótese | Dado que confirma | Dado que refuta | |----------|-------------------|-----------------| ## O que os dados NÃO respondem - [limitação real, com o motivo] ## Conferências que vou fazer - [ ] Total bate com [fonte independente] - [ ] Contagem de linhas antes/depois de cada JOIN - [ ] Nulos medidos nas colunas agregadas
Onde guardar: No repositório de análises, junto do notebook ou do SQL.
"O que os dados NÃO respondem" é a que dá mais trabalho e mais protege. Escrever "não conseguimos separar cancelamento voluntário de involuntário porque o motivo não é registrado" evita que a conclusão seja usada para uma decisão que ela não sustenta.
Também é a seção que mais frequentemente vira uma melhoria de instrumentação no trimestre seguinte.
- Especificação boa é aquela em que outra pessoa chega ao mesmo número sem te perguntar nada.
Comentários e dúvidas
Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.
Inscrever-se grátis com GoogleAinda não há comentários nesta aula.