Um Dia na Vida de um Analista de Negócios (B2B SaaS, Trilha IC)

Antes de abrir o notebook, já tenho 11 mensagens no Slack perguntando por que o MRR caiu. Nenhuma delas está errada. Nenhuma delas tem a mesma resposta.

Um PM está olhando para o painel executivo, que puxa de um modelo dbt que rodou às 5h. Um CSM está olhando para um relatório no Salesforce que define MRR como valor de contrato comprometido. O VP de Finanças está olhando para a visão de reconhecimento de receita, que exclui tudo que ainda não foi faturado. Todos estão corretos, e todos estão olhando para números diferentes, e até as 9h30 alguém vai me perguntar qual é o "MRR real." Essa resposta leva 20 minutos para dar e mais 20 para defender. Bem-vindo à terça-feira.

O que a descrição de cargo prometeu versus como a terça-feira realmente parece

A descrição de cargo dizia "gere insights de negócios" e "parceria com a liderança em decisões estratégicas." Aceitei. A realidade é que minha semana é aproximadamente 60% SQL e encanamento de dados, 30% tradução entre Engenharia e Produto (e Vendas, e Finanças, e aquela diretora de CS que só se comunica por mensagens de voz), e 10% análise real. O insight só acontece quando o encanamento roda limpo. Um BA que não consegue manter os painéis no verde nunca é convidado para a mesa de estratégia. Está ocupado demais no porão consertando os canos.

Aqui está o passo a passo de um dia normal. Stack: Snowflake para o warehouse, dbt para transformações, Looker para BI (com alguns notebooks no Hex para ad hoc), Notion para especificações, Jira para tickets.

8h00: Verificação de saúde dos painéis

Antes de responder uma única mensagem no Slack, faço a mesma revisão de cinco minutos toda manhã:

O job do dbt terminou? Verifico o painel do dbt Cloud. Tudo verde, ou o fct_revenue falhou às 4h47 porque alguém entregou uma mudança de schema?
Timestamps de freshness no painel executivo. Abro o painel executivo do Looker. O tile "última atualização" deveria dizer "hoje, por volta das 6h." Se diz "ontem", algo upstream está desatualizado.
Contagens de linhas versus ontem. Três queries contra o warehouse (pedidos, oportunidades, contas ativas). Se as contagens caíram mais de 5%, uma sincronização do Fivetran upstream está quebrada.
Os três KPIs principais. Contagem de novos contratos, MRR e retenção bruta. Estão dentro de faixas saudáveis, ou um deles mostra uma variação semana a semana de 40% que grita "a definição quebrou"?
A verificação "alguém mexeu na camada semântica ontem à noite." Verifico o repositório LookML por merges nas últimas 12 horas.

Aqui está uma query de verificação de sanidade que mantenho fixada no Snowflake. Roda em menos de cinco segundos:

select
  date_trunc('day', created_at) as day,
  count(*) as orders,
  sum(amount) as gmv
from analytics.fct_orders
where created_at >= dateadd('day', -7, current_date)
group by 1
order by 1 desc;

Se a linha de hoje está faltando ou o GMV oscila muito, eu sei antes do CEO. Esse é o ponto inteiro. Detectar um join quebrado às 8h05 é uma correção de três minutos. Detectar às 9h35 depois que o all-hands já começou é uma crise de 90 minutos mais um e-mail de desculpas.

9h00: Triagem de solicitações ad hoc

A fila está em três lugares, porque claro que está. Painel de intake no Jira para solicitações formais. O canal #data-help no Slack para "perguntas rápidas." Uma página compartilhada no Notion onde uma das diretoras continua adicionando solicitações porque ela se recusa a usar o Jira. Verifico os três.

Nesta manhã: cinco novas solicitações. Meu trabalho não é respondê-las. Meu trabalho é fazer triagem.

"Você pode puxar o churn por nível de plano do último trimestre?" Bloqueante. O CFO precisa para o deck do conselho na quinta. Se a camada semântica está limpa, é uma query de 15 minutos. Se fct_subscription_events ainda tem o problema antigo do join com plan_id, são duas horas. Estimativa: 30 minutos. Aceito.
"Curioso, quantos dos nossos usuários de teste vêm do LinkedIn?" Curiosidade, não bloqueante. O painel de marketing já tem a divisão por fonte de aquisição. Respondo com um screenshot e um link. Dois minutos.
"Preciso saber nossa taxa de conversão no T1 por setor." Já existe no painel de desempenho de vendas do Looker. Envio o link e uma frase sobre qual filtro aplicar. Três minutos.
"Você consegue construir um painel para nosso novo experimento de precificação?" Trabalho real. Precisa de uma conversa de escopo de 30 minutos, não de uma query SQL. Resposta: "Entendido, vamos passar 20 minutos na quinta para escopar a decisão que este painel precisa suportar."
"Esse número no painel de CS parece estranho, você pode verificar?" Pode ser nada, pode ser tudo. Abro. O número está bem. A legenda está errada porque alguém renomeou uma medida. Correção de 10 minutos no LookML.

A regra de triagem que salvou minha sanidade: separe "bloqueante" de "curioso." Bloqueante significa que uma decisão não pode avançar sem uma resposta. Curioso significa que alguém está num explore do Looker e foi fisgado pela análise. Curioso vai para o autoatendimento. Bloqueante vai para o topo da fila. Se tudo é "bloqueante", nada é.

A equipe de dados em que estou tem três pessoas. Entre nós, recebemos de 8 a 12 novas solicitações ad hoc por semana. Sem triagem, a fila engole o trabalho inteiro.

11h00: Entrevista de requisitos durante o almoço

Um PM reserva 45 minutos no meu calendário. A pauta diz: "Escopo do painel de engajamento." Já estive aqui antes. O PM quer "um painel de engajamento." Isso não é uma solicitação. É um sentimento.

Meu trabalho nessa reunião é chegar à decisão real que o painel vai suportar e trabalhar de trás para frente até duas ou três métricas que não sejam de vaidade. Aqui está o roteiro de perguntas que uso, e literalmente o tenho aberto num doc do Notion quando a reunião começa:

Que decisão você vai tomar de forma diferente depois de olhar para este painel? (Se não consegue responder, o painel é uma solicitação de vaidade. Pare aqui.)
Quem mais precisa ver isso, e que decisão essa pessoa toma?
Com que frequência você vai olhar para ele (diário, semanal, mensal)? (Diário significa que você precisa de um alerta no Slack, não de um painel.)
Que número, se mudasse, faria você agir esta semana?
Qual é o limite? O que conta como 'bom' versus 'ruim'?
O que já existe que é quase isso, mas não exatamente? (Frequentemente há um explore do Looker existente que atende 80% da necessidade.)
Se só pudermos entregar dois gráficos, quais dois importam mais?

O PM de hoje disse "painel de engajamento." Após 30 minutos dessas perguntas, o que ele realmente precisa é de um gráfico (usuários ativos semanais por coorte de funcionalidade) mais um alerta no Slack quando WAU cair mais de 10% semana a semana. Esforço de construção: meio dia. Solicitação original, tomada ao pé da letra: provavelmente duas semanas para algo que ninguém abriria depois do primeiro sprint.

O PM que pede "um painel" geralmente precisa de um gráfico e um alerta no Slack. Aproximadamente 70% das vezes, na minha experiência.

13h30: Async com engenharia e produto

O almoço foi um sanduíche na mesa enquanto revisava um PR do dbt. Essa é a parte de tradução do trabalho, e é a parte que ninguém te conta em entrevistas.

Comentário no PR do dbt. Um analytics engineer está refatorando dim_accounts e renomeando uma coluna de account_owner_id para owner_user_id. A descrição do PR não menciona os quatro explores do Looker que referenciam o nome antigo. Deixo um comentário com links para cada explore afetado e uma nota de que precisamos de (a) um alias de coluna para compatibilidade retroativa ou (b) um PR coordenado do LookML entregue ao mesmo tempo. Esse comentário de 10 minutos previne três mensagens no Slack às 9h de amanhã perguntando por que o painel de vendas está quebrado.

Resposta a uma especificação de produto. Um PM escreveu uma especificação para um novo fluxo de onboarding no app e me marcou perguntando se eu consigo "rastrear o engajamento com cada etapa." Olhando o rastreamento de eventos, os eventos que eles querem não existem. A instrumentação de produto atual dispara onboarding_started e onboarding_completed, ponto final. Para responder a pergunta que eles realmente se importam (onde os usuários abandonam o fluxo), precisamos de eventos por etapa: onboarding_step_viewed com uma propriedade step_name. Escrevo isso na especificação com o schema exato do evento, aponto para o plano de rastreamento existente no Notion e adiciono um ticket no backlog de Engenharia para adicionar os eventos.

Esse é o trabalho que não aparece em nenhum painel mas separa um BA que é recontratado de um que não é. Engenharia fala tabelas e schemas. Produto fala funcionalidades e resultados. Partes interessadas falam em sentimentos e mensagens no Slack. O BA faz a ponte entre os três. PRs do dbt revisados antes do almoço evitam interrupções no Looker depois do almoço. Esse é o trabalho.

15h00: Pull de dados executivos no final do dia

O VP de Vendas me pinga às 14h55. A ligação de preparação do conselho é às 16h. Ele precisa do pipeline do trimestre até agora por segmento, dividido por estágio e ponderado pela probabilidade de estágio. O slide está sendo construído agora.

O SQL está bem. Tenho uma query salva para exatamente esse corte. Parece aproximadamente assim:

select
  segment,
  stage,
  count(*) as opps,
  sum(amount) as pipeline_amount,
  sum(amount * stage_probability) as weighted_pipeline
from analytics.fct_opportunities
where close_quarter = 'Q2-2026'
  and is_active = true
group by 1, 2
order by 1, 2;

A parte difícil não é a query. É o aviso. O VP quer um número no slide. Preciso decidir qual e dizer o motivo. Três opções, todas defensáveis:

Pipeline bruto (soma simples): número maior, parece ótimo, inclui negócios com 10% de chance de fechar.
Pipeline ponderado (soma x probabilidade de estágio): mais honesto, menor, o que a maioria dos CFOs prefere.
Pipeline comprometido (apenas estágios 4 e acima): mais conservador, o que reportamos no QBR.

Envio os dados com uma nota de um parágrafo: "O slide deve usar pipeline ponderado. É o que o CFO apresentou no último trimestre, e usar uma definição diferente neste trimestre vai disparar uma pergunta sobre 'por que a metodologia mudou'. Se o VP quiser o número bruto para narrativa, liste-o como rodapé."

Os dados levam quatro minutos. A recomendação leva 12. A recomendação é a parte que me garante o convite de volta no próximo trimestre.

16h30: O pânico "este relatório está errado"

Na hora certa. Uma Diretora de Customer Success me manda mensagem: "Ei, o número de novos contratos no painel de CS diz 47 para abril, mas o Salesforce diz 52. Você pode verificar?"

Essa é a emergência mais comum no trabalho, e quase sempre tem a mesma causa raiz. Aqui está o debug de 20 minutos que rodo, em ordem:

Verificação de definição. O que o painel chama de "novo contrato"? No Looker, é filtrado por is_first_paid_invoice = true. No Salesforce, o relatório é filtrado por opportunity_stage = 'Closed Won' E account_type = 'New Logo'. Essas são definições diferentes. Uma oportunidade pode ser Closed Won mas ainda não ter uma fatura paga (atraso de faturamento de 5 dias). Isso por si só geralmente explica uma diferença de 5 negócios.
Verificação de fuso horário. O Salesforce reporta no horário local do usuário. O painel do Looker está em UTC. 30 de abril no horário de Brasília é 1º de maio em UTC. Um ou dois negócios sempre ficam presos nisso.
Verificação de filtro. O relatório do Salesforce está incluindo renovações ou upgrades? Às vezes o filtro de "novo contrato" está mal configurado.
Verificação de freshness dos dados. Quando a sincronização Salesforce para Snowflake rodou pela última vez? Se rodou há 10 minutos, ótimo. Se rodou há seis horas, dois negócios adicionais podem ter fechado desde então.
Bug real nos dados. Somente depois de descartar os quatro primeiros verifico se há um problema upstream.

A resposta de hoje: divergência de definição. O Looker usa fatura paga; o Salesforce usa closed-won. Ambos estão "corretos", eles apenas respondem perguntas diferentes. O número do Looker é o certo para os propósitos da equipe de CS (devemos celebrar clientes pagantes, não fechamentos no papel), mas documento a diferença na descrição do painel para que isso não aconteça novamente no próximo mês.

A comunicação importa tanto quanto o diagnóstico. Nunca respondo com "o relatório do Salesforce está errado." Respondo com: "Ambos estão corretos, mas estão medindo coisas diferentes. Aqui está o que cada um significa, aqui está por que diferem neste mês e aqui está qual usar para o QBR de CS." Ninguém fica na defensiva. Ninguém escalona. A diretora me agradece e segue em frente.

"Este relatório está errado" é quase sempre um desacordo de definição, não um bug nos dados. Talvez 80% das vezes. Os outros 20% são bugs reais, e esses recebem um ticket no Jira e um post-mortem.

17h30: Encerramento

Cinco solicitações ad hoc chegaram esta manhã. Fechei três. Duas foram postergadas para amanhã com uma resposta no Slack explicando o motivo, para que ninguém fique se perguntando. Uma adicionei ao backlog de engenharia de analytics como solicitação recorrente. O pull de "churn por nível de plano" chega aproximadamente duas vezes por trimestre, e está na hora de transformá-lo em um painel de autoatendimento para que pare de pousar na minha fila. Esse é o movimento de maior alavancagem do dia, e levou dois minutos.

Última coisa que faço antes de fechar o notebook: uma nota de uma linha no meu diário diário do Notion. O que entreguei, o que aprendi, o que foi postergado. Amanhã de manhã, quando as 11 mensagens do Slack começarem novamente, esse registro é como lembro quais incêndios já estavam queimando.

O scorecard honesto

No final de um bom dia, o BA entregou uma análise real (o escopo do painel de engajamento que transformou uma construção de duas semanas em meio dia mais alerta), desbloqueou três partes interessadas (o pull de churn do CFO, o corte de pipeline do VP de Vendas, a questão do novo contrato da diretora de CS) e evitou um incidente de número errado (o comentário no PR do dbt que salvou a interrupção do Looker amanhã).

Esse é o trabalho. Não "gere insights." Não "seja um parceiro estratégico." Apareça, mantenha os painéis no verde, faça a tradução entre as pessoas que não conseguem se comunicar e responda a pergunta por trás da pergunta.

Os 10% que são análise estratégica real só acontecem quando os 90% rodam limpos. Os BAs que são promovidos são os que descobriram isso até o terceiro mês.

Playbooks para Analistas de Negócios