Plano 30-60-90 para desenvolvedores: template prático, métricas e apresentação

1) Problema real que resolve

Equipes e gestores esperam que um desenvolvedor júnior/ pleno recém-contratado entregue valor rapidamente sem perder tempo com expectativas vagas. O plano 30-60-90 traduz objetivos intangíveis ("se integre", "entregue valor") em entregáveis mensuráveis e checkpoints realistas.

Sem um plano claro, o profissional de 1-3 anos tende a fazer work that looks busy enquanto não conecta suas tarefas aos objetivos do time. O impacto disso inclui onboarding lento, desalinhamento com stakeholders e avaliações de performance inconsistentes.

O plano 30-60-90 serve para três coisas práticas: alinhar expectativas, priorizar trabalho e prover métricas que suportam conversas de carreira e avaliações. Ele não é um documento apenas para HR — é uma ferramenta de engenharia para controle de escopo e feedback.

Use o plano em entrevistas, no primeiro dia e em ramp-ups de projetos críticos. Ele funciona como contrato mental entre você e o time: o que você fará, como medirá sucesso e quais riscos mitigará.

Por que é especialmente útil para devs com 1-3 anos?

Nessa fase você já sabe codar, mas ainda aprende contexto do produto, arquitetura e processos. Um plano 30-60-90 ajuda a transformar habilidades técnicas em entregas relevantes: bug fixes com impacto, melhorias de infraestrutura que reduzam custo, features pequenas que liberam valor.

Stakeholders que se beneficiam

• Você — clareza de prioridades e critérios de sucesso.
• Tech lead / gerente — visibilidade e pontos de checagem.
• Product manager — entendimento do que será entregue e quando.
• Mentor — base para feedback estruturado.

Se o objetivo é ser útil rápido, o plano 30-60-90 é o atalho: menos suposições, mais entregas com impacto mensurável.

2) Abordagem ingênua vs abordagem otimizada

Abordagem ingênua: escrever um documento genérico com tarefas vagas, como "estudar o código" ou "entregar uma feature". Esses planos falham por não definirem critérios de sucesso, dependências e stakeholders. Resultado: avaliações subjetivas e frustração mútua.

Abordagem otimizada: plano dividido em marcos concretos (30 / 60 / 90 dias), cada um com objetivos, métricas, entregáveis, dependências e riscos. Combine atividades técnicas com atividades de integração humana (reuniões chave, revisões de arquitetura, documentação). Garanta checkpoints rápidos (1, 2 e 4 semanas) para feedback.

Componentes de um plano otimizado

1. Objetivo do período (verificável): o que será diferente ao final.
2. Entregáveis concretos: PRs, tickets fechados, documentação, testes end-to-end.
3. Métricas de sucesso: redução de tempo de build, cobertura de testes, lead time de PR.
4. Riscos e dependências: quem trava, qual infra precisa.
5. Plano de comunicação: reuniões de alinhamento e demos.

Uma prática eficaz é mapear cada tarefa para um critério SMART (específico, mensurável, atingível, relevante, temporal). Isso transforma intenção em evidência.

Quando simplificar em vez de detalhar demais

Nem todo plano precisa ser burocrático. Se a empresa tem processos maduros (onboarding, rota de mentoria), foque nos pontos que realmente mudam: primeiro bug crítico, integração com CI, ou entrega de feature x. A granularidade ideal é aquela que sustenta conversas objetivas a cada checkpoint.

3) Implementação com código real

Apresentei a teoria; agora exemplos práticos. Três blocos de código: (A) template Markdown do plano 30-60-90 pronto para usar em entrevistas ou PRs de onboarding; (B) script Node.js que combina um JSON com o template e gera Markdown/PDF, calculando métricas simples; (C) script Python para extrair métricas básicas do Git/PR para alimentar o plano com dados reais.

Contexto do código A: Template Markdown

O template abaixo é para copiar/colar no seu README pessoal, PR de onboarding ou para anexar na entrevista. Contém campos para métricas, entregáveis e riscos.

# Plano 30-60-90 - {{nome}} (cargo: {{cargo}})

## Resumo
- Objetivo geral: {{objetivo_geral}}
- Stakeholders: {{stakeholders}}

## 0-30 dias: Conhecer e contribuir
- Objetivo: Entender arquitetura e corrigir 1-2 bugs com impacto
- Entregáveis:
  - PR #1: correção de bug crítico (link)
  - Documento: mapa de arquitetura básico (arquivo: docs/arquitetura.md)
- Métricas:
  - Bugs fechados: >=2
  - Tempo médio de revisão: <=48h
- Riscos/dependências: acesso ao repositório, credenciais de staging

## 31-60 dias: Entregar valor incremental
- Objetivo: Implementar feature pequena que reduza atrito
- Entregáveis:
  - Feature: endpoint /api/x com tests e CI
  - Automação: job de testes no pipeline
- Métricas:
  - Cobertura de testes na feature: >=80%
  - Lead time PR: <72h

## 61-90 dias: Assumir dono técnico de uma área
- Objetivo: Liderar a proposta de melhoria com métricas de custo/benefício
- Entregáveis:
  - RFC: proposta de melhoria (docs/rfc/feature-x.md)
  - Rollout plan e rollback
- Métricas:
  - Redução de tempo de deploy: -20%
  - Redução de incidentes na área: -30%

## Checkpoints e feedback
- Semana 1: alinhamento com tech lead
- Semana 2: revisão do primeiro PR
- Semana 4: demo do progresso

## Notas finais
- Comunicação: atualizações semanais no status meeting
- Expectativa de mentor: 2h semanais

Depois: preencha os placeholders quando usar. O template é curto, objetivo e foca em entregáveis verificáveis em vez de atividades vagas.

Contexto do código B: Node.js gerador de plano com métricas

Esse script pega um JSON com sua meta e algumas métricas iniciais (ex: PRs abertos) e gera o Markdown do plano preenchido. Útil para automatizar o envio do plano ao repo do time.

/* gera-plano.js
  Usa: node gera-plano.js dados.json > plano.md
  Gera o markdown preenchido e calcula métricas simples.
*/
const fs = require('fs');
const tpl = fs.readFileSync('template.md', 'utf8');
const data = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));

function render(template, ctx) {
  return template.replace(/{{\s*(\w+)\s*}}/g, (_, key) => ctx[key] || '');
}

// calcula métricas compostas
data.metrica_lead_time = data.media_review_hours ? Math.round(data.media_review_hours) + 'h' : 'N/A';

const out = render(tpl, {
  nome: data.nome,
  cargo: data.cargo,
  objetivo_geral: data.objetivo_geral,
  stakeholders: data.stakeholders.join(', '),
});

console.log(out);

Depois de rodar: o script imprime o Markdown preenchido. Integre com CI (ex: gerar plano e abrir um issue ou MR no repo do time).

Contexto do código C: Python para extrair métricas de Git/PR

Esse script consulta a API do GitHub (ou GitLab) para calcular métricas simples: número de PRs abertos/fechados nos últimos 30 dias, tempo médio de revisão e número de commits. Use tokens e filtre por autor.

# extrai_metricas.py
# Usa: python3 extrai_metricas.py token repo autor
# Retorna JSON com pr_abertos, pr_fechados, media_review_horas
import sys, requests, datetime, os

token = sys.argv[1]
repo = sys.argv[2]
autor = sys.argv[3]
headers = {'Authorization': f'token {token}', 'Accept': 'application/vnd.github.v3+json'}
base = f'https://api.github.com/repos/{repo}/pulls'
params = {'state':'all', 'per_page':100}
res = requests.get(base, headers=headers, params=params)
res.raise_for_status()
prs = [p for p in res.json() if p['user']['login']==autor]

cut = datetime.datetime.utcnow() - datetime.timedelta(days=30)
recent = []
for p in prs:
    created = datetime.datetime.strptime(p['created_at'], '%Y-%m-%dT%H:%M:%SZ')
    if created > cut:
        recent.append(p)

opened = sum(1 for p in recent if p['state']=='open')
closed = sum(1 for p in recent if p['state']=='closed')

# tempo medio de review simplificado
reviews = []
for p in recent:
    if p['state']=='closed' and p['merged_at']:
        created = datetime.datetime.strptime(p['created_at'], '%Y-%m-%dT%H:%M:%SZ')
        merged = datetime.datetime.strptime(p['merged_at'], '%Y-%m-%dT%H:%M:%SZ')
        delta = merged - created
        reviews.append(delta.total_seconds()/3600)

media_review = sum(reviews)/len(reviews) if reviews else 0
print({'pr_abertos': opened, 'pr_fechados': closed, 'media_review_horas': round(media_review,2)})

Depois: pegue esse JSON e alimente o script Node.js para preencher métricas reais no seu plano. Isso transforma suposições em dados durante a entrevista ou ramp-up.

4) Testes e validação

Testar um plano 30-60-90 é diferente de testar código, mas é igualmente sistemático. Valide o plano em ciclos curtos com stakeholders: checkpoints semanais que possuem critérios de aceitação.

Os testes aqui são conversas estruturadas e evidências objetivas:

• Prova de entrega: PRs merged, issues fechadas, métricas comparadas.
• Prova de integração: feedback do mentor, participação em reuniões técnicas.
• Prova de impacto: redução mensurável (erros, tempo de deploy, latência) ligada ao seu trabalho.

Checklist de validação

1. Cada entrega tem um ticket ou PR referenciando o plano.
2. Reuniões de revisão registradas com tópicos e decisões.
3. Métricas antes/depois registradas e vinculadas às entregas.

Utilize dashboards simples (Grafana, planilhas) para mostrar impacto. Métricas visuais reduzem discussão subjetiva e aceleram confiança entre você e o time.

Erros comuns na validação

Muitas validações falham por usar métricas pobres (ex: contagem de commits). Use métricas que reflitam valor: lead time, taxa de incidentes, tempo médio de recuperação (MTTR) e satisfação do usuário interno/externo.

Dica: um bom teste do seu plano é responder em 5 minutos como cada entrega mudou um KPI do time.

5) Considerações de produção

Preparar um plano 30-60-90 para produção significa considerar segurança, dependências infra e rollback. Se sua entrega envolve DB schema changes, feature flags ou infra, inclua planos de mitigação e KPIs de monitoramento.

Checklist de produção para entregas do plano:

• Feature flag disponível para rollout gradual.
• Métricas de observabilidade adicionadas (logs estruturados, métricas customizadas).
• Plano de rollback documentado e testado em staging.
• Automação de deploy para reduzir erro humano.

Governança e segurança

Não ignore governança: se você mexer com dados sensíveis, peça revisão de segurança e checklist de compliance. Pequenas equipes frequentemente subestimam esse ponto e sofrem retrabalho.

Escalando o plano para áreas maiores

Se você precisa coordenar com outros times, transforme as entregas em dependências com responsáveis claros. Use um RFC (Request for Comments) curto para decidir contratos de API, SLAs e owners. Assim você não transforma o plano em promessas individuais sem suporte do ecossistema.

Erros comuns, armadilhas e dicas práticas

Lista dos erros que vejo todo dia em devs com 1-3 anos:

1. Plano vagamente positivo: "melhorar sistema" sem critérios.
2. Número de tarefas como proxy de sucesso (mais tickets != mais impacto).
3. Ignorar comunicação: não atualizar stakeholders entre checkpoints.
4. Subestimar dependências infra (waiting on ops, DB migrations).

Dicas práticas para evitar armadilhas:

• Mapeie dependências e peça nomes específicos (quem bloqueia, qual ticket).
• Automatize coleta de métricas com scripts (ex: extrai_metricas.py) e anexe ao plano.
• Documente decisões técnicas em RFCs, mesmo que curtos (1 página).
• Use feature flags para garantir entrega segura.

Evite metas internas vagas. Se o objetivo é "melhorar performance", transforme em objetivo mensurável: "reduzir o p50 de latência do endpoint /search de 120ms para 80ms".

Conclusão e próximos passos práticos

Um bom plano 30-60-90 transforma incerteza em entregas verificáveis. Para devs com 1-3 anos ele atua como contrato com o time: define o que será entregue, como será medido e quais riscos existem. Use o template Markdown, automatize coleta de métricas e valide ao longo de checkpoints curtos.

Próximos passos concretos:

1. Copie o template e preencha com objetivos SMART para sua próxima entrevista ou primeiro dia.
2. Rode o script Python para coletar métricas dos últimos 30 dias e gere insights reais sobre sua produtividade.
3. Integre o Markdown gerado ao repo do time (issue/PR) e agende checkpoints semanais com seu mentor.

O impacto real vem da disciplina: atualizar o plano, apontar métricas e usar evidências em vez de narrativas. Se você trouxer dados e entregáveis, a conversa sobre promoção, desempenho e confiança técnica se torna objetiva e rápida.

Este artigo entregou: problema, comparação de abordagens, templates reais com scripts, validação prática e checklist de produção. Aplique, meça e ajuste: isso é engenharia de carreira.