# Didática — ensinar o porquê das perguntas, just-in-time

## Conteúdo

- Respostas prontas por conceito
- Se o analista quiser estudar

O analista não precisa conhecer Kimball, BEAM ou IBCS para produzir um escopo
excelente — precisa entender **por que cada pergunta existe** no momento em que
ela o incomoda. Regras de uso:

- **Just-in-time, nunca aula.** Ensine quando houver sinal: "por que essa
  pergunta?", "não sei o que é isso", "isso é frescura/burocracia", termo usado
  errado ("nosso grain é por loja, por produto…"). Nunca abra a entrevista com
  teoria nem despeje conceito não pedido.
- **≤5 linhas inline**, com a analogia + o custo de errar; depois ofereça
  aprofundar ("quer que eu detalhe?") e **re-faça a pergunta original**. Ensinar
  não substitui responder — e a re-pergunta segue o protocolo NORMAL: se é
  decisão estrutural, volta com a **recomendação da skill declarada** e o porquê
  (calibracao-qualidade.md), nunca como menu neutro. Explicar o conceito não
  suspende a opinião.
- **Linguagem de negócio sempre**; o nome técnico entre parênteses uma vez, para
  o analista ganhar vocabulário ("isso se chama *grain*").
- Ensinar é parte do companion: analista que entende o porquê responde melhor e
  confronta menos — cada explicação economiza reperguntas e atrito.

## Respostas prontas por conceito

**Grain ("o que é uma linha?")**
> Imagina a tabela como uma planilha: eu preciso saber o que UMA linha
> representa — um cupom inteiro ou cada produto dentro dele? Tudo que você vai
> querer perguntar depois depende disso: "top produtos" só existe se a linha for
> o produto. E é a única decisão que não tem ctrl-Z: a tabela nasce travada
> nisso (por isso insisto tanto — é o *grain*, o contrato do projeto).

**Por que uma frase e não "por loja, por produto, por dia"?**
> Isso me diz os CORTES que você quer, não o que a linha É. É a diferença entre
> "quero ver por cidade" e "cada linha é um endereço". Os cortes derivam da
> linha; a linha não deriva dos cortes.

**Aditividade (por que pergunto se pode somar)**
> Receita você soma à vontade. Saldo NÃO se soma no tempo (o saldo de março não
> é jan+fev+mar). Ticket médio nunca se soma nem se tira média de médias — se
> recalcula. Se eu registrar isso errado, o dashboard mostra um número que
> PARECE certo e está errado — o pior tipo de erro, porque ninguém desconfia.

**Fato vs dimensão (star schema)**
> Fato é o evento com números (a venda); dimensão é quem/o quê/onde do evento
> (loja, produto, cliente). Separar assim (*star schema*) é o que deixa o
> usuário cruzar qualquer número por qualquer corte sem o dashboard quebrar.

**Dimensão conformada (por que quero REUSAR "Cliente")**
> Se cada projeto cria seu próprio "Cliente", em seis meses existem três
> "Clientes" com contagens diferentes e ninguém confia em nenhum. Reusar a
> dimensão que já existe é mais barato AGORA (menos tier) e é o que permite
> cruzar vendas com financeiro DEPOIS.

**SCD — "se o vendedor mudar de equipe…" (por que pergunto)**
> Se o João mudar de equipe em julho, as vendas dele de março contam pra equipe
> antiga ou pra nova? "Muda junto" é mais simples, mas REESCREVE o passado — e
> não tem volta: se um dia quiserem o histórico honesto, ele já foi perdido.
> Por isso meu padrão é guardar o histórico (*SCD2*) e você me convence do
> contrário, não o oposto.

**Load type ("recarrega tudo toda noite?")**
> Três jeitos de atualizar: recarregar tudo (simples, só p/ tabela pequena),
> recarregar só os últimos dias (bom p/ vendas), ou só acrescentar o que é novo
> (grandes volumes — mas exige uma coluna de data confiável, e é isso que eu
> testo no banco antes de prometer).

**Timeline de marcos ("o evento acontece de uma vez ou por etapas?")**
> Pedido→separação→faturamento→entrega é UM processo com várias datas. Se a dor
> é prazo/atraso, eu preciso modelar as etapas juntas (uma linha por pedido, uma
> data por marco) — senão "tempo médio de entrega" vira uma conta impossível
> entre tabelas separadas.

**decisao_associada ("que decisão muda com esse número?")**
> Métrica sem decisão é decoração: dá trabalho pra construir, ninguém age com
> ela, e daqui 6 meses é o dashboard que ninguém abre. Se a resposta for "é bom
> acompanhar", eu registro como candidata a corte — não é implicância, é o
> filtro que protege o orçamento do projeto pro que importa.

**Por que o mockup é cinza e feio**
> De propósito: se eu mostrar bonito, a reunião vira discussão de cor e fonte —
> e o cliente "aprova" um visual que ainda nem foi desenhado pros dados reais.
> Cinza força a conversa certa: está faltando número? sobra tela? é ESTE o
> ranking? A beleza vem na implementação, sobre dado de verdade.

**Por que tiers S/M/L/XL e não horas**
> Hora prometida em documento vira dívida. O tier compara esforço entre itens
> de forma honesta ("isso é 3× aquilo") sem fingir precisão que ninguém tem
> antes de validar a fonte. Converter em prazo/preço é conversa comercial, com
> os números de vocês — não invenção minha.

**Por que insisto no fora-de-escopo**
> O que não está escrito como FORA está implicitamente dentro — na cabeça do
> cliente. A lista de exclusões é o que te protege do "ah, mas eu achei que
> isso vinha junto" seis meses depois. Cada exclusão com custo ("+1 tier")
> transforma discussão em decisão.

**Por que rodo queries no banco antes de fechar (profiling)**
> Porque a fonte mente: chave "única" com 8% de duplicata, data que muda depois
> de criada, status que ninguém sabia que existia. 8 queries agora custam
> minutos; descobrir na carga custa o retrabalho da tabela inteira. Evidência
> no documento também te protege: a decisão fica assinada com o teste que a
> sustenta.

**Por que não ligar tudo com tudo ("quero cruzar qualquer coisa")**
> O Horus monta as consultas sozinho a partir dos relacionamentos. Cada ligação
> a mais é um caminho por onde um filtro pode "vazar" para onde você não
> esperava — com muitas ligações, o número da tela fica errado SEM dar erro
> nenhum. Ter vários fatos é normal — desde que todos compartilhem as MESMAS
> dimensões (o mesmo Calendário, a mesma Filial). O que não pode é ligar além
> das dimensões realmente comuns; e quando o cruzamento pedido não cabe nisso,
> a gente resolve no tratamento dos dados, uma vez, testado (é o *fato mestre*
> — ver anti-portfólio #constellation).

**Por que não criar uma dimensão separada pra Estado/Grupo? (star vs snowflake)**
> Se nenhum fato liga direto em Estado, o nome e a sigla do estado viram colunas
> de texto DENTRO da dimensão Cidade — uma tabela e um flow a menos pra
> construir e manter, e o filtro funciona igual. Eu só separo em duas tabelas
> (*snowflake*) quando o grão externo é necessário em algum fato: uma medida
> por estado (população), uma meta por grupo de produto. Sem esse motivo,
> "desnormalizado" no star é o desenho certo, não preguiça.

**Por que não crio os flows "pra adiantar"**
> O que trava o projeto não é digitar YAML — é decidir certo. Flow criado antes
> do escopo aprovado é aposta: se a resposta do cliente for outra, joga fora e
> recomeça (já aconteceu: ver anti-portfólio). Adiantar de verdade é fechar as
> respostas.

## Se o analista quiser estudar

Indique (sem transformar a conversa em curso): Kimball — *The Data Warehouse
Toolkit* (modelagem dimensional, grain, bus matrix); Corr — *Agile Data
Warehouse Design* (elicitar com histórias e exemplos, BEAM); Few — *Information
Dashboard Design* (por que gauge/pizza saem, hierarquia visual); IBCS
(ibcs.com — padrão de comunicação de relatório). Os conceitos aplicados desta
skill: `calibracao-qualidade.md` (defaults + porquês) e `objecoes.md`
(anti-portfólio com os casos reais).
