SQL e Design de Painel Que Conquistam a Confiança das Partes Interessadas

O CEO abre o painel de receita na segunda-feira de manhã. Há 14 gráficos. Três deles têm a palavra "receita" no título. Mostram números diferentes. Ele manda uma mensagem no Slack: "espera, o que receita significa aqui?" Você gasta 30 minutos explicando a diferença entre receita reservada, reconhecida e coletada. Ele agradece, fecha a aba e volta para a exportação do Stripe que a líder de finanças enviou porque, pelo menos, aquele número não discute consigo mesmo.

Esse painel não falhou por ter muitos gráficos. Falhou porque dois deles diziam coisas diferentes e ninguém na sala conseguia defender nenhum dos dois.

A dor no trabalho de BA não é o volume. É que cada painel que você entrega é uma promessa (esse é o número, você pode agir com base nele), e a maioria dos BAs entrega essa promessa sem fazer o trabalho que a torna defensável. Este texto é sobre esse trabalho. Os padrões de SQL, as escolhas de layout, a higiene no dbt e a disciplina de descontinuação que transformam uma cozinha de 14 gráficos em um número no qual uma parte interessada apostará o budget de um trimestre.

Design de Painel: Uma Decisão por Painel

A pergunta mais útil antes de construir qualquer coisa: qual ação este painel gera?

Se a parte interessada não consegue completar a frase "depois de olhar isso, eu vou..." em português simples, você não tem um painel. Tem um papel de parede. Elimine ou divida.

Uma decisão por painel. Não três. O painel de ARR responde "estamos no plano este trimestre." O painel de cobertura de pipeline responde "temos deals suficientes para bater o próximo trimestre." São decisões diferentes, públicos diferentes, cadências diferentes. Não pertencem à mesma tela só porque ambas envolvem vendas.

Hierarquia Visual: A Regra dos 2 Segundos

Quando o painel carrega, o olho da parte interessada deve pousar na resposta em menos de 2 segundos. Isso significa:

• Canto superior esquerdo: o número principal. Grande, em negrito, com a comparação embutida (R$ 4,2M ARR · +6% vs. plano). Não "Receita Acumulada no Ano" com um gráfico de linha abaixo que você precisa ler.
• Abaixo do título: 2 a 4 cortes de apoio que explicam por que o número principal é o que é. Por segmento, por região, por movimento. Não 12 cortes. Quatro.
• Drill-downs em abas ou clique-para-detalhar: quem quiser a cauda longa pode chegar lá. Não faça a visualização padrão carregar esse peso.

Se o número principal do seu painel está no gráfico 7 de 14, você inverteu a pirâmide. A maioria dos BAs faz isso porque tem medo de deixar algo de fora. Tenha mais medo de as partes interessadas não saberem para onde olhar.

Disciplina de Cor: Pare de Construir Sacos de Bala

A maioria dos painéis de BA é um saco de bala. Oito cores categóricas, três cores de destaque, um mapa de calor, duas paletas divergentes e um semáforo, tudo na mesma página. Isso é ruído, não sinal.

Escolha uma restrição e mantenha-a:

• Uma cor de destaque para "bom" (geralmente um verde ou azul da marca).
• Uma cor de destaque para "alerta" (geralmente vermelho ou laranja).
• Todo o resto em escala de cinza neutro.

Se você se pegar usando uma quarta cor, o problema não é que você precisa de mais cores. O problema é que está tentando mostrar coisas demais em um único gráfico. Divida o gráfico.

Anotações Superam Legendas

Uma legenda é algo que a parte interessada precisa ler, decodificar e lembrar. Uma anotação é o gráfico falando com ela.

Uma legenda de duas linhas ao lado de uma queda no Q3 ("queda no Q3 = mudança de precificação publicada em 14 de agosto, previsão de recuperação até o Q4") previne 80% das mensagens de Slack de acompanhamento. Os outros 20% são sobre algo que o painel não foi construído para responder, o que também é informação útil.

Torne as anotações um hábito. Todo gráfico com uma forma não óbvia recebe uma explicação de uma frase dentro do próprio gráfico, não em um documento separado que ninguém lê.

Práticas de SQL Que Entregam Confiança

O painel é a porta de entrada. O SQL por baixo é a fundação. As partes interessadas não veem o SQL, mas o sentem toda vez que o número muda e você não consegue explicar por quê.

CTEs em Vez de Subconsultas Aninhadas

Compare estas duas queries que fazem a mesma coisa:

-- A versão com subconsulta aninhada (não faça isso)
SELECT customer_id,
       SUM(amount) AS revenue
FROM (
  SELECT *
  FROM orders
  WHERE status = 'paid'
    AND created_at >= '2026-01-01'
    AND customer_id IN (
      SELECT id FROM customers
      WHERE region = 'NA'
        AND tier IN ('enterprise', 'mid-market')
    )
) paid_orders
GROUP BY customer_id;

-- A versão com CTE (faça isso)
WITH na_target_customers AS (
  SELECT id
  FROM customers
  WHERE region = 'NA'
    AND tier IN ('enterprise', 'mid-market')
),

paid_orders_2026 AS (
  SELECT customer_id, amount
  FROM orders
  WHERE status = 'paid'
    AND created_at >= '2026-01-01'
)

SELECT po.customer_id,
       SUM(po.amount) AS revenue
FROM paid_orders_2026 po
JOIN na_target_customers c
  ON po.customer_id = c.id
GROUP BY po.customer_id;

Mesmo resultado. A versão com CTE tem nomes. Um colega consegue lê-la em 30 segundos. A versão aninhada é um quebra-cabeça. Uma query que um colega não consegue ler em 30 segundos é uma query que vai quebrar silenciosamente em 6 meses quando alguém mudar a definição de tier de cliente e ninguém notar porque não conseguia encontrar o filtro.

CTEs custam quatro linhas a mais e compram uma query que sobrevive à rotatividade da equipe.

Modelos dbt com Fonte Única da Verdade

Se receita é calculada em quatro painéis, vai divergir em quatro painéis. Não "pode divergir." Vai. Alguém vai ajustar um para excluir reembolsos. Outra pessoa vai ajustar outro para incluir conversões de trial. Seis meses depois, quatro painéis mostram quatro números e a confiança está destruída.

Centralize a métrica em um modelo dbt. Um arquivo. Uma definição. Depois, todo painel, todo explore do Looker, todo notebook do Hex referencia esse modelo e somente esse modelo. Se finanças quer mudar como a receita é calculada, muda uma vez, e todo artefato downstream se atualiza.

Isso não é opcional. É a diferença entre uma equipe de BA que escala e uma equipe de BA que passa o Q4 todo ano reconciliando números em que ninguém acredita.

Testes Nomeados em Todo Modelo de Métrica

O dbt oferece quatro testes integrados que capturam a maioria das derivações silenciosas:

version: 2

models:
  - name: fct_revenue_recognized
    description: "Receita reconhecida conforme política GAAP da empresa. Responsável: finance-data."
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('dim_customers')
              field: customer_id
      - name: revenue_status
        tests:
          - accepted_values:
              values: ['recognized', 'deferred', 'refunded']

Execute esses testes em todo PR. Se alguém adicionar um novo valor de revenue_status upstream e esquecer de atualizar o modelo, o teste falha antes que o painel falhe. Da primeira vez que um teste not_null capturar um bug em dados de produção, você vai se perguntar como algum dia entregou sem ele.

Comente o Porquê, Não o O Quê

-- Ruim: diz o que o código já diz
WHERE status = 'paid'

-- Bom: diz por que a regra existe
-- Finanças exclui reembolsos processados mais de 30 dias após o pedido
-- conforme política de receita v3 (assinada pelo CFO no Q4-2025).
WHERE status = 'paid'
  AND NOT (status_changed_at > created_at + INTERVAL '30 days'
           AND status = 'refunded')

O comentário ruim é ruído. O comentário bom é a única coisa que vai salvar o próximo BA que herdar essa query em um ano. Escreva o porquê. Especialmente para qualquer regra de negócio que não seja óbvia pelo nome da coluna.

O Diagnóstico das "Duas Definições de Receita"

Aqui está o movimento de construção de confiança mais útil que um BA pode fazer nos primeiros 90 dias, e não envolve escrever um único painel.

Vá até o seu líder de finanças. Pergunte a ele, numa ligação: "como calculamos receita?" Anote a resposta.

Vá até o seu líder de vendas. Faça a mesma pergunta. Anote a resposta.

Eles vão dar respostas diferentes.

Vendas vai falar sobre ACV reservado: negócios fechados, contratos assinados, o número no placar. Finanças vai falar sobre receita reconhecida: caixa coletado líquido de reembolsos, diferido conforme política, o número que vai para o conselho. Ambos estão corretos. Ambos são reais. Estão respondendo perguntas diferentes. E agora mesmo, em algum lugar da sua empresa, um painel está mostrando um deles e chamando de "receita" sem dizer qual.

Documente ambos. Nomeie-os claramente no modelo dbt:

-- fct_revenue_finance.sql -- reconhecida conforme política GAAP v3
-- fct_revenue_sales_booked.sql -- ACV reservado na data de fechamento do negócio

Exponha ambos na sua camada de BI. Deixe a parte interessada escolher o que corresponde à pergunta dela. Quando o CEO perguntar "como está a receita?", você pergunta de volta: "reservada ou reconhecida?" Ele vai pausar. Vai pensar. Vai dar a resposta certa, e a partir desse momento você é a pessoa em quem ele confia porque o fez sentir competente em vez de confuso.

Esse diagnóstico também revela qual organização é mais descuidada com as definições, o que é inteligência que você usará pelos próximos dois anos.

Painel vs. Ad Hoc: Quando Construir, Quando Tirar um Print

Nem toda pergunta merece um painel. O padrão na maioria das organizações de BA é "a resposta para uma pergunta é um novo painel," e é assim que se chega a 200 ou mais painéis sem saber quais 30 são realmente usados.

A heurística é simples. Essa pergunta será feita novamente em 30 dias?

• Sim: painel. Vale o compromisso de manutenção.
• Não: query SQL, print, poste no Slack, pronto. Não polua a biblioteca de painéis com um ad hoc para preparação de conselho.

Cada painel que você constrói é um compromisso de manutenção de 6 meses. As tabelas de origem mudam. As definições derivam. As partes interessadas mudam de equipe. Você será chamado para corrigir. Recuse adequadamente.

O roteiro para recusar o painel:

"Fico feliz em puxar isso como um ad hoc. Vou enviar o gráfico no Slack até o fim do dia. Se isso virar uma pergunta recorrente (você perguntar de novo no mês que vem), vamos revisitar e construo corretamente com documentação. Agora, construir um painel para uma pergunta única adicionaria overhead de manutenção que não compensa."

Envie isso para uma parte interessada uma vez e ela vai respeitá-lo mais, não menos. Construir tudo é um sinal de que você não valoriza o seu próprio tempo, o que significa que ela também não vai valorizar.

Controle de Versão e Disciplina de Change Log

Todo SQL vive no git. Sim, o seu LookML do Looker. Sim, o seu notebook do Hex (ou copie o SQL para um repositório). Sim, os seus modelos dbt, obviamente. Se um número num painel pode mudar, a mudança precisa ser rastreável.

Duas regras que capturam a maioria dos desastres:

1. Revisão por duas pessoas em mudanças de métrica. Qualquer PR que toque um modelo fct_* ou dim_* é revisado por outro analista antes do merge. Não um gestor. Um par que vai realmente ler o SQL. Isso captura a deriva silenciosa de definições que destrói a confiança.

2. Card de change log fixado em todo painel. No topo do painel, sempre visível:

Change Log: Rastreador de ARR
2026-04-15: Trocada a fonte de receita do Stripe para o NetSuite.
            Os números podem diferir de prints anteriores em ~2%.
            Responsável: camellia. PR: #1842.
2026-02-03: Adicionada segmentação por tier enterprise.
2025-11-20: Build inicial.

Quando uma parte interessada tira um print do painel em março e pergunta por que está diferente em maio, o change log responde à pergunta sem você precisar intervir.

A Revisão de Descontinuação a Cada 6 Meses

A maioria das organizações de BA tem 200 ou mais painéis e usa 30. Os outros 170 são peso morto: confundem novos contratados, fazem executivos duvidarem dos ativos ativos, consomem créditos de query no warehouse. A limpeza é o trabalho.

Configure um lembrete no calendário a cada 6 meses. Execute uma query no log de auditoria da sua ferramenta BI:

-- Exemplo para Looker
SELECT dashboard.title,
       dashboard.id,
       MAX(history.created_at) AS last_opened,
       COUNT(DISTINCT history.user_id) AS unique_viewers_180d
FROM history
JOIN dashboard ON history.dashboard_id = dashboard.id
WHERE history.created_at > CURRENT_DATE - INTERVAL '180 days'
GROUP BY 1, 2
ORDER BY last_opened ASC;

O output ordena seus painéis do mais obsoleto ao menos obsoleto. Aplique a regra:

• Não aberto em 90 dias: arquive. Sem discussão.
• Aberto por 1 a 2 pessoas: envie uma DM. "Ainda precisa disso? Se sim, mantenho. Se não, arquivo na sexta." A maioria vai dizer para arquivar.
• Aberto regularmente por 5 ou mais pessoas: mantenha, e certifique-se de que está na sua lista de manutenção.

Poste a lista de descontinuação em um canal público do Slack antes de arquivar. Dá às partes interessadas 48 horas para objetar. Quase nunca o fazem.

Uma equipe de BA que faz isso duas vezes por ano passa de 200 painéis para 40, e os 40 que restam são os que os executivos realmente consultam. A melhoria da relação sinal-ruído é enorme, e você passa a ser conhecido como a equipe que entrega menos, o que parece contraintuitivo até você ver o indicador de confiança se mover.

Conclusão: Confiança É um Output de Qualidade Técnica

Confiança não é uma característica de personalidade. Não se trata de ser charmoso em reuniões com partes interessadas, ou sempre dizer sim, ou ser o BA prestativo. Essas coisas ajudam, mas se desgastam. O que dura é a qualidade técnica.

O BA que consegue responder "de onde vem isso, quem mais usa, quando mudou pela última vez" em 10 segundos é o BA que executivos mantêm nos projetos estratégicos. O que não consegue é silenciosamente rebaixado a "macaco de query ad hoc" e nunca se recupera, não importa o quão simpático seja.

Construa para uma decisão. Mantenha a linha de cor. Centralize suas métricas. Teste-as. Comente o porquê. Pergunte as duas definições de receita. Recuse os painéis que não valem seu custo. Fixe o change log. Archive por cadência.

Esse é o trabalho completo. Execute esses movimentos de forma consistente por dois anos e você não vai precisar pedir uma cadeira na mesa de estratégia. Eles vão reservar para você.

Saiba Mais

• Gestão das Partes Interessadas para BAs
• Levantamento de Requisitos Sem o Teatro
• A Trilha de Carreira do BA: IC a Principal
• Job Description de Referência: Analista de Negócios