Um Dia na Vida de um Data Scientist

São 8h07. Seu celular vibrou às 6h42 com um alerta de degradação do modelo do MLflow. O PM te mandou uma DM no Slack às 7h55: "pergunta rápida: por que esse usuário foi sinalizado como rotatividade?" Você ainda não abriu o laptop. Bem-vindo ao trabalho que ninguém descreve com precisão no LinkedIn.

A descrição do cargo que você aceitou prometia "construir modelos de ML, gerar insights, colaborar com partes interessadas." Tudo isso é verdade, tecnicamente. As proporções não são. Em uma terça-feira típica em uma empresa B2B SaaS, construir modelos ocupa talvez um quarto do seu dia. Engenharia de atributos e plumbing de SQL consomem outra boa fatia. O restante é trabalho de tradução: explicar a um VP por que precisão não é exatidão, defender um intervalo de confiança para um líder de vendas, gravar um Loom que ninguém assiste e lembrar à equipe de plataforma que, sim, o modelo dbt que quebra toda quarta-feira ainda está quebrando toda quarta-feira.

Esta não é a versão do trabalho do DS sênior no LinkedIn. É a versão real. Se você está há três meses e sua semana não tem nada a ver com o cargo para o qual foi entrevistado, isso não é um defeito em você. É o cargo.

Aqui está como uma terça-feira real parece.

8h às 8h30: A verificação de desempenho do modelo

Com o café na mão e o laptop aberto, a primeira aba é sempre o MLflow ou o Weights & Biases. Você analisa as previsões de ontem contra os labels que chegaram durante a noite. O AUC do modelo de rotatividade caiu de 0,84 para 0,79 no fim de semana. Não é uma catástrofe, mas é suficiente para investigar antes do standup.

Você verifica as coisas óbvias primeiro. A distribuição de entrada mudou? Você abre o dashboard de desvio de atributos. Dois atributos estão derivando. Um é "dias desde o último login", o que faz sentido porque a equipe de produto publicou um novo fluxo de onboarding na sexta e vários usuários antigos foram redirecionados de volta. O outro é "tickets de suporte nos últimos 30 dias", que não tem uma explicação óbvia. Você anota para investigar após o standup.

Essa verificação de trinta minutos é uma das partes mais subestimadas do trabalho. Metade dos DS sênior que conheço foi promovida por detectar algo aqui que ninguém mais teria detectado. O modelo não quebrou. O mundo no qual o modelo foi treinado quebrou, levemente, e você notou antes de qualquer outra pessoa.

Você também verifica os experimentos de ontem no MLflow. Dois dos seus colegas iniciaram jobs de treinamento às 23h. Um convergiu. O outro explodiu porque alguém renomeou uma coluna na tabela de origem sem avisar ninguém. Bem-vindo ao trabalho com dados.

9h30 às 11h30: Design de experimento (90 minutos discutindo a métrica)

O PM chega ao standup com uma pergunta: "A nova página de precificação converte melhor?" Simples, certo? Tamanho da amostra, teste de duas proporções, publica.

Nunca é assim tão simples.

Você passa 90 minutos no Hex definindo o escopo do experimento. A matemática é a parte fácil. Veja o que realmente consome o tempo:

Definir o que é "vencer". O PM quer medir cliques no botão "Iniciar teste grátis". Você explica que cliques não são o mesmo que inícios, inícios não são o mesmo que ativações e ativações não são o mesmo que conversões pagas. Quando termina, a métrica de sucesso mudou três vezes e você tem uma métrica de proteção para retenção na primeira semana porque o funil da página de precificação antiga tinha um vazamento conhecido após a ativação.

Verificação de realidade do cálculo de poder estatístico. Com o tráfego semanal atual, detectar um lift relativo de 3% em conversões pagas requer rodar o teste por seis semanas. O PM quer resultados em duas. Você concorda em usar uma métrica proxy mais ruidosa (inícios de teste) para a leitura antecipada e a métrica real (conversões pagas) para a decisão.

Métricas de proteção. E se a nova página aumentar os inícios de teste, mas prejudicar a qualidade desses testes? Você adiciona uma proteção na taxa de ativação. E se mudar o mix de seleção de planos? Você adiciona uma proteção na receita média por novo cliente. Agora há três métricas, duas proteções e uma regra de parada.

Pré-comprometimento de segmentação. O PM pergunta se você pode "apenas fatiar por tamanho de empresa depois". Você diz não, e depois sim, mas apenas com correção de Bonferroni e uma lista escrita dos segmentos antes do início do teste. Vocês escrevem a lista juntos. Isso vai salvar o emprego de alguém mais tarde.

Você publica o documento de design de experimento no workspace Hex da equipe, cria um link na página do projeto no Notion e menciona o PM e o líder de Engenharia. A matemática levou 15 minutos. A conversa levou 75. Essa proporção está mais ou menos certa para o restante da sua carreira.

12h30 às 14h: Assíncrono com Engenharia sobre a implantação em produção

Você almoça rapidamente na mesa. O bloco da tarde é o que mais frustra os novos DS: o seu modelo está "pronto para publicar" há três semanas, e o bloqueio não tem nada a ver com o modelo.

O modelo em si está bem. O problema é o pipeline de atributos. Seu modelo de rotatividade precisa de um atributo chamado engajamento_ponderado_30d, que é a soma ponderada de logins, mensagens enviadas e participação em reuniões nos últimos 30 dias. Esse atributo é computado em um modelo dbt chamado fct_engajamento_usuario_diario. O modelo dbt quebra toda quarta-feira entre 6h e 7h no horário do Pacífico porque depende de uma sincronização com o Salesforce que termina de forma inconsistente.

Você não é responsável pelo modelo dbt. A equipe de analytics engineering é. Eles sabem que está instável. Têm um ticket para isso. Têm o ticket há dois meses.

Então o trabalho de hoje é escrever um longo comentário no PR do staging. Você explica:

O pipeline de atributos tem uma janela de falha semanal conhecida
Seu modelo precisa do atributo com no máximo 24 horas de desatualização
O monitoramento atual no modelo dbt dispara depois que o atributo já está desatualizado
Você gostaria que a equipe de plataforma ou corrigisse o modelo dbt upstream ou instalasse um fallback que use o último snapshot válido do atributo com uma flag de atualidade

Você menciona o líder da equipe de plataforma, cria link do alerta de monitoramento dbt da última quarta como evidência e cria link do seu documento de requisitos de atualidade do modelo. Você não escala. Não reclama. Você deixa um comentário de PR calmo e específico com três opções classificadas por sua preferência e uma recomendação padrão. Então fecha a aba.

Essa é a parte do trabalho que o JD chama de "colaboração interfuncional". É principalmente esperar, com advocacia calma e intermitente, que algo que você não consegue corrigir seja corrigido por outra pessoa. Aceite isso cedo.

14h às 15h: A reunião "essa previsão está errada"

Um líder de vendas agendou trinta minutos no seu calendário. O assunto: "Conversa rápida sobre o modelo de rotatividade: um dos meus clientes que ele sinalizou acabou de renovar por três anos."

Você sabe como isso vai ser. Você teve essa reunião cerca de quatorze vezes desde que começou. Você tem um roteiro. Aqui está o formato geral:

Comece com curiosidade, não com defesa. "Me conte sobre o cliente. Qual é a história deles?" Você deixa o líder de vendas reclamar por cinco minutos sobre como o modelo vai envergonhar a equipe, como o cliente ficaria ofendido se soubesse, e como ele sempre teve uma sensação de que o modelo era não confiável.

Reformule a métrica sem fazê-los se sentir mal. "O modelo prevê com 87% de precisão no coorte de 'alto risco de rotatividade'. Isso significa que, de cada 100 contas sinalizadas, cerca de 87 realmente abandonam em 90 dias. As outras 13 não. Esta conta é uma dessas 13. Isso não é o modelo falhando. É o modelo performando exatamente como projetado."

Traga um dashboard do Looker, não um tom defensivo. Você compartilha a tela e abre o Looker de desempenho do modelo de rotatividade. Você mostra a curva de precisão-revocação. Você mostra que diminuir o limiar para capturar mais rotatividade significaria ainda mais falsos positivos, e aumentá-lo perderia rotatividade real. Você mostra o valor em dólares da rotatividade capturada no trimestre passado ($2,4M) versus o valor dos falsos positivos se cada conta sinalizada fosse embora (muito maior do que isso, mas eles não precisam saber).

Feche com o propósito do modelo, na linguagem deles. "Este modelo é uma ferramenta de triagem. Não é um veredicto. Ele diz à sua equipe onde gastar a primeira hora da semana. O fato de uma conta sinalizada ter renovado significa que sua equipe fez o trabalho. Eles intervieram. Esse é o critério de sucesso."

O líder de vendas sai da reunião mais calmo do que entrou. Você adiciona a conversa ao log de experimentos. Você adiciona um slide para a próxima sincronização mensal DS-para-Vendas chamado "Precisão não é Exatidão", porque se você teve essa conversa 14 vezes, o restante da equipe de vendas a teve com mais frequência do que está admitindo.

16h às 17h30: Limpeza do notebook e o log de experimentos

O último bloco do dia é de volta ao Jupyter. Você abre o notebook de análise do escopo de experimento da página de precificação desta manhã. Está uma bagunça. Metade é código de rascunho. Há uma célula que só diz df.head() sem comentário. Há um gráfico sem rótulos nos eixos. Há uma consulta SQL contra o schema errado.

Você organiza tudo. A disciplina aqui importa mais do que a aparência. Você não está deixando bonito para si mesmo. Está deixando legível para a versão de você em três meses que precisará lembrar por que escolheu tamanho de amostra 4.200 e não 5.000. A convenção na sua equipe:

Célula de markdown no topo do notebook com a pergunta, a data e a conclusão
Cada seção tem um cabeçalho markdown de uma linha acima do código
Gráficos têm títulos, rótulos nos eixos e uma frase de interpretação abaixo
A célula final é uma célula de markdown com a recomendação e a próxima ação

Você faz commit do notebook no repositório da equipe. Você escreve um resumo de 200 palavras no log de experimentos da equipe, que fica em uma página Notion compartilhada. Você também faz push da mudança no modelo dbt que escreveu esta manhã. Está em um branch separado e marcado para revisão amanhã.

Última coisa antes de fechar o laptop: você verifica as notas da reunião com o líder de vendas das 14h e adiciona um TODO ao backlog da equipe. "Construir um dashboard no Looker voltado para vendas que mostre a precisão e a revocação do modelo de rotatividade em termos simples, atualizado semanalmente." Esta é a terceira vez que você pensou em construí-lo. Talvez esta semana você realmente construa.

O que o JD não vai te dizer

Algumas coisas que o JD vai omitir e que valem saber no primeiro dia.

Você vai escrever mais SQL do que Python. O Snowflake ou o BigQuery será o seu segundo idioma. Quanto mais limpo for o seu SQL, mais rápido será o seu ciclo de iteração. A maioria dos gargalos na sua semana não é modelagem. É "os dados ainda não estão no formato certo."

Engenharia de atributos consome 40% do seu tempo de modelagem. O modelo XGBoost leva 20 minutos para treinar. Os atributos que entram nele levaram duas semanas para construir, validar e conectar a um pipeline. Novos DS subestimam isso todas as vezes.

O "problema de ML" mais difícil costuma ser uma parte interessada que não confia no output. Você pode ter um modelo perfeitamente calibrado com um AUC digno de publicação e zero impacto, porque ninguém vai agir com base nele. A confiança é construída por meio de explicações repetíveis, dashboards na linguagem das partes interessadas e aparecer na reunião "essa previsão está errada" com calma.

O pânico de "essa previsão está errada" é um evento semanal. Tenha um roteiro pronto. Traga um dashboard. Não fique na defensiva. A conversa é o trabalho, não uma distração do trabalho.

As implantações em produção são mais lentas do que você pensa. Não porque o código é difícil. Porque as dependências de dados são instáveis, o ambiente de staging é um espelho da produção do trimestre passado, e a equipe de plataforma também está fazendo o melhor que pode.

Ferramentas que você vai usar de verdade

O stack varia por empresa, mas o formato é consistente. Na maioria das empresas B2B SaaS com uma função real de DS em 2026:

Python e Jupyter para análise e modelagem. Algumas equipes migraram trabalhos mais pesados para o VS Code com notebooks como arquivos de porcentagem, mas o Jupyter ainda é o padrão para exploração.
SQL no Snowflake ou BigQuery para tudo que toca dados de produção. Se você veio de um lugar que usava Postgres diretamente, o modelo mental do data warehouse é diferente, e você vai pensar no custo por consulta pela primeira vez.
dbt para transformações. Você vai ler mais modelos dbt do que vai escrever, mas vai escrever alguns.
MLflow ou Weights & Biases para rastreamento de experimentos. A maioria das equipes tem um ou outro; quase não importa qual.
Hex para notebooks colaborativos que PMs e analistas conseguem ler. O Hex está fazendo para analytics o que o Figma fez para design.
Looker para dashboards voltados para partes interessadas. Os dashboards que você constrói aqui são pelos quais suas partes interessadas o julgam, mesmo que o modelo por trás deles seja o trabalho real.
Opcional, mas comum: Airflow, Prefect ou Dagster para orquestração. Você pode ou não ser responsável por eles.

Você não vai usar todos esses em toda equipe. Provavelmente vai aprender um novo nos primeiros 90 dias.

Como é o "bom" após 90 dias

Se você é novo na função, aqui está uma definição útil de sucesso na marca de três meses. Esqueça a contagem de modelos. Procure isso:

Você consegue nomear as perguntas reais das suas três principais partes interessadas, na linguagem delas, sem um documento na sua frente.
Você tem um modelo em produção. Mesmo um pequeno. Mesmo uma regressão logística em um único atributo. Produção supera notebook.
Você parou de se assustar quando uma parte interessada te manda "essa previsão está errada". Você tem um roteiro. Você traz um dashboard.
Você sabe quais modelos dbt quebram semanalmente e quais atributos são instáveis. Você parou de se surpreender com a quebra de quarta-feira.
Você escreveu pelo menos um documento que outro DS da equipe criou um link. Conhecimento que se acumula supera análise que cai no esquecimento.

Essa é a barra. Não é "publicou cinco modelos" ou "dobrou a velocidade da equipe." Essas métricas não sobrevivem ao contato com a realidade. A lista acima sobrevive.

A divisão 50/50 entre trabalho técnico e trabalho de tradução não é uma falha na função. É a função. Tradução não é inferior à modelagem. É como a modelagem realmente muda alguma coisa. Os DS que se dedicam a isso mais cedo do que seus pares são os que são promovidos a Sênior em 18 meses em vez de 30.

O alerta de degradação do modelo às 6h42 vai vibrar de novo amanhã. Tome o café da manhã primeiro.

Playbooks para Data Scientists