# Primeiros 90 dias como dev: plano mês a mês

> Published 2026-10-11T02:09:23.421Z on https://www.crazystack.com.br/pt/p/primeiros-90-dias-como-dev-plano-mes-a-mes/
> Source video: https://www.youtube.com/watch?v=ueFQfd7X4ag

Quase nenhuma empresa tem um onboarding em dia, e é justamente aí que você começa a vencer nos primeiros 90 dias como dev. O caminho é faseado: entender o negócio, entregar tarefas simples com confiabilidade e só então assumir a responsabilidade por uma área.

## Como planejar os primeiros 90 dias como dev

Os primeiros 90 dias como dev funcionam melhor em três fases: um mês de compreensão, um mês de confiabilidade e um mês de ownership. Entrar num emprego novo e tentar sair contribuindo com qualidade desde o primeiro dia é difícil, e muitas vezes a contribuição apressada vira contraproducente.

A lógica é simples. No primeiro mês, você ainda não conhece o produto, o processo nem as pessoas. No segundo, você já entende o suficiente para que a equipe possa depender de você. No terceiro, coincide com o fim típico do período de experiência, e é quando você passa a ser dono de algo dentro da empresa.

A preparação começa antes do primeiro dia, no fim do processo de entrevista. A oferta traz salário, benefícios e política de trabalho, mas também traz responsabilidades definidas pela vaga aberta. Descobrir por que aquela posição existe é a forma mais rápida de entender o que a empresa considera sucesso no cargo.

Vale ajustar o plano ao seu nível. Um júnior entra com expectativas diferentes de um sênior, e quem fez o Crazystack Typescript ou um [Bootcamp do Dev Doido](https://crazystack.com.br) chega com um ferramental diferente de quem veio de outra stack. As proporções mudam, mas a sequência das fases se mantém.

## Por que compreensão vem antes de contribuição

A contribuição só agrega valor depois que você entende o que a empresa faz e como a equipe trabalha. Código entregue sem esse entendimento pode parecer produtivo, mas frequentemente precisa ser refeito, revisado com pressa ou revertido. A tabela abaixo resume o papel de cada fase:

| Fase | Foco | Resultado esperado |
| --- | --- | --- |
| Mês 1 | Compreensão | Entender negócio, processo e code base |
| Mês 2 | Confiabilidade | Entregar no prazo e comunicar riscos cedo |
| Mês 3 | Ownership | Ser dono de uma área e propor melhorias |

Nos dois primeiros meses você é, na prática, reativo: resolve o que aparece, porque ainda não sabe onde pode pisar. A proatividade de verdade, com sugestões de melhoria e criação de tickets, só se torna segura por volta do sexagésimo dia.

## Primeira semana: as perguntas que definem sua prioridade

Duas perguntas guiam sua primeira semana: o que é importante para a empresa e como a equipe contribui. Sem elas, você não sabe para onde direcionar esforço. Saber quais clientes e produtos geram mais receita mostra em quais projetos vale concentrar energia.

Responder a segunda pergunta passa por entender o fluxo de trabalho em software. Existe uma sprint, alguém cria os tickets, os tickets chegam até você, você abre um pull request, passa por code review, QA e por fim o deploy. Se a empresa não tem estrutura e você for jogado num ambiente caótico, a tentação é usar [Claude Code](https://claude.com/claude-code) para empurrar uma feature que você não entende. Isso é o oposto do ideal.

Ferramentas fazem parte desse mapeamento. Vale listar o que você vai encarar no dia a dia: configurar o [Sentry](https://sentry.io) e olhar os erros que importam, acompanhar dashboards, revisar issues no [GitHub](https://github.com). Já sabe de cabeça, mas escrever a lista evita depender de memória.

Reserve tempo para pessoas, não só para sistemas. Conversas curtas de cinco ou dez minutos com cada colega, aproveitadas no standup, rendem mais do que interromper alguém com dúvida urgente. Pergunte ao manager quem decide, de onde vêm os tickets e como a empresa se organiza. Se aparecerem ferramentas de IA como o [Gemini](https://gemini.google.com) no fluxo da equipe, entenda onde elas entram antes de usar.

## Como aprender a code base com tarefas simples

Pegue a feature mais simples do planeta, como trocar a cor de um botão, e execute o processo completo. Um ticket trivial atravessa as mesmas etapas de um grande: sprint, pull request, padrões da code base, review e QA. Fazendo algo pequeno, você aprende como a equipe contribui sem risco de quebrar nada.

Leitura passiva não substitui essa prática. Muita gente recomenda dedicar semanas para estudar a code base antes de contribuir, mas entender de verdade costuma vir de alterar o código por conta própria. Você mapeia lendo e entende editando.

A partir da segunda semana, amplie o alcance. Participe de code reviews o quanto antes, porque revisar código alheio acelera o domínio da base. Investigue como o deploy acontece, seja num script de [GitHub Actions](https://github.com/features/actions) ou em outro fluxo, e descubra se existem feature flags entre o que está sendo criado e o que chega ao cliente.

## Anotar e corrigir: o onboarding defasado

Praticamente toda empresa tem um processo de onboarding desatualizado, e isso é uma oportunidade, não um defeito a esconder. Conforme a empresa cresce, documentação antiga e setups de máquina defasados se acumulam. A pessoa que entra depois de você vai esbarrar nos mesmos problemas.

Enquanto faz seu onboarding, anote onde os documentos mentem e corrija o que conseguir. Você já chega ajudando, e a equipe percebe. Se ninguém te apresentar um diagrama da arquitetura, crie um por conta própria e suba nos repositórios; se existir, estude-o de fato para poupar seu tempo e o dos colegas no futuro.

Anotar também vale para o estranho. Você vem de outro ambiente e enxerga processos que a empresa naturalizou: um deploy que depende de uma pessoa específica, um linting manual, uma build rodada à mão antes de abrir pull request. Levante esses pontos cedo, antes que seu cérebro se acostume com o jeito local e pare de questionar.

Nem tudo que parece errado é errado. Muitas vezes ninguém teve tempo de consertar, mas às vezes existe um motivo real. Por isso a recomendação é sugerir aos poucos, entendendo onde pisa, em vez de sair consertando tudo de forma proativa logo na chegada.

## Segundo mês: confiabilidade acima de tudo

No segundo mês, a palavra que importa é confiabilidade. Pessoa confiável entrega no prazo ou, quando percebe que vai atrasar, comunica o atraso o mais cedo possível. Não é preciso ninguém cobrando; a tarefa delegada a você é responsabilidade sua até o fim.

Confiabilidade também é limpar bloqueadores rápido. Perdeu tempo preso num problema? Vá ativamente atrás de quem pode ajudar em vez de esperar. Resolver o que aparece, destravar o próprio caminho e comunicar riscos cedo são comportamentos que fazem a equipe passar a depender de você.

Ninguém vira referência em trinta dias, porque compreensão de code base, produto e contexto ainda está em construção. Confiabilidade é o objetivo diretor do mês, não uma promessa cumprida no primeiro dia sessenta e um.

## Terceiro mês: ownership e feedback

No terceiro mês, você passa a ser dono de algo. Se desde o primeiro mês você notou uma área simples e meio abandonada, e foi pegando tarefas relacionadas a ela, chegada a hora em que a equipe olha para você e diz: essa pessoa domina nosso serviço de pagamentos, nossa autenticação, nossa questão de tenants no banco.

Ownership significa garantir que sua parte funcione. Você identifica bugs quando surgem, propõe melhorias, participa da criação de tickets e implanta processos, testes e automatizações suficientes para dormir tranquilo se algo der errado na sua área.

É também o momento de pedir o máximo de feedback possível, e do tipo mais honesto. Diga às pessoas acima de você que não vai levar nada para o lado pessoal, que o objetivo é entender se está performando adequadamente. Em software, seis meses já dão para trocar de posição, mudar de equipe ou negociar aumento; não é o cenário comum, mas acontece, e os três meses são o ponto de virada para quem construiu as duas fases anteriores com calma.

## Perguntas frequentes

- **Devo entregar código já na primeira semana?** Só se for uma tarefa simples o suficiente para atravessar todo o processo sem risco. O objetivo da primeira semana é entender o fluxo de contribuição, não impressionar com volume de código.
- **O que fazer quando o onboarding da empresa está desatualizado?** Anote cada divergência entre a documentação e a realidade, corrija o que estiver ao alcance e compartilhe as correções. Isso já conta como uma contribuição útil no primeiro mês.
- **Como escolher a área para assumir no terceiro mês?** Procure algo simples, com demanda real e pouca atenção da equipe, ainda no primeiro mês. Vá pegando tarefas relacionadas até que dominar aquela área se torne reconhecível pelos colegas.
- **Júnior e sênior seguem o mesmo plano?** As proporções mudam bastante, porque um sênior entende contexto mais rápido e recebe expectativas maiores. A sequência de compreensão, confiabilidade e ownership continua válida nos dois casos.
- **Quando é razoável pedir aumento ou promoção?** Seis meses já podem bastar para uma mudança de posição, embora não seja o comum. O fim do terceiro mês, com feedback coletado e uma área sob sua responsabilidade, é o momento de avaliar.

## Transforme suas explicações em artigo

A ideia central aqui é que conhecimento só vira resultado quando está organizado na ordem certa: compreensão, confiabilidade, ownership. Com quem trabalha com tecnologia acontece o mesmo com vídeo: há explicações valiosas presas em gravações de YouTube que ninguém vai reassistir inteiras.

Se você tem aulas, análises de carreira ou lições parecidas com as deste texto em vídeos seus, o fluxo é direto: visite o [Skala Blog](https://skalablog.com), cole a URL do vídeo, gere a transcrição e receba um artigo estruturado pronto para revisar e publicar.

[Source video](https://www.youtube.com/watch?v=ueFQfd7X4ag)