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

São 9h47 do terceiro dia. Você mal descobriu quais canais do Slack importam. O seu café ainda está quente. Uma mensagem chega de alguém que você encontrou uma vez durante o onboarding: "ei, você pode dar uma olhada no modelo de churn? ele está fora do padrão há um tempo."

Parabéns. Você acabou de herdar 18 meses de decisões de outra pessoa. Dois donos anteriores, sem documentação que valha ler, um conjunto de atributos que ninguém entende completamente e um CFO que está há seis semanas perguntando quando "o investimento em AI" vai pagar. O modelo não é retreinado desde agosto. Você ainda nem provisionou seu notebook completamente.

Essa é a experiência real do terceiro dia para a maioria dos novos Data Scientists em SaaS B2B, e a tentação é brutal: entregue algo rápido, qualquer coisa, para parecer que está justificando seu lugar. Não faça isso. Os primeiros 90 dias são quando você define a narrativa sobre se a liderança vai enxergar você como uma alavanca de receita ou como a próxima linha de custo a ser cortada quando o board perguntar onde o headcount está inchado. E os cargos de data science são cortados mais rápido do que qualquer outra função técnica quando a história de valor para o negócio está nebulosa.

Aqui está um plano de 90 dias que não exige heroísmo, não depende de você ser um gênio e não termina com você sendo dono do modelo de churn quebrado de outra pessoa como seu KPI.

Por Que Auditar Supera Construir (e Por Que a Maioria dos Novos DS Erra Aqui)

O maior erro que um novo Data Scientist comete é publicar um novo modelo na segunda semana para parecer produtivo. Parece ótimo. Também significa que você agora é dono de algo cujo contexto de negócio ainda não entende, sinalizou às partes interessadas que "publicar modelos" é sua proposta de valor (não é) e pulou a única janela que você já terá para fazer perguntas ingênuas sem julgamento.

Você tem exatamente um período de lua de mel. Use-o ouvindo, não construindo. A boa notícia é que ouvir produz artefatos tangíveis (um memo de auditoria, um mapa de partes interessadas, um guia de atalhos do data warehouse) que parecem tão produtivos ao seu gestor quanto um modelo pela metade faria, e não geram dívida técnica.

Dias 1 a 30: Auditar e Ouvir

Os primeiros 30 dias têm um único objetivo: construir um mapa defensável do que existe, do que está quebrado e do que as pessoas realmente querem. Nenhum modelo novo. Nenhum "experimento rápido." Nenhuma promessa.

Inventarie Cada Modelo em Produção

Monte uma planilha. Uma linha por modelo que roda em qualquer lugar: produção, notebook agendado, aquela coisa no Airflow que ninguém admite ser um modelo. Para cada um, preencha três colunas:

Desempenho vs. desempenho declarado. O que a ficha do modelo ou a última revisão trimestral diz que ele faz (AUC, precisão no top decil, MAPE, o que for)? O que ele realmente faz nos últimos 90 dias de dados? Você vai encontrar pelo menos um modelo com uma lacuna constrangedora. O modelo de churn costuma ser o pior infrator. Um desvio de 15 a 25% nos atributos principais é normal em SaaS B2B, onde o mix de clientes muda a cada trimestre.
Fairness e desvio de dados. A distribuição de entrada ainda está próxima do que o modelo foi treinado? Para modelos tabulares, uma verificação rápida do Population Stability Index (PSI) nos cinco atributos principais geralmente diz tudo. PSI acima de 0,25 significa que o modelo está operando fora da sua distribuição de treinamento e as previsões são ruído vestido de sinal.
Valor real para o negócio. Quem usa o resultado? Qual decisão ele orienta? O que aconteceria se o modelo retornasse um valor constante amanhã? Se a resposta for "honestamente, provavelmente nada," escreva isso. Você vai precisar depois.

Três a cinco modelos é normal. Oito ou mais significa que alguém estava construindo para parecer ocupado e você herdou um cemitério.

Participe de Cinco Sincs de Partes Interessadas

Não cinco conversas. Cinco sincs recorrentes às quais você se junta como observador silencioso nas duas ou três primeiras reuniões antes de começar a contribuir. Escolha uma de cada:

Sales ops (precisão de forecast, cobertura de pipeline, reclamações sobre lead scoring)
Customer success (sinais de churn, movimentos de expansão, vínculos de NPS com receita)
Produto (adoção de funcionalidades, ativação, o que estão testando com A/B test de forma ruim)
Finanças (previsão de receita, unit economics, o modelo real do negócio que o CFO usa)
Engenharia / plataforma de dados (custos do warehouse, confiabilidade de pipelines, o que está em chamas)

Você está ouvindo duas coisas: quais decisões estão sendo tomadas com base em intuição que poderiam ser tomadas com base em dados, e quais decisões estão sendo tomadas com base em dados que estão na verdade errados. A segunda é mais comum do que as pessoas admitem. Sales ops rodando forecasts de pipeline com base em um relatório do Salesforce que conta renovações em duplicidade é um dos cinco maiores acertos na maioria das empresas SaaS B2B.

Aprenda Onde Vivem as Mentiras no Warehouse

Todo data warehouse tem uma camada de pequenas verdades terríveis. Colunas renomeadas três vezes. Linhas soft-deleted que a ferramenta de BI silenciosamente inclui. Bugs de fuso horário que fazem segundas-feiras em Cingapura aparecerem como domingos. Um campo receita_usd que é pré-desconto em uma tabela e pós-desconto na tabela ao lado.

Passe uma semana com quem é dono da camada de analytics. Leve um notebook. Pergunte: "O que você gostaria que as pessoas soubessem antes de consultar esta tabela?" Você vai obter mais valor dessa única pergunta do que de três semanas lendo a documentação do dbt.

Ao final do dia 30 você deve ter: uma planilha de auditoria, anotações de cinco sincs de partes interessadas, um documento de uma página com "armadilhas do data warehouse" e zero novos modelos em andamento.

Dias 31 a 60: Encerrar, Entregar, Propor

Agora você começa a produzir trabalho visível. Três entregas, nesta ordem.

Encerre um Modelo Quebrado, Publicamente, com um Memo

Isso parece prejudicial à carreira. É o oposto. Encerrar um modelo quebrado é a ação de maior alavancagem que você pode tomar como novo DS, porque:

Libera compute, atenção do headcount e largura de banda das partes interessadas.
Demonstra que você tem julgamento, não apenas throughput.
Estabelece que "publicar um modelo" não é uma virtude se o modelo está errado.

Escolha o pior caso da sua auditoria. O candidato clássico é o modelo de churn que foi retreinado duas vezes em 18 meses, tem 22% de desvio nos atributos, não orienta nenhuma ação real de retenção (os reps de CS ignoram o score) e custa R$ 400 por mês em compute. Escreva um memo de uma página: o que o modelo afirmava fazer, o que ele realmente fazia, quanto custava, qual decisão deveria orientar, o que você propõe em substituição (frequentemente: "um relatório de coorte simples, atualizado semanalmente").

Envie o memo ao seu gestor e à parte interessada original. Deixe-os responder. Nove em dez vezes eles vão dizer "sim, paramos de olhar para isso há meses." Agora ele foi desativado com um rastro documental, e você demonstrou à liderança que vai cortar seu próprio trabalho quando esse trabalho não estiver gerando valor.

Um template curto que funciona:

Memo: Encerrando o modelo [nome do modelo]
Autor: [você]
Data: [data]

O que ele faz hoje: [uma frase]
O que afirmava quando foi lançado: [métrica e valor]
O que realmente faz nos últimos 90 dias: [métrica e valor]
Custo de compute: [$/mês]
Decisões que orienta: [lista, seja honesto se a resposta for "nenhuma"]
Recomendação: Encerrar em [data]. Substituir por [algo mais simples ou nada].
Risco se não encerrarmos: [manutenção contínua + falsa confiança em previsões desatualizadas]

Isso é tudo. Uma página. Sem apêndices.

Entregue uma Análise de Vitória Rápida Que uma Parte Interessada Realmente Pediu

Volte às suas anotações de sincs de partes interessadas. Encontre a solicitação menor e mais concreta, aquela que a pessoa mencionou de passagem, com uma decisão clara vinculada. Não "deveríamos usar AI para X." Algo como: "Gostaria de saber qual etapa do onboarding está causando o maior abandono nos primeiros 14 dias."

Faça essa. Relatório amigável para o Slack. Três gráficos no máximo. Recomendação no primeiro parágrafo. Chame a pessoa que pediu mais o gestor dela. Você não está tentando vencer uma competição no Kaggle. Está provando que consegue converter uma pergunta real em uma resposta real em menos de dez dias úteis.

Proponha um Roadmap de ML de 6 Meses Vinculado a 2 ou 3 Métricas de Negócio

Até o dia 60 você deve ter contexto suficiente para esboçar um roadmap. Duas a três métricas de negócio, no máximo. Para cada uma, uma hipótese de 1 a 2 frases, uma abordagem de modelo ou análise, uma estimativa de esforço (pequeno / médio / grande) e, o mais importante, um critério de encerramento (o que faria você interromper o trabalho nessa frente).

Critérios de encerramento são o que separa um roadmap de uma lista de desejos. "Se até a semana 8 o ganho de linha de base estiver abaixo de 5%, paramos e realocamos" é uma linha de roadmap. "Construir um modelo de churn" não é.

Compartilhe o roadmap com o executivo que contratou você. Receba o feedback. Revise. O objetivo é que ele consiga descrever seus próximos dois trimestres em uma frase para qualquer pessoa na C-suite.

Dias 61 a 90: Seja Dono de Uma Métrica, Apresente e Planeje o H2

Os últimos 30 dias tratam de transitar de "o novo DS" para "a pessoa que é dona de X."

Seja Dono de Uma Métrica de Negócio Vinculada a um Modelo

Atenção ao framing aqui: você é dono da métrica, não do modelo. Se você é dono do "modelo de churn," herdou a identidade de outra pessoa e será julgado por algo que não projetou. Se você é dono da "retenção de logos em 12 meses no segmento SMB," pode usar qualquer combinação de modelo, análise e mudança operacional que mova o número.

Escolha uma. Apenas uma. Ela deve ser:

Uma métrica que finanças e a equipe executiva já acompanham (não invente uma nova)
Dentro da sua esfera de influência (um modelo a toca, mas também o workflow de CS, precificação e produto)
Mensurável em janelas de 60 a 90 dias, não de 12 meses

Boas escolhas comuns para um novo DS em SaaS B2B: taxa de churn de SMB, conversão de lead para oportunidade, conversão de trial gratuito para pago, receita de expansão por CSM. Más escolhas comuns: receita total (muitos insumos, você nunca vai receber crédito), NPS (muito ruidoso), "precisão do modelo" (não é uma métrica de negócio).

Apresente um Relatório de 90 Dias ao Executivo Que Contratou Você

Reunião de 15 minutos. Deck de cinco slides. A estrutura que funciona:

O que encontrei. A auditoria, em um gráfico (modelos encerrados, modelos saudáveis, modelos em observação).
O que entreguei. A análise de vitória rápida, o memo de encerramento, a métrica que agora é minha.
O que aprendi sobre o negócio. As duas ou três coisas que te surpreenderam (problemas de qualidade de dados, decisões que não estão sendo tomadas com base em dados, solicitações que continuam aparecendo).
O roadmap. Seu plano de 6 meses, com critérios de encerramento.
O que preciso. Headcount, infraestrutura, acesso a partes interessadas, decisões.

O slide cinco é o mais importante e o mais frequentemente omitido. Se você não consegue articular o que precisa para ter sucesso nos próximos 90 dias, o executivo vai assumir que você não precisa de nada, e então vai se perguntar no mês seis por que o progresso travou.

Proponha um Plano de ML para o H2 com Headcount, Infraestrutura e Critérios de Encerramento

Este é o roadmap do dia 60, agora refinado com três meses de contexto. Três coisas entram no plano de H2 que não estavam no roadmap original:

Matemática de headcount. "Para executar este plano, preciso de X dias de engenharia e Y dias de engenharia de dados por trimestre. Hoje tenho Z. Aqui está a lacuna." Seja específico. ML Engineers são caros. A capacidade de engenharia de dados é o gargalo em 60% do trabalho de DS na maioria das empresas SaaS B2B, e dizer isso em voz alta cedo protege você de ser responsabilizado por problemas de entrega que não são seus.
Necessidades de infraestrutura. Repositório de atributos? Rastreamento de experimentos? Uma plataforma de inferência gerenciada? Liste-as com custos aproximados. O CFO prefere ver uma linha de R$ 150 mil/ano agora do que uma surpresa de R$ 150 mil/ano no Q3.
Critérios de encerramento, revisados. Seis meses de trabalho sempre revelam quais apostas estavam erradas. Codifique quando você vai parar, não apenas quando vai começar.

A Conversa em Que o CFO Pergunta Sobre ROI

Essa conversa está chegando. Provavelmente na semana 5 ou 6. Geralmente soa assim: "Então, quando vamos começar a ver retorno sobre o investimento em AI?"

As respostas erradas: "É um investimento de longo prazo." "AI leva tempo." "Ainda estamos na fase de experimentação." Todas essas são verdadeiras. Nenhuma delas funciona. O CFO está fazendo uma pergunta legítima e merece uma resposta legítima.

A resposta que funciona:

"No momento estou em modo de auditoria. Encontrei dois modelos que nos custam cerca de R$ X por mês e não orientam nenhuma decisão, e vou encerrá-los até o fim do mês. Até o dia 90 vou ser dono da métrica de churn de SMB e ter um roadmap com duas ou três apostas, cada uma vinculada a uma métrica de negócio que você já acompanha, cada uma com um critério de encerramento. A resposta honesta para 'quando veremos retorno' é: até o fim do Q3 se eu estiver certo, e saberemos cedo o suficiente para redirecionar se eu estiver errado."

Esse é o framing. Ações concretas de curto prazo, uma métrica que você vai possuir, uma data e um plano para falhar rápido se as apostas não derem certo. CFOs respondem bem a critérios de encerramento porque nunca ouviram um Data Scientist mencioná-los antes.

Erros Comuns Que Vão Afundar Silenciosamente os Primeiros 90 Dias

Algumas armadilhas que pegam até DSes experientes:

Construir na segunda semana para "parecer produtivo." Você vai herdar a culpa por esse modelo para sempre. Resista.
Dizer sim para solicitações de "uma AI" sem escopar a decisão real. Quando um VP diz "podemos usar AI para [coisa vaga]?", a resposta certa é "qual decisão você tomaria de forma diferente com o resultado?" Se ele não conseguir responder, o projeto ainda não existe. Não se voluntarie para construí-lo assim mesmo. (Escopando solicitações vagas de AI vai mais fundo aqui.)
Herdar o modelo de churn quebrado como seu KPI. O modelo é uma ferramenta. Retenção é a métrica. Seja dono da métrica.
Ignorar o imposto de engenharia de dados. 60% do seu tempo no primeiro ano vai para encanamento de dados: corrigir pipelines, depurar joins, validar que o número do warehouse corresponde ao número da ferramenta de BI. Orce para isso. Não finja que vai ser 20%.

Medindo o Sucesso no Dia 90

O teste honesto de um primeiro 90 dias bem-sucedido não é "você publicou um modelo." É:

Você consegue nomear as três principais métricas de negócio e quais modelos tocam cada uma
Um modelo quebrado está encerrado, com rastro documental
Uma análise de vitória rápida foi entregue e recebeu crédito do solicitante
Você é dono de uma métrica, não de cinco
O executivo que contratou você consegue descrever seu roadmap em uma frase

Se essas cinco coisas forem verdadeiras no dia 91, você está preparado para um ano forte. Os Data Scientists que se esgotam no mês nove quase sempre construíram um novo modelo no mês um e passaram os oito seguintes defendendo-o.

Playbooks para Data Scientists