Quando eu olho para trás, eu não vejo minha entrada em dados como uma decisão super planejada. Não teve um momento cinematográfico em que eu pensei: “agora vou virar analista de dados”. Na prática, foi bem menos bonito — e talvez por isso tenha sido mais real.
Eu comecei como estagiário de pré-vendas na Sympla, em Belo Horizonte. Era SDR. Meu trabalho era qualificar leads, organizar informações para o time comercial e tentar dar algum ritmo para um processo que ainda estava sendo estruturado. Na época, eu nem sabia direito que “área de dados” era uma carreira possível dentro das empresas.
Mas eu gostava muito de Excel. E, por gostar de Excel, comecei a organizar o processo comercial de um jeito mais estruturado: leads, taxa de conversão, tempo de fechamento, histórico de contato, origem dos potenciais clientes. Olhando hoje, eu estava montando uma espécie de banco de dados do processo comercial. Só que eu não tinha esse nome para aquilo.
O primeiro passo não foi técnico. Foi perceber uma bagunça.
Esse é um ponto que eu acho importante para quem está tentando entrar em dados. A carreira não começa necessariamente quando você aprende a primeira query. Muitas vezes, ela começa quando você olha para uma rotina confusa e pensa: “isso aqui poderia estar mais organizado”.
Foi exatamente isso que aconteceu comigo. Eu não estava tentando construir um portfólio. Não estava tentando impressionar ninguém com um dashboard. Eu só estava perto de um problema real e tentei deixar aquele problema mais claro.
Aí uma pessoa entrou na empresa para estruturar a área de dados, viu o que eu estava fazendo e percebeu que talvez existisse ali um potencial. Foi assim que eu fui puxado para a área. Primeiro veio o problema. Depois veio a ferramenta.
A ordem que muita gente inverte
Hoje, quando vejo pessoas tentando migrar para dados, percebo uma ansiedade enorme para aprender tudo ao mesmo tempo: SQL, Python, Power BI, Tableau, estatística, cloud, machine learning, IA, dbt, Airflow. A lista parece infinita.
O problema é que essa ansiedade às vezes coloca a ferramenta antes do raciocínio. A pessoa acha que só vai poder começar quando dominar o stack perfeito. Mas, no dia a dia, dados é muito mais sobre transformar uma pergunta bagunçada em uma estrutura minimamente confiável.
Você precisa entender o que está sendo contado. O que é uma linha. O que é uma coluna. Qual é a regra de negócio. O que deveria entrar na análise e o que deveria ficar fora. Isso parece simples, mas é exatamente o tipo de coisa que separa uma análise útil de uma planilha bonita e errada.
Excel não é “menos dados”
Existe um certo preconceito com Excel em algumas conversas de tecnologia. Como se trabalhar com Excel fosse uma etapa inferior ou pouco sofisticada. Eu discordo bastante disso.
Para muita gente, Excel é o primeiro lugar onde a pessoa aprende a pensar em tabelas, filtros, totais, duplicidades, regras, comparações e erros de preenchimento. É onde ela começa a perceber que dado não é só número. É processo.
No meu caso, Excel foi uma ponte. Ele me ajudou a entender lógica de tabela antes de eu saber SQL. Me ajudou a perceber padrões antes de eu saber estatística. Me ajudou a organizar um processo antes de eu conhecer ferramentas de BI.
Depois, claro, SQL virou central. Python entrou em outro momento. Ferramentas de visualização também. Mas a base veio de tentar entender e organizar um problema real.
A melhor forma de começar é procurar um problema perto de você
Se você quer entrar em dados, meu conselho não seria “comece instalando todas as ferramentas possíveis”. Eu começaria de outro jeito: olhe para o seu trabalho atual, mesmo que ele não seja oficialmente um trabalho de dados, e procure alguma rotina que poderia ser melhor medida.
Pode ser uma planilha de vendas. Um controle de atendimento. Uma lista de clientes. Um histórico de campanhas. Um fluxo financeiro. Um processo de recrutamento. Um calendário editorial. Quase toda área tem algum processo que gera dados, mesmo que ninguém chame aquilo de dados.
A pergunta é: o que dá para organizar melhor? O que dá para acompanhar com mais clareza? Que número ajudaria alguém a tomar uma decisão melhor?
Quando você começa por aí, o estudo técnico deixa de ser abstrato. SQL passa a ser uma forma de responder uma pergunta. Python passa a ser uma forma de automatizar uma rotina. Dashboard passa a ser uma forma de acompanhar algo que realmente importa.
O que eu teria feito mais cedo
Se eu pudesse voltar, eu provavelmente teria estudado SQL mais cedo. Teria entendido antes que SQL é o “acesso ao jogo” para quem quer trabalhar com dados. Mas eu não me arrependo de ter começado pelo problema.
Na verdade, acho que isso me ajudou. Porque, desde o começo, eu aprendi que dado só tem valor quando melhora uma decisão, reduz uma dúvida ou dá mais clareza para um processo. O resto é ferramenta.
E ferramenta você aprende. Sintaxe você pesquisa. Hoje, com IA, isso ficou ainda mais acessível. Mas desenvolver curiosidade, atenção ao detalhe e vontade de entender o negócio demora mais.
Resumo direto
Você não precisa esperar ter o currículo perfeito para começar em dados. Se você já organiza informações, cria controles, melhora processos e tenta transformar bagunça em clareza, talvez você já esteja desenvolvendo parte do raciocínio que a área exige.
A diferença é dar o próximo passo: aprender SQL, entender banco de dados, praticar análise e começar a transformar esse instinto em habilidade profissional.
A minha carreira não começou com a ferramenta perfeita. Começou com um problema perto de mim.
