Seus Primeiros 30/60/90 Dias como Novo Data Analyst

São 9h47 do terceiro dia. Você mal descobriu como funciona a VPN. Uma mensagem no Slack chega de alguém cujo nome você não reconhece: "ei, bem-vindo! pergunta rápida: você consegue puxar o MRR por segmento para o board deck de amanhã? preciso fatiado por faixa de ARR e canal de aquisição. valeu!"

Como você responde a essa mensagem decide os próximos 12 meses.

Se você disser sim e rodar a consulta, acabou de assinar o contrato. Você é agora a Pessoa dos Pulls Pontuais. Vai passar 40 horas por semana em "puxadas rápidas" e não vai entregar nenhum trabalho estratégico. No dia 91, quando seu gestor perguntar o que você realizou, você vai ter um arquivo do Slack em vez de uma história.

Se você disser não, você é o novo analista que bloqueou o board deck. Também ruim.

Existe um terceiro caminho. Este guia é esse caminho.

Por que analistas precisam de um plano de 30/60/90 mais do que qualquer outra pessoa

Engenheiros ganham um backlog. PMs ganham um roadmap. Designers ganham um arquivo Figma já em andamento. Analistas entram numa empresa onde cada stakeholder acha que é a prioridade, o analista anterior não deixou documentação e a TV da empresa está exibindo painéis de controle que não são atualizados há oito meses. Metade está errada. Ninguém sabe qual metade.

Sem um plano, você vira uma máquina de SQL. Com um, você se torna alguém que eliminou 30 painéis de controle quebrados, entregou um modelo de receita canônico e entrou na reunião de planejamento do segundo semestre com um roadmap de analytics que seu VP não havia pedido, mas de repente precisava.

O plano é simples: audite, depois entregue uma coisa, depois seja dono de uma métrica. Três meses. Um trabalho por mês. Não pule etapas.

Dias 1 a 30: Audite, não construa

O maior erro que vejo novos analistas cometerem é abrir um editor SQL no quarto dia e tentar "consertar" algo. Você ainda não sabe o que está quebrado. Não sabe o que é estrutural. Não sabe qual painel de controle "quebrado" é na verdade o único em que o CFO confia.

O primeiro mês é reconhecimento. Você escreve quase nenhuma consulta. Você anota muita coisa.

Semana 1: Inventário de painéis de controle

Extraia uma lista de todos os painéis de controle, relatórios e consultas salvas na sua ferramenta de BI (Looker, Mode, Tableau, Metabase, o que você herdou). Para cada um, capture cinco campos:

• Nome
• Responsável (ou "desconhecido")
• Contagem de visualizações (últimos 60 dias)
• Data da última edição
• Status (ativo / suspeito / morto)

Morto significa: zero visualizações em 60 dias OU última edição feita por alguém que saiu da empresa há mais de seis meses. Em uma empresa SaaS de médio porte típica, você vai descobrir que 60% a 70% dos painéis de controle estão mortos. Na minha última empresa tínhamos 312. Após a auditoria, 47 eram realmente usados. O resto eram navios fantasma.

Não apague nada ainda. Apenas liste.

Semana 2: Tour pelo esquema e a briga pela receita canônica

Agora você lê. Abra o repositório dbt (ou seu data warehouse se não houver dbt). Encontre as cinco tabelas que você vai usar toda semana (geralmente alguma variação de accounts, subscriptions, events, users e uma tabela de receita). Leia as definições dos modelos. Leia os comentários de coluna. Leia as macros.

Com certeza estatística, você vai descobrir que sua empresa tem múltiplas definições de receita. Em uma empresa onde trabalhei, tínhamos 14 versões de receita no data warehouse. ARR contratado. ARR faturado. ARR previsto. ARR líquido novo. ARR retido bruto. Cada uma estava correta para algum propósito e errada para outro. Finanças usava uma. Vendas usava outra. O CEO tinha uma planilha do Google com uma terceira.

Isso é normal. É também a tarefa mais importante da segunda semana. Marque uma reunião com seu contraparte em finanças. Pergunte: "Qual dessas é a fonte da verdade para o board?" Obtenha a resposta por escrito. Não uma mensagem no Slack, um documento. Essa conversa é a fundação sobre a qual tudo o mais se apoia.

Se finanças não souber responder, isso é um achado. Anote.

Semana 3: Alinhamentos com stakeholders (ouça, não apresente)

Participe de cinco reuniões: revenue ops, customer success, marketing, produto, finanças. Você não está lá para apresentar. Não está lá para "se apresentar". Você está lá para ouvir as perguntas recorrentes.

O padrão que você procura: a mesma pergunta feita por três equipes diferentes de três formas diferentes. Esse é o painel de controle da quinta semana.

Exemplos do que já ouvi em alinhamentos da terceira semana:

• Líder de RevOps: "A gente nunca sabe em qual segmento o nosso Pipeline está realmente concentrado."
• Diretor de CS: "Eu queria ver o ARR de expansão por setor sem precisar exportar para uma planilha."
• CMO: "O Pipeline originado pelo marketing por segmento está em cinco lugares diferentes."

É a mesma pergunta três vezes. Esse é o painel de controle que você constrói no segundo mês.

Leve um caderno. Não abra o notebook. Não se ofereça para "puxar algo rápido". Quando perguntado, diga: "Estou em modo de auditoria pelas próximas duas semanas. Vamos registrar no formulário de entrada assim que ele estiver no ar." (Mais sobre o formulário de entrada em breve.)

Semana 4: A lista de eliminação

Agora você propõe descontinuar os painéis de controle mortos. É aqui que novos analistas ficam com medo e pulam essa etapa. Não faça isso.

Volte ao seu inventário. Para cada painel de controle morto, encontre o criador original (ou a equipe responsável) e pergunte: "Esse painel não foi visualizado há X dias. Você topa eu arquivá-lo?" 80% das vezes a resposta é "pelo amor, eu havia esquecido que ele existia." 15% das vezes a resposta é "na verdade, guarda, eu uso uma vez por mês." 5% das vezes você vai aprender algo importante sobre o negócio.

Obtenha confirmação por escrito. Uma thread no Slack está ótimo. Depois arquive, não apague. A maioria das ferramentas de BI permite arquivar com restauração em um clique. Você quer um histórico documentado.

O roteiro que funcionou para mim:

Ei [nome], estou fazendo uma limpeza de painéis de controle como parte do onboarding. O "[nome do painel]" não teve nenhuma visualização em 73 dias e foi editado pela última vez por [pessoa que saiu]. Gostaria de arquivá-lo (reversível, não vou apagar). Pode ser? Se preferir manter, sem problema, só quero confirmar que alguém é responsável por ele.

Mande em lotes de 10. Não cobre resposta. Silêncio após 5 dias úteis = arquivar. Documente tudo.

Ao final da quarta semana, você terá geralmente eliminado entre 40 e 150 painéis de controle. Esse é o seu primeiro entregável. É também o único entregável que você vai reivindicar sem ter escrito uma linha de SQL, o que é exatamente o ponto.

Dias 31 a 60: Entregue uma coisa, defina o SLA

O segundo mês é onde o trabalho aparece. Mas você só pode fazer três coisas. Entregue um painel de controle. Publique um SLA. Construa um modelo dbt. Só isso. Resista à tentação de fazer mais.

Entregue o painel de controle que todo mundo pediu

Lembra da pergunta da terceira semana que três equipes fizeram? Construa aquele painel de controle. Apenas aquele.

A disciplina aqui é brutal. As pessoas vão pedir "já que você está nisso, você consegue adicionar também..." e a resposta é não. Não porque o pedido é ruim, mas porque cada "já que você está nisso" se torna a armadilha da Pessoa dos Pulls Pontuais com passos extras. Entregue uma coisa. Faça bem feito. Entregue.

Um "bom" primeiro painel de controle significa:

• Uma pergunta, respondida claramente. Não cinco perguntas.
• A definição da métrica é a canônica pela qual você brigou na segunda semana, e o rodapé do painel diz isso. ("Receita definida conforme [link para o modelo dbt]. Última revisão com Finanças em [data].")
• Três filtros no máximo. Segmento, período e um corte específico por equipe.
• Um parágrafo de "como ler este painel" no topo.
• Um responsável (você) e um canal no Slack para dúvidas.

Esse último item não é negociável. Todo painel de controle sem responsável vira um navio fantasma em 18 meses. Você vai ser o analista que quebra esse padrão.

Publique o SLA de solicitações pontuais

Esse é o momento em que você para de ser uma máquina de SQL. Você publica uma página única (um documento Notion, uma página Confluence, o que sua empresa usa) que diz:

Intake de solicitações pontuais de dados

1. Envie via [formulário / canal #data-requests]. Mensagens diretas para mim serão redirecionadas para cá.
2. Três campos obrigatórios: o que você precisa, quando precisa, que decisão isso vai embasar.
3. SLA: solicitações de até 4 horas de trabalho, mesmo dia ou manhã seguinte. Solicitações acima de 4 horas, triadas para o próximo Sprint.
4. Qualquer coisa marcada como "board deck" ou "revisão executiva" sobe para o topo da fila.

Três campos obrigatórios. Não sete. Não um formulário de 14 perguntas. O terceiro campo (que decisão isso vai embasar) é o que faz a mágica. Metade dos pedidos morre nele porque quem solicitou percebe que na verdade não precisa dos dados, estava só curioso. A outra metade chega mais direcionada porque quem pediu teve que pensar primeiro.

Peça para seu gestor enviar o anúncio, não você. "Oi pessoal, [seu nome] está gerenciando o intake de analytics agora. Por favor, usem o formulário a partir de agora." Essa frase vale cem mensagens diretas que você não precisa absorver.

O SLA não é sobre dizer não. É sobre tornar "próximo Sprint" uma resposta normal em vez de uma briga.

Construa um modelo dbt

O modelo dbt é a definição de receita canônica pela qual você brigou na segunda semana. Apenas aquela. Não uma camada de métricas. Não uma refatoração semântica. Um modelo.

Nomeie-o fct_revenue_canonical ou conforme a convenção do seu repositório. Escreva o bloco de documentação. Adicione testes. Faça a revisão. Faça o merge. Atualize o painel de controle da quinta semana para usar como fonte.

Esse é o seu momento de "eu pertenço aqui". A primeira vez que alguém em uma reunião disser "espera, qual número de receita estamos usando?" e um colega responder "o canônico, é o modelo dbt que [seu nome] entregou", esse é o momento em que você para de ser o novo analista e se torna o analista.

Não tente, em hipótese alguma, refatorar o resto do data warehouse no segundo mês. O cemitério de novos analistas está pavimentado com pessoas que tentaram "reconstruir tudo" na sexta semana e quebraram um relatório do board na oitava. Entregue um modelo. Siga em frente.

Dias 61 a 90: Seja dono de uma métrica, apresente o plano

O terceiro mês é quando você para de ser medido por tickets fechados e começa a ser medido pelo que você possui.

Adote o tempo até o insight como sua métrica

Escolha uma métrica de equipe e seja responsável por ela. A mais relevante para analistas é o tempo até o insight: mediana de horas entre "solicitação enviada" e "resposta de dados entregue". Algumas equipes chamam de tempo de primeira resposta para perguntas de dados. É a mesma ideia.

Meça a partir do seu formulário de entrada (você já tem um). Estabeleça uma baseline na nona semana. Defina uma meta para a décima segunda semana. A minha era: mediana de 6 horas, meta abaixo de 4.

Por que essa métrica e não "taxa de adoção de painéis" ou "consultas executadas"? Porque o tempo até o insight é o que seus stakeholders sentem. Eles não percebem quando a taxa de adoção sobe. Eles percebem quando a pergunta deles é respondida antes do almoço em vez de na terça que vem.

Reporte semanalmente no standup da equipe. Três números: mediana, p90, contagem. Só isso.

O relatório de 90 dias

Por volta do dia 85, escreva para seu gestor um relatório de uma página. Quatro seções, nessa ordem:

Eliminados. Número de painéis de controle arquivados, com a lista. Total estimado de carga poupada no data warehouse, se você conseguir medir.

Entregues. O painel de controle. O modelo dbt. O formulário de entrada com dois meses de dados de throughput.

Quebrados. O que você encontrou que ainda está errado. Seja específico. "O modelo de MRR por segmento faz dupla contagem de conversões de trial na região EMEA. Afeta 4 painéis de controle. A correção é um projeto de 1 semana." Não amenize. Seu gestor quer a lista.

Próximos passos. Dois projetos estratégicos, um investimento em plataforma, uma solicitação de contratação se relevante. Concreto. Com cronogramas aproximados.

Uma página. Não mais. Envie como documento e percorra no seu 1:1.

A apresentação do plano para o segundo semestre

O relatório de 90 dias é o aquecimento. A apresentação é o que vem a seguir. No mesmo 1:1, você diz: "Quero ser responsável pelo plano de analytics do segundo semestre. Aqui está o esboço: dois projetos estratégicos (X e Y), um investimento em plataforma (uma camada de métricas / reverse ETL / framework de experimentação) e uma decisão de contratação (contratamos um segundo IC ou um sênior para liderar?). Vou ter um documento completo até [data]."

Esse é o momento que distingue o analista que permanece IC por cinco anos do que está liderando uma equipe em 18 meses. A maioria dos analistas espera que o gestor planeje por eles. Você vai planejar para o seu gestor.

Você vai receber resistência. O plano vai ser editado. Dois dos seus projetos vão ser cancelados. Tudo bem. A apresentação é o ato, não o artefato.

As armadilhas (vão te tentar, não caia nelas)

Dizer sim para toda solicitação pontual no primeiro mês. Já disse no início, vou repetir. A esteira de solicitações pontuais é uma via de mão única. Você diz sim na primeira semana e ainda está dizendo no segundo ano.

Reconstruir o data warehouse na segunda semana. Você ainda não entende o negócio. O modelo "obviamente quebrado" é estrutural para alguém que você ainda não conheceu. Audite primeiro.

Ficar em silêncio por 60 dias e depois soltar uma auditoria de 40 páginas. Ninguém pediu a auditoria. Pediram evidência de que você existe. Entregue a lista de eliminação na quarta semana. Publique o SLA na sexta semana. Apareça.

Entregar um painel de controle com a definição de receita errada. Você pulou a reconciliação com finanças na segunda semana. Agora seu painel contradiz o board deck. Confiança perdida. Difícil de recuperar. Não faça isso.

Modelos que você vai realmente usar

Planilha de inventário de painéis de controle. Seis colunas: nome, responsável, última visualização (data), última edição (data), status (ativo/suspeito/morto), decisão de eliminar ou manter. Uma linha por painel. Ordene por última visualização de forma crescente e os mortos flutuam para o topo.

Lista de perguntas para alinhamentos com stakeholders. Cinco perguntas, em ordem: (1) Que decisões você tomou no último trimestre e desejou ter melhores dados para isso? (2) Que número você verifica toda manhã? (3) Qual painel de controle você realmente usa, versus qual existe para você? (4) Que pergunta você fica recebendo do seu gestor e não consegue responder rápido? (5) Se eu pudesse te dar uma nova visão sobre o negócio, qual seria? Nenhuma delas é "do que você precisa de mim". Essa pergunta gera uma lista de desejos. Essas perguntas geram a verdade.

Formulário de entrada de solicitações pontuais. Três campos. Solicitação. Prazo. Decisão que vai embasar. Só isso.

Relatório de 90 dias. Uma página. Eliminados. Entregues. Quebrados. Próximos passos. Tópicos, não parágrafos.

Como é o "sucesso" no dia 90

No dia 90, a contagem de painéis de controle na sua ferramenta de BI está caindo, não subindo. Existe um modelo dbt canônico para a métrica sobre a qual sua empresa costumava brigar. Os stakeholders usam o formulário de entrada em vez de te mandar mensagem direta. Seu gestor tem um plano escrito para o segundo semestre vindo de você, e não o contrário. E em algum lugar na TV da empresa, os painéis de controle ainda mostram o mesmo número numa terça que numa sexta.

Você não é a Pessoa dos Pulls Pontuais. Você é o analista.

Esse é o trabalho.

Saiba Mais

• Descrição de Vaga para Data Analyst (a vaga com a qual este Playbook se conecta)
• Um Dia na Vida de um Data Analyst
• SQL e Modelagem de Dados que Escalam
• Tradução para Stakeholders: De Pedidos Vagos a Análises Entregáveis
• Métricas para Data Analysts: Tempo até o Insight, Adoção, Impacto
• Armadilhas Comuns do Data Analyst