Um plano de desenvolvimento individual (PDI) é um acordo curto e escrito sobre a forma como uma pessoa vai crescer nos próximos meses: em que competências vai trabalhar, o que vai fazer concretamente e até quando. Parece burocracia e, em muitas empresas, é — um formulário preenchido uma vez por ano e nunca mais aberto. Não tem de ser assim.
Este guia mostra como escrever um PDI que se cumpre: de onde vêm os objetivos, o que torna uma ação concreta, um modelo que pode copiar e exemplos para funções de apoio ao cliente, vendas, engenharia e gestão.
O que é um plano de desenvolvimento individual, e o que não é
Um PDI útil tem três elementos:
- Uma direção. Normalmente o nível seguinte na escada de carreira da pessoa; por vezes, a passagem para outro percurso ou outra função.
- Uma ou duas competências em foco. As lacunas que separam a pessoa dessa direção.
- Algumas ações concretas com prazo — a parte que realmente muda alguma coisa.
Não é um plano de melhoria de desempenho. Esse é uma resposta formal a alguém que fica aquém da sua função atual. Um PDI é para quem está a ir bem e quer fazer mais. Se os dois se confundem, as pessoas começam a temer o PDI.
Também não é um pedido de orçamento para formação. Os cursos podem fazer parte de um plano, mas a maior parte do crescimento vem do próprio trabalho: pegar num problema mais difícil, liderar algo pela primeira vez, ensinar outras pessoas.
Parta da lacuna, não de uma lista de desejos
A melhor fonte para um PDI é um check-in: o colaborador avaliou-se face às competências que a sua função espera, o gestor fez o mesmo, e ambos viram onde as avaliações divergem ou ficam abaixo do nível. Essas lacunas são a matéria-prima.
Escolha uma ou duas. Para decidir, pergunte:
- Que lacuna pesa mais para o nível seguinte? Leia as expectativas do nível seguinte e encontre o maior salto.
- Qual delas interessa à pessoa? Um plano que não interessa à pessoa não se cumpre.
- Há trabalho a caminho que ajude? Uma lacuna que o trabalho do próximo trimestre pode fechar é a mais fácil de atacar.
Sem uma escada de carreira, também é possível escrever um PDI, mas os objetivos tendem a derivar para o que soa bem — «ser mais estratégico» — em vez de para aquilo de que a função precisa. Expectativas claras por nível tornam o plano muito mais fácil de escrever.
Como escrever uma ação que se cumpre
A maioria dos PDI falha neste passo. «Melhorar a comunicação» é um desejo, não uma ação. Uma boa ação responde a cinco perguntas:
- O que vai fazer, exatamente? Um verbo e um resultado.
- Que competência desenvolve? Uma competência da função, ou um objetivo mais amplo se não encaixar em nenhuma.
- Como vamos saber que está feita? Uma meta final que ambos os lados conseguem ver.
- Até quando? Uma data real, entre algumas semanas e três meses.
- Que apoio é preciso? Tempo, acessos, um mentor, orçamento, uma apresentação a alguém.
Compare:
| Vago | Concreto |
|---|---|
| Falar melhor em público | Apresentar o relatório trimestral do apoio ao cliente na reunião geral de dezembro; ensaiar antes uma vez com o team lead |
| Saber mais sobre o produto | Acompanhar duas chamadas de onboarding com a equipa de soluções até ao fim do mês e registar três perguntas que os clientes fazem |
| Assumir mais responsabilidade | Ser responsável pela checklist das duas próximas versões, incluindo a decisão de avançar ou não |
Varie o tipo de ação. Um bom equilíbrio é sobretudo fazer (um desafio acima do habitual em trabalho real), alguma aprendizagem com outros (acompanhar colegas, mentoria, feedback) e um pouco de aprendizagem formal (um curso ou um livro) — e não o contrário. Um plano feito só de cursos produz certificados, não comportamentos novos.
Um modelo de PDI
Copie-o para a ferramenta que usar. Cabe num só ecrã, e é essa a ideia.
Pessoa / função / nível: nome — função — nível atual
Direção: por exemplo, «pronto para o nível 3 dentro de 12 meses» ou «passar para o percurso de gestão»
Competências em foco: uma ou duas, tiradas das expectativas da função
| Ação | Competência | Concluída quando | Prazo | Apoio necessário |
|---|---|---|---|---|
| O que vai fazer | Nome da competência | Meta final visível | Data | Tempo, mentor, etc. |
Revisto em: o próximo check-in, data
Mantenha duas a quatro ações em aberto de cada vez. Quando uma terminar, acrescente a seguinte em vez de escrever dez logo de início.
Exemplos para quatro funções
Especialista de apoio ao cliente, nível 2 3
Direção: tornar-se a pessoa de referência numa área complexa. Competências em foco: conhecimento técnico e de produto, operações de apoio. As expectativas de cada nível estão no modelo de apoio ao cliente.
| Ação | Competência | Concluída quando | Prazo |
|---|---|---|---|
| Escrever notas internas sobre os cinco problemas de faturação mais comuns | Conhecimento técnico e de produto | Notas publicadas; dois colegas já as usaram | 6 semanas |
| Dar à equipa uma sessão de 30 minutos sobre a configuração da faturação | Conhecimento técnico e de produto | Sessão realizada, perguntas recolhidas | 10 semanas |
| Propor uma alteração ao processo de escalamento, com base nos tickets do último mês | Operações de apoio | Proposta discutida com o coordenador de apoio | 12 semanas |
Account executive, de intermédio a sénior
Direção: conduzir sozinho negócios maiores, com várias partes interessadas. Competências em foco: descoberta e qualificação, gestão de negócios e fecho. Veja o modelo de account executive.
| Ação | Competência | Concluída quando | Prazo |
|---|---|---|---|
| Conduzir a fase de descoberta em dois negócios com três ou mais interlocutores, com o gestor a observar | Descoberta e qualificação | Duas chamadas conduzidas, feedback escrito após cada uma | 8 semanas |
| Escrever um plano de ação conjunto para cada negócio ativo acima de uma certa dimensão | Gestão de negócios e fecho | Planos partilhados com o cliente e mantidos atualizados | Contínuo, rever em 12 semanas |
| Pedir feedback escrito a dois colegas que participaram nessas chamadas | Descoberta e qualificação | Feedback recebido e discutido no check-in | 10 semanas |
Engenheiro de software, nível 2 3
Direção: engenheiro sénior dentro de um ano. Competências em foco: design de sistemas, mentoria e desenvolvimento da equipa. Veja o modelo de engenheiro de software.
| Ação | Competência | Concluída quando | Prazo |
|---|---|---|---|
| Escrever o documento de design da exportação de relatórios e conduzir a sua revisão | Design de sistemas | Documento revisto por dois engenheiros seniores e aprovado | 6 semanas |
| Trabalhar em par todas as semanas com o engenheiro mais recente da equipa | Mentoria e desenvolvimento da equipa | Oito sessões realizadas; o novo engenheiro entrega sozinho a primeira funcionalidade | 10 semanas |
| Rever pull requests fora da sua área pelo menos duas vezes por semana | Design de sistemas | Hábito mantido durante um trimestre inteiro | 12 semanas |
Engineering manager recém-nomeado, primeiros seis meses
Direção: liderar a equipa sem voltar ao trabalho individual. Competências em foco: desenvolvimento de pessoas, entrega e execução. Veja o modelo de engineering manager.
| Ação | Competência | Concluída quando | Prazo |
|---|---|---|---|
| Fazer um check-in de carreira com cada pessoa que lhe reporta diretamente | Desenvolvimento de pessoas | Todos os check-ins concluídos, cada um com ações acordadas | 8 semanas |
| Passar a escala de prevenção e a checklist de lançamento a duas pessoas da equipa | Entrega e execução | Ambas as conduzem sem si durante um mês inteiro | 12 semanas |
| Reunir-se de duas em duas semanas com um gestor mais experiente | Desenvolvimento de pessoas | Seis reuniões realizadas; uma mudança na forma como conduz as reuniões 1:1 | 12 semanas |
Repare no que os exemplos têm em comum: quase todas as ações são trabalho real que a pessoa faria em parte de qualquer forma, tornado intencional e com uma meta final.
Manter o plano vivo
Um plano escrito e arquivado fica esquecido ao fim de um mês. Três hábitos mantêm-no vivo:
- Reveja-o em cada check-in. Comece cada check-in pelas ações em aberto: o que ficou feito, o que está parado, o que já não faz sentido. Cancele as ações que perderam a razão de ser — isso é honestidade, não fracasso.
- Registe o progresso à medida que acontece. Uma nota curta quando algo avança — «primeira sessão realizada, 6 participantes» — é melhor do que tentar lembrar-se três meses depois, e torna-se prova numa proposta de promoção.
- Deixe o colaborador fechar a ação. Quem faz o trabalho diz quando está concluído, com uma nota sobre como correu. O gestor pode discordar e reabri-la, mas não deve marcar tarefas como feitas em nome de outra pessoa.
Os prazos só funcionam se alguém der por eles. Se o seu plano vive num documento, ponha as datas num calendário. No LadderKit, cada ponto do PDI é uma ação de desenvolvimento com prazo, uma ligação opcional a uma competência da função da pessoa, um fio de notas em que ambos os lados escrevem e lembretes antes e depois do prazo; só o colaborador a pode marcar como concluída.
Erros comuns
- Objetivos a mais. Duas competências em foco, duas a quatro ações. Tudo o resto espera.
- Ações sem meta final. Se não se consegue saber se está feita, nunca estará feita.
- Só cursos. A aprendizagem acontece no trabalho; os cursos apoiam-na.
- Escrito só pelo gestor. A pessoa tem de o reconhecer como o seu plano.
- Desligado da função. Objetivos que não apontam para as expectativas do nível seguinte não ajudam na promoção, e as pessoas percebem isso.
- Nunca revisto. Um PDI que não é discutido no check-in seguinte foi uma mera formalidade.