pdi para dev junior: como montar um plano que não vira teatro

PDI para dev junior costuma nascer de um jeito estranho. Alguém fala em “plano de desenvolvimento individual”, abre uma planilha, coloca três competências vagas, marca prazo para daqui a seis meses e pronto: o documento existe, mas a carreira continua no escuro.

Para quem está começando em tech, isso é perigoso. Junior já vive com sensação de avaliação permanente. Daily parece prova oral. Code review parece boletim. 1:1 parece reunião para descobrir se você ainda serve. Se o PDI vira mais um formulário corporativo, ele não ajuda. Só aumenta a ansiedade.

Um bom PDI faz o contrário: reduz ruído. Ele transforma feedback solto em foco de aprendizado, combina que tipo de evidência mostra evolução e cria um jeito simples de conversar com gestor ou pessoa mentora sem depender de adivinhação.

Este guia é para montar um PDI realista de dev junior, estágio em tecnologia ou primeira vaga de produto/dados/QA/suporte técnico. Não é para prometer virar pleno em três meses. É para sair de “preciso melhorar” para “vou trabalhar nesses dois pontos, com essas entregas, até essa data”.

Se você acabou de entrar, leia também o roteiro de primeira semana como dev junior e o plano de primeiros 30 dias como dev junior. O PDI funciona melhor quando nasce depois de alguma vivência real no time, não antes de você entender o repositório, os rituais e o jeito de pedir ajuda.

PDI não é lista de cursos

O erro mais comum é montar PDI como catálogo de estudos:

- Fazer curso de React
- Estudar Docker
- Aprender testes
- Melhorar inglês
- Ver arquitetura limpa

Nada disso é errado. O problema é que lista de curso não prova evolução no trabalho. Você pode terminar cinco aulas de Docker e continuar travando na hora de subir o ambiente local. Pode assistir conteúdo de testes e ainda abrir PR sem cobrir o fluxo que mudou.

PDI bom conecta estudo com comportamento observável.

Ruim:

Aprender testes automatizados.

Melhor:

Em 6 semanas, conseguir alterar uma regra simples do backend incluindo pelo menos um teste de caso feliz e um teste de erro, pedindo review antecipado quando ficar em dúvida sobre escopo.

Percebe a diferença? A segunda versão tem contexto, prazo, tipo de entrega e comportamento esperado. O gestor consegue acompanhar. Você também.

escolha no máximo dois focos por ciclo

Junior quer melhorar tudo ao mesmo tempo: código, comunicação, Git, teste, produto, inglês, cloud, design pattern, estimativa, entrevista, salário, portfólio. Essa vontade é compreensível, mas vira ruído rápido.

Um ciclo de PDI precisa ter no máximo dois focos principais. Três já é muito. Cinco é fantasia.

Exemplos de foco bom:

• abrir PRs menores e mais fáceis de revisar;
• escrever updates claros em daily e Slack;
• ganhar autonomia em bugs simples;
• entender melhor regras de produto antes de codar;
• melhorar testes em mudanças pequenas;
• reduzir retrabalho em code review;
• organizar candidaturas e entrevistas se você ainda está buscando vaga.

Escolha o foco a partir de evidência, não de vergonha. Se três PRs seguidos voltaram por falta de teste, testes entram no PDI. Se você trava dias antes de pedir ajuda, comunicação entra. Se seu gestor sempre corrige o entendimento do ticket depois que você já implementou, descoberta de contexto entra.

O guia de code review como dev junior ajuda muito nesse diagnóstico, porque review mostra padrões que a gente não enxerga sozinho. O roteiro de 1:1 como dev junior também é útil para transformar sensação em conversa objetiva.

transforme feedback em meta pequena

Feedback ruim costuma vir assim:

Você precisa ser mais autônomo.

Isso não é meta. É neblina.

Autonomia pode significar várias coisas:

• entender o ticket antes de começar;
• quebrar uma tarefa grande em passos menores;
• avisar bloqueio cedo;
• procurar documentação antes de chamar alguém;
• testar o que mudou sem depender do revisor;
• propor uma solução simples em vez de perguntar “o que faço?”.

Quando receber feedback genérico, traduza com pergunta:

Quando você fala em autonomia, o principal hoje é eu pedir ajuda mais cedo, quebrar melhor as tarefas ou chegar com uma proposta inicial antes de chamar alguém?

Depois transforme em meta pequena:

Nas próximas 4 semanas, antes de começar cada ticket médio, vou escrever um plano de 3 a 5 linhas com regra entendida, arquivos prováveis e dúvida principal. Vou validar esse plano com meu par técnico quando houver incerteza.

Isso é PDI. Não porque parece sofisticado, mas porque muda um comportamento real.

combine evidências antes do prazo final

PDI sem evidência vira opinião no dia da avaliação. Você acha que evoluiu. O gestor acha que ainda não. Ninguém guardou exemplos. A conversa fica emocional.

Combine evidências desde o começo:

• links de PRs em que você aplicou o ponto combinado;
• antes/depois de uma documentação que você melhorou;
• exemplo de update de daily mais claro;
• bug simples resolvido com menos intervenção;
• feedback de revisor dizendo que o PR ficou mais fácil de revisar;
• resumo mensal com aprendizados, bloqueios e próximos passos.

Não precisa montar dossiê. Precisa guardar sinais.

Um modelo simples:

Foco: reduzir retrabalho em code review
Prazo: 6 semanas
Evidências:
- 3 PRs com descrição clara de contexto, teste feito e risco
- comentários repetidos agrupados e resolvidos sem discussão longa
- 1 checklist pessoal antes de pedir review
Checkpoint: toda 1:1 de sexta

Se você já está nos primeiros 90 dias como dev junior, esse tipo de evidência vale mais que discurso. Mostra maturidade sem tentar se vender como pleno.

separe meta técnica de meta de rotina

Nem todo PDI precisa ser sobre framework. Às vezes o maior gargalo de junior não é saber menos tecnologia. É trabalhar de um jeito que esconde problema.

Meta técnica:

Implementar mudanças pequenas em endpoint existente com teste automatizado e validação manual documentada.

Meta de rotina:

Atualizar o time até 11h quando uma tarefa ficar bloqueada por mais de 45 minutos, explicando o que tentei, onde parei e qual ajuda preciso.

As duas importam. Em remoto, a segunda pode ser decisiva. Junior que desaparece com bloqueio parece menos confiável, mesmo quando é esforçado. Se esse é seu caso, leia o guia de rotina remota para junior junto com este texto.

Para quem ainda está procurando o primeiro emprego, a lógica também funciona. Seu PDI pode ser externo:

Em 30 dias, revisar CV, LinkedIn e portfólio para uma direção principal de vaga, aplicar para 25 oportunidades filtradas e registrar resposta, etapa e ajuste necessário.

Isso conversa com CV junior, LinkedIn para dev junior e planilha de candidaturas junior. O PDI não depende de estar empregado. Ele depende de ter foco e acompanhamento.

use cursos como apoio, não como objetivo final

Curso entra no PDI quando serve a uma entrega.

Em vez de:

Concluir curso de SQL.

Use:

Estudar SQL básico e aplicar em uma melhoria real: ajustar uma consulta simples, explicar o filtro usado e validar o resultado com dados de teste.

Se seu foco for Python, por exemplo, faz mais sentido acompanhar material técnico em português, como tutoriais e guias em sites de stack específica tipo Python Brasil, e depois aplicar esse estudo em projeto, teste técnico ou tarefa real. Só assistir aula não muda a percepção do time.

O mesmo vale para inglês. “Melhorar inglês” é grande demais. Melhor:

Durante 8 semanas, ler a documentação oficial usada no projeto por 20 minutos em 3 dias da semana e trazer uma dúvida técnica por semana para validar entendimento.

Se inglês já virou barreira para vaga, o guia de inglês para tech ajuda a priorizar leitura, entrevista e documentação sem cair na promessa de fluência mágica.

faça checkpoint curto toda semana

PDI que só é visto no fim do trimestre chega tarde demais. O ideal é checkpoint curto, repetido e sem cerimônia.

Perguntas para 1:1:

• Esta meta ainda é a mais importante?
• Qual evidência apareceu esta semana?
• Onde eu ainda estou repetindo o erro antigo?
• O escopo está realista para meu nível e carga?
• O que devo tentar diferente na próxima semana?

Não transforme o checkpoint em apresentação. Cinco minutos bastam. O importante é ajustar rota cedo.

Um bom resumo semanal pode ser assim:

PDI - semana 2
Foco: PR menor e mais claro
O que fiz: quebrei a correção do formulário em 2 PRs; o primeiro teve 3 comentários pequenos.
Evidência: PR #184 e checklist antes do review.
Bloqueio: ainda demoro para decidir o que fica fora do escopo.
Próximo passo: validar recorte do ticket antes de codar quando houver regra ambígua.

Isso dá material para o gestor ajudar. Também impede que você dependa de memória emocional no fim do ciclo.

cuidado com PDI usado para empurrar escopo de pleno

Nem todo PDI é justo. Às vezes a empresa usa o nome bonito para cobrar nível acima sem suporte.

Sinais de alerta:

• metas sem pessoa mentora, sem review e sem tempo para aprender;
• cobrança de liderar projeto crítico sozinho;
• expectativa de arquitetura, plantão, produto e entrega como pleno;
• feedback agressivo disfarçado de desenvolvimento;
• prazo impossível sem reduzir outras demandas;
• promessa vaga de promoção sem critério.

PDI de junior precisa ter desafio, mas também proteção. Se o plano exige que você vire pleno para provar que merece continuar junior, tem algo errado.

Nesse caso, leve a conversa para critérios:

Quero trabalhar esse ponto, mas preciso entender o nível esperado para junior. Qual parte devo conduzir sozinho, qual parte terá acompanhamento e como vamos avaliar se a entrega ficou adequada?

Se a resposta for sempre confusa, talvez o problema não seja seu esforço. O texto sobre sair de estágio ruim em tech ajuda a separar ambiente exigente de ambiente sem estrutura.

modelo simples de PDI para copiar

Use este formato enxuto:

PDI - ciclo de 6 semanas

Contexto:
Recebi feedback de que meus PRs estão grandes e geram retrabalho no review.

Foco 1:
Abrir PRs menores e mais claros.

Comportamento esperado:
Antes de pedir review, vou preencher contexto, mudança feita, como testei e risco. Quando o ticket crescer, vou propor quebra em partes.

Evidências:
- 3 PRs com descrição completa
- menos comentários repetidos sobre escopo
- feedback do revisor na semana 6

Apoio necessário:
Validar recorte de tarefa em 1:1 ou pareamento rápido quando houver dúvida.

Checkpoint:
Toda sexta, 5 minutos na 1:1.

Esse modelo é pequeno de propósito. Se não cabe em uma página, provavelmente está grande demais para um ciclo junior.

PDI bom deixa você menos perdido

O objetivo do PDI não é parecer profissional no documento. É diminuir a distância entre esforço e evolução real.

Quando o plano é bom, você sabe o que observar na semana. O gestor sabe como ajudar. A pessoa revisora entende qual comportamento você está tentando mudar. A próxima avaliação não depende só de impressão.

Para dev junior, isso vale muito. Você ainda vai errar. Vai receber comentário em PR. Vai subestimar tarefa. Vai pedir ajuda tarde algumas vezes. PDI não elimina essa fase. Ele dá trilho para atravessar sem transformar cada erro em crise de identidade.

Comece pequeno: um foco técnico, um foco de rotina, evidências simples e checkpoint semanal. Se isso acontecer por seis semanas, você já vai estar mais longe do que a maioria dos planos bonitos que morrem na pasta do RH.

E quando for buscar a próxima oportunidade, use esse mesmo raciocínio para filtrar vaga. Vaga boa para junior fala de acompanhamento, review, escopo proporcional e aprendizado real. Vaga que só promete “crescimento acelerado” sem explicar suporte pode ser só pressa com outro nome. Antes de aplicar, passe pelas vagas junior e estágio em tech com esse olhar.