Erros Comuns do Data Analyst: 7 Armadilhas que Travam sua Carreira (e Como Corrigi-las)

O seu Slack está ocupado. O seu Looker tem 47 painéis de controle com o seu nome neles. O seu gestor te chama de "sólido" nas reuniões individuais. E de alguma forma, quando o VP de Vendas decide reestruturar os territórios no próximo trimestre, ninguém te convida para a reunião em que a decisão é tomada.

Bem-vindo ao paradoxo do analista no 14º mês. Você é competente o suficiente para estar afogado em trabalho e não é sênior o suficiente para recusar qualquer parte dele. O trabalho que preencheu o seu calendário te trouxe até o IC2. Nenhum dele vai te levar ao Sênior.

Já revisei ciclos de avaliação de desempenho de analistas em empresas de 80 a 8.000 pessoas. Os que estacionam quase sempre estacionam pelos mesmos motivos. Não é habilidade. SQL você aprende. dbt você aprende. Python você aprende em um fim de semana se realmente abrir o notebook. As armadilhas deste artigo são hábitos, e hábitos são mais difíceis de desaprender do que conceitos são de aprender.

Então aqui estão os sete que causam mais dano. Cada um vem com um sintoma que você vai reconhecer desta semana, um número real para se comparar e uma correção que você pode começar a executar na segunda-feira de manhã.

Por que a janela de 6 a 18 meses define a sua trajetória

Nas avaliações de desempenho de analistas que já vi, aproximadamente 73% das pessoas que estacionam no IC2 o fazem por causa de padrões formados entre os meses 6 e 18. Essa é a janela depois que o onboarding termina mas antes de você ter acumulado capital político suficiente para definir o próprio escopo. Você passa os primeiros seis meses provando que consegue entregar. Você passa os meses 6 a 18 decidindo que tipo de analista vai ser pelo resto da carreira.

A maioria das pessoas não decide. Elas derivam. A deriva parece dizer sim a cada notificação do Slack, construir painéis que ninguém abre e medir o sucesso em tickets fechados. Dois anos depois, o papel está calcificado. Até o mês 24, as pessoas da sua equipe que estabeleceram limites estão recebendo ofertas de Sênior. Você está recebendo "vamos revisitar no próximo ciclo".

Essas sete armadilhas são a deriva, com nome e sobrenome.

Armadilha 1: Virar o Help Desk

Sintoma: Mais de 60% da sua semana são solicitações pontuais de menos de 30 minutos cada. Você não tocou na análise mais aprofundada que escopo há seis semanas.

Você consegue identificar isso no seu próprio calendário em cinco minutos. Abra o Slack, busque as mensagens em que você enviou um resultado de consulta e conte quantas delas levaram menos de meia hora para resolver. Se esse número for superior a 25 em uma semana típica, você não é um Data Analyst. Você é um atendente de SQL.

A armadilha é que ser o help desk parece ser útil. Cada emoji de "obrigado!" é um pequeno estímulo de satisfação. Cada entrega rápida faz você parecer responsivo. E cada minuto que você passa nesses chamados é um minuto que você não está construindo o que vai te promover, que é julgamento.

Correção para executar esta semana:

Defina um SLA de triagem e publique no canal da sua equipe. O meu diz:

Solicitações pontuais: organizo em dois momentos por dia, 11h e 16h. Se algo estiver realmente bloqueando, me marque com urgente e o prazo. Para perguntas recorrentes, aqui está o painel de autoatendimento: [link]. Se a pergunta levar mais de 45 minutos, ela vira um ticket e passa pela priorização com o meu gestor.

Depois construa uma biblioteca de consultas de autoatendimento. As 10 perguntas que você mais responde, expostas como um painel ou um Explore salvo no Looker com documentação. Você vai reduzir o volume do help desk em 40 a 60% em duas semanas. O seu gestor vai notar. As suas partes interessadas vão reclamar por uma semana e depois parar.

O desconforto de dizer "isso passa pela priorização" é o preço de ser tratado como analista em vez de ferramenta de busca.

Armadilha 2: Pular a Aprovação de Requisitos

Sintoma: Você está na terceira rodada de revisão de um projeto e a parte interessada acabou de dizer "na verdade, o que eu quis dizer foi..." Você vai refazer o modelo e publicar novamente na sexta.

Isso custa mais do que você imagina. Uma equipe de analytics típica de médio porte que trabalhei auditou a taxa de retrabalho e descobriu que 31% das horas dos analistas eram gastas em projetos que já tinham sido "entregues" uma vez. Três de cada dez horas, refazendo trabalho porque a especificação era um histórico do Slack.

Você pulou a aprovação de requisitos porque pedi-la parecia lento. Pedir à parte interessada para escrever o que quer, colocar o nome e se comprometer com critérios de aceitação parecia burocracia. Então você pulou. E agora é quarta-feira e você está reconstruindo o funil pela terceira vez e o VP de Marketing está "frustrado com o tempo de resposta de analytics".

Correção para executar esta semana:

Briefing de uma página para todo projeto com mais de quatro horas de trabalho. Template:

Projeto: [nome]
Solicitante: [nome + cargo]
Decisão que esta análise impulsiona: [a decisão real]
Tomador de decisão: [quem age com base nisso]
Prazo da decisão: [data]
Critérios de aceitação: [lista de 3 a 5 entregas específicas que devem existir para que isso seja "concluído"]
Fora do escopo: [o que NÃO estamos fazendo]
Aprovação da parte interessada: [nome + data]

Envie por e-mail. Aguarde o "aprovado". Depois escreva o SQL. Se a parte interessada não aprovar, o projeto não é real e você não precisa começar.

Sim, isso desacelera as primeiras 24 horas de um projeto. Elimina as próximas 24 horas de retrabalho. A matemática não é sutil.

Armadilha 3: Construir Painéis Antes de Definir a Decisão

Sintoma: O seu último painel de controle tem 14 blocos, três filtros e um seletor de intervalo de datas. Quando perguntado qual ação ele dispara, a sala fica em silêncio.

Este é o mau hábito mais comum que vejo e o que os analistas mais defendem. O instinto é "mais é mais". Dê ao usuário todos os recortes, todos os detalhamentos, todas as dimensões e deixe-os fatiar. O resultado é um painel que ninguém consegue usar porque não há pergunta que ele responda.

Um benchmark interno de 2024 em uma empresa SaaS de 400 pessoas: de 287 painéis de controle na instância do Looker, 41 tinham mais de 10 visualizadores por semana. Os outros 246 eram cidades fantasma. Os 41 que funcionavam respondiam exatamente uma pergunta e disparavam uma ação. Os 246 que não funcionavam eram painéis de "visão geral", "resumo executivo" ou "saúde da equipe": substantivos vagos disfarçados de entregas.

Correção para executar esta semana:

Antes de qualquer novo painel de controle, responda por escrito a quatro perguntas:

1. Qual decisão isso impulsiona?
2. Quem toma essa decisão?
3. Em qual cadência (diária, semanal, trimestral)?
4. Qual ação é tomada quando a métrica cruza um limite?

Se você não consegue responder a todas as quatro, não está construindo um painel de controle. Está construindo papel de parede. Devolva o projeto ao solicitante até que ele consiga responder junto com você.

Painéis construídos dessa forma têm 3 a 7 blocos, um intervalo de datas e um indicativo claro de "se esse número cair abaixo de X, faça Y". Eles são usados porque respondem algo específico.

Armadilha 4: Depender Demais de Exportações para Excel

Sintoma: Todo "número final" que as suas partes interessadas citam vive em um CSV no desktop de alguém, modificado pela última vez há três semanas.

O botão de exportar é o inimigo da analytics confiável. Cada exportação é uma bifurcação nos seus dados. No momento em que um número sai do data warehouse e cai em Q3_pipeline_v4_FINAL_real.xlsx, você perdeu o controle dele. Seis semanas depois, o CFO vai citar esse arquivo em um deck para o board e ele vai estar errado, e o número errado vai ser atribuído a você.

Já vi equipes de finanças citarem 19% de cobertura de pipeline a partir de um CSV quando o número ao vivo no data warehouse era 14%. O CSV era de antes de um deal ser reclassificado como commit. O CFO apresentou 19% ao board. Dois meses depois, o board perguntou por que a empresa tinha perdido tanto. A resposta foi "a planilha estava desatualizada", o que não é uma resposta que sobrevive a uma reunião de board.

Correção para executar esta semana:

Construa uma camada semântica gerenciada. Modelos dbt, métricas definidas, expostas pelo Looker, Sigma, Hex ou a ferramenta do seu stack. Acesso somente leitura para as partes interessadas. Depois, no canal da equipe, faça este anúncio:

A partir de [data], a fonte da verdade para [pipeline, receita, retenção ou a métrica que importa] é o [link do painel]. CSVs com mais de 24 horas não serão reconciliados. Se você precisar de um número para um deck, coloque o link do painel.

Algumas partes interessadas vão resistir. Tudo bem. O CFO que resiste é o mesmo que vai te agradecer na primeira vez que o data warehouse capturar um número que a planilha teria perdido.

Acabe com o hábito de exportar. A reputação que você vai salvar é a sua.

Armadilha 5: Sem Controle de Versão no SQL ou no dbt

Sintoma: A sua consulta de atribuição em produção vive em um histórico do Slack de março. Ou pior, vive em um bloco do Looker e três pessoas o editaram sem que você soubesse.

Esse parece constrangedor demais para admitir, mas já auditei equipes de analytics em empresas na rodada Série C onde o cálculo de valor de vida do cliente era uma consulta de 400 linhas colada em uma tabela derivada do Looker sem comentários e sem histórico de quem mudou o quê quando. O analista que a escreveu saiu em 2024. Ninguém consegue alterar nada com confiança.

Você acha que controle de versão é para engenheiros. Não é. É para qualquer pessoa cujo trabalho outras pessoas dependem, o que é você. Um analista sem controle de versão está a um merge equivocado ou a uma exclusão acidental de distância de um incidente que dura o dia inteiro.

Correção para executar esta semana:

Mesmo que você seja um analista solo, configure:

1. Um repositório git para o seu SQL, chamado analytics-sql ou similar.
2. dbt para qualquer modelo usado por mais de uma pessoa ou um painel de controle.
3. Revisão de pull request. Se você for solo, faça a revisão de pull request de você mesmo na manhã seguinte. Releia o diff com olhos frescos antes de fazer o merge.
4. Verificações de CI (dbt test, mesmo que apenas três básicas: not null, unique e accepted values).

O primeiro mês parece lento. No segundo mês, você vai detectar um bug na revisão que teria derrubado o cálculo do bônus de um líder de vendas em 8%. A partir daí, você nunca vai voltar atrás.

O analista sênior na sua empresa tem tudo isso. O IC2 que nunca é promovido não tem nada disso. Essa é grande parte da diferença.

Armadilha 6: Ignorar as Revisões de Descontinuação

Sintoma: Você mantém mais de 200 painéis de controle. Não consegue me dizer quais 12 estão realmente em uso ativo. Também não consegue me dizer quais deletar, então mantém todos, e cada mudança no dbt se propaga por 200 blocos downstream.

Uma auditoria simples na maioria das equipes de BI: painéis com 3 ou menos visualizadores únicos nos últimos 30 dias. Em uma empresa típica de médio porte, isso corresponde a 60 a 75% do inventário. O custo não é apenas de armazenamento, é de atrito. Cada refatoração, cada mudança na definição de métricas, cada renomeação de coluna precisa ser testada de forma regressiva em painéis que ninguém abre.

Você não faz a auditoria porque deletar parece político. Alguém criou cada um desses painéis. Alguém ainda pode querer. Então você os mantém, e a sujeira se acumula, e os builds do dbt ficam mais lentos, e o tempo para publicar uma nova métrica vai de dois dias para duas semanas.

Correção para executar esta semana:

Revisão trimestral de descontinuação. Convite no calendário, 90 minutos, a cada trimestre, recorrente para sempre:

1. Puxe as estatísticas de uso: painéis com menos de 3 visualizadores únicos por mês no último trimestre.
2. Notifique os responsáveis (ou @canal se não houver responsável): "Este painel está na lista de descontinuação. Se você ainda precisar dele, responda até [data]. Do contrário, será arquivado."
3. Arquive (não delete; mova para uma pasta separada por 90 dias, depois delete).
4. Rastreie a contagem. Tente aposentar 20 a 30% do inventário na primeira auditoria. Menos do que isso e você não foi agressivo o suficiente.

As partes interessadas vão ser mais barulhentas do que você espera na primeira rodada e mais silenciosas em cada rodada seguinte. Até a terceira rodada, a equipe está enxuta e os builds do dbt terminam antes do almoço.

Armadilha 7: Medir Uso Sem Impacto na Decisão

Sintoma: O documento de avaliação de desempenho diz "visualizações do painel: 1.200 por mês" e "tickets fechados: 47 por mês". Não diz nada sobre o que mudou no negócio por causa de você.

Esta é a mais silenciosa das sete armadilhas para a carreira, porque não parece errada enquanto você a está cometendo. As visualizações aumentam, os tickets fecham, você parece produtivo. E então chega o ciclo de promoção e o analista sênior do pod ao lado é promovido com metade dos seus tickets, porque a autoavaliação dele dizia:

"Construí o modelo de retenção por coorte que redirecionou o movimento de renovação da equipe de customer success. Resultou em R$ 1,4M em ARR salvo no Q3 ao sinalizar contas em risco 60 dias antes do que o modelo anterior."

Essa frase supera "visualizações do painel: 1.200/mês" em todos os ciclos. Não é nem perto.

A armadilha é que métricas de atividade são fáceis de contar e impacto na decisão é difícil. Então você conta o que é fácil, e o analista sênior conta o que importa. Adivinhe quem recebe o título.

Correção para executar esta semana:

Inicie um "registro de decisões". Uma linha por análise, colunas:

Na maioria das semanas você vai adicionar 0 a 2 linhas. Esse é o ponto. A barra é "decisão alterada por causa desta análise", não "enviei um número". Se você não consegue preencher a coluna 4, o trabalho não moveu nada, e isso também é um sinal útil. Talvez o projeto fosse o projeto errado.

Na hora da promoção, a sua autoavaliação se escreve sozinha. E a conversa com o seu gestor muda de "você está acompanhando os tickets" para "qual é a próxima decisão que vale a pena tomar".

O Custo Composto de Carregar Essas Armadilhas para o Segundo Ano

Escolha uma delas e você vai sentir como um ponto de atrito, mas vai se recuperar. Carregue três ou mais para o segundo ano e a trajetória endurece. A reputação se forma. Você se torna "a pessoa dos painéis" ou "a pessoa do SQL" em vez de "o analista que nos fez eliminar a etapa errada do onboarding".

Essa reputação é o que é realmente difícil de desfazer. Atrasos na promoção de 9 a 15 meses são comuns. Vagas sênior vão para colegas que entregaram menos código mas conduziram mais decisões. E o pior resultado não é não ser promovido, é começar a acreditar que a versão de help desk do papel É o papel, e você para de almejar qualquer outra coisa.

A boa notícia é que a correção leva um trimestre, não um ano. A maioria dos analistas que corrigem esses padrões vê uma mudança perceptível em como são tratados em 6 a 8 semanas. As partes interessadas começam a perguntar "o que devemos fazer?" em vez de "você pode puxar esse número?". Esse é o jogo inteiro.

O Reinício de 30 Dias

Não tente corrigir todos os sete de uma vez. Você não vai corrigir nenhum.

Escolha os dois que mais te atingem. Seja honesto. O que você menos quer admitir provavelmente é o primeiro a atacar. A maioria dos analistas que oriento escolhe "virar o help desk" e "medir uso sem impacto na decisão". Eles tendem a se intensificar mutuamente.

Depois:

• Semana 1: Escolha a armadilha nº 1. Escreva a correção como um plano de uma página. Conte ao seu gestor que vai executá-lo.
• Semanas 2 e 3: Execute a correção. Rastreie o que muda: suas horas recuperadas, a resistência das partes interessadas, a qualidade do seu output.
• Semana 4: Acrescente a armadilha nº 2. O mesmo processo.

Até o dia 30 você terá dois novos hábitos. Até o dia 90 parecerão automáticos. Até o dia 180 você vai olhar para o analista que era e não vai se reconhecer.

Esse é o trabalho. Não aprender uma nova ferramenta. Não ficar mais esperto. Apenas recusar-se a derivar.

Checklist de autoavaliação

Execute esta segunda-feira de manhã. Respostas honestas apenas:

• Menos de 40% da minha semana são solicitações pontuais de menos de 30 minutos
• Todo projeto com mais de 4 horas tem um briefing escrito e aprovado antes de o SQL ser escrito
• Todo painel de controle que mantenho consegue nomear a decisão que impulsiona, o tomador de decisão e a cadência
• As minhas partes interessadas citam painéis ao vivo, não CSVs, em suas reuniões
• Todo SQL ou modelo dbt que mantenho está no git com histórico de pull request
• Realizo uma auditoria trimestral de descontinuação e arquivo pelo menos 20% do inventário não utilizado
• A minha autoavaliação tem pelo menos 5 entradas em um registro de decisões com impacto nomeado

Pontue-se de 0 a 7. Abaixo de 4, você está derivando. Entre 4 e 5, você é médio. De 6 a 7, você está operando como um analista sênior e provavelmente deveria ser pago como um, o que é uma conversa diferente para uma semana diferente.

Saiba Mais

• Modelo de Descrição de Cargo para Data Analyst
• Trajetória do Data Analyst: IC1 ao Staff
• Tradução para Partes Interessadas: de Solicitações Vagas a Análises Entregáveis
• Design de Painel de Controle que Gera Decisões