9 min leitura • Guide 87 of 877
Criando Onboarding Efetivo para Novos Desenvolvedores
Onboarding de novos desenvolvedores pode levar semanas ou meses sem estrutura, deixando os recém-chegados confusos e os membros existentes constantemente interrompidos. Um programa de onboarding efetivo usa NoteVault do GitScrum para documentação, tarefas iniciais cuidadosamente projetadas, e expectativas claras para reduzir o tempo-para-primeiro-commit de semanas para dias. O objetivo não é apenas configuração técnica—é criar segurança psicológica e construir relacionamentos que habilitam produtividade a longo prazo.
Filosofia do Onboarding
O Que um Bom Onboarding Alcança
RESULTADOS ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ MEDINDO SUCESSO ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ ONBOARDING RUIM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Semana 1: "Leia o wiki" (desatualizado, fragmentado) ││
│ │ Semana 2: "Siga alguém" (interrompe trabalho deles) ││
│ │ Semana 3: "Pegue qualquer ticket" (sem contexto, falha) ││
│ │ Semana 4: Ainda fazendo perguntas básicas ││
│ │ Mês 2: Finalmente um pouco produtivo ││
│ │ Mês 3: Ainda descobrindo conhecimento tribal ││
│ │ ││
│ │ Resultado: Novo funcionário se sente incompetente ││
│ │ Time frustrado com interrupções ││
│ │ Primeira contribuição real: 4-6 semanas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ONBOARDING EFETIVO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Dia 1: Ambiente funciona, primeiro PR merged (fix docs) ││
│ │ Dia 2-3: Completar 2-3 "good first issues" ││
│ │ Semana 1: Pareado em feature real com mentor ││
│ │ Semana 2: Primeira feature própria end-to-end ││
│ │ Semana 3-4: Contribuindo a 50% capacidade ││
│ │ Mês 2: Membro completo, mentoreando próximo hire ││
│ │ ││
│ │ Resultado: Novo funcionário se sente capaz ││
│ │ Time ganha contribuidor rápido ││
│ │ Primeira contribuição real: 2-3 dias ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework 30-60-90 Dias
EXPECTATIVAS PROGRESSIVAS:
┌─────────────────────────────────────────────────────────────┐
│ FASES ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRIMEIROS 30 DIAS: APRENDIZADO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ambiente completamente configurado e funcionando ││
│ │ • Entender arquitetura codebase ││
│ │ • Completar 5-10 tarefas pequenas ││
│ │ • Conhecer todos membros do time 1:1 ││
│ │ • Saber quem perguntar o quê ││
│ │ ││
│ │ Métrica sucesso: Pode executar, testar, deployar ││
│ │ código independentemente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIAS 31-60: CONTRIBUIÇÃO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ser dono de 2-3 features médias end-to-end ││
│ │ • Participar em code reviews (dar + receber) ││
│ │ • Participar e contribuir em cerimônias sprint ││
│ │ • Começar a identificar melhorias ││
│ │ ││
│ │ Métrica sucesso: Completando features com nível ││
│ │ normal de suporte ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIAS 61-90: OWNERSHIP │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metas: ││
│ │ • Ser dono de uma área do codebase ││
│ │ • Tomar decisões arquiteturais (com orientação) ││
│ │ • Melhorar documentação baseado na experiência ││
│ │ • Ajudar a fazer onboard do próximo novo hire ││
│ │ ││
│ │ Métrica sucesso: Membro completo, quase independente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Documentação no NoteVault
Runbook Onboarding
DOCUMENTAÇÃO ESTRUTURADA:
┌─────────────────────────────────────────────────────────────┐
│ ESTRUTURA NOTEVAULT ONBOARDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📓 Guia Onboarding │
│ │ │
│ ├─ 📄 Boas-vindas & Overview Time │
│ │ • Quem somos, o que construímos │
│ │ • Roster time com fotos, papéis, contato │
│ │ • Normas comunicação (quando Slack vs email) │
│ │ • Calendário reuniões e expectativas │
│ │ │
│ ├─ 📄 Checklist Dia 1 │
│ │ ☐ Contas criadas (GitHub, GitScrum, Slack) │
│ │ ☐ Repo clonado e rodando localmente │
│ │ ☐ Primeiro PR merged (typo fix ou README update) │
│ │ ☐ Apresentado no canal Slack do time │
│ │ ☐ 1:1 agendado com manager │
│ │ ☐ Buddy atribuído e intro meeting feito │
│ │ │
│ ├─ 📄 Setup Desenvolvimento Local │
│ │ • Pré-requisitos (versão Node, Docker, etc.) │
│ │ • Instruções setup passo a passo │
│ │ • Erros comuns e soluções │
│ │ • Verificação: "Você terminou quando testes passam" │
│ │ │
│ ├─ 📄 Overview Arquitetura │
│ │ • Diagrama sistema com explicações componentes │
│ │ • Arquivos chave e o que fazem │
│ │ • Fluxo dados para operações comuns │
│ │ • Ponteiros "comece aqui" para cada área │
│ │ │
│ └─ 📄 FAQ & Conhecimento Tribal │
│ • "Por que fazemos X dessa forma?" │
│ • Decisões históricas e contexto │
│ • Gotchas comuns │
│ • Quem sabe o quê (mapa expertises) │
│ │
└─────────────────────────────────────────────────────────────┘
Tarefas Iniciais
Good First Issues
PROJETANDO TAREFAS INICIAIS:
┌─────────────────────────────────────────────────────────────┐
│ PRIMEIRAS TAREFAS IDEAIS NO GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ CARACTERÍSTICAS BOAS TAREFAS INICIAIS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Escopo pequeno (1-4 horas) ││
│ │ ✅ Critérios aceitação claros ││
│ │ ✅ Toca código produção real ││
│ │ ✅ Baixo risco se feito incorretamente ││
│ │ ✅ Introduz um novo conceito ││
│ │ ✅ Tem padrões existentes para seguir ││
│ │ ││
│ │ ❌ NÃO: "Refatore o sistema autenticação" ││
│ │ ❌ NÃO: "Arrume esse bug" (sem contexto) ││
│ │ ❌ NÃO: "Construa a nova feature" (muito escopo) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXEMPLO BOA PRIMEIRA TAREFA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarefa: Adicionar estado loading à lista usuários ││
│ │ ││
│ │ Labels: good-first-issue, onboarding ││
│ │ Estimativa: 2 pontos ││
│ │ ││
│ │ Descrição: ││
│ │ Atualmente lista usuários não mostra nada enquanto ││
│ │ carrega. Adicionar um loading spinner. ││
│ │ ││
│ │ Critérios aceitação: ││
│ │ ☐ Spinner mostra enquanto fetch usuários ││
│ │ ☐ Spinner coincide padrão existente em ProductList ││
│ │ ☐ Teste adicionado para estado loading ││
│ │ ││
│ │ Para começar: ││
│ │ 1. Ver como ProductList lida com loading (src/components)│
│ │ 2. UserList está em src/features/users/UserList.tsx ││
│ │ 3. Usar componente <Spinner /> de src/ui ││
│ │ ││
│ │ Perguntar ao @mentor se travado mais de 30 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Modelo Mentoria
Sistema Buddy
PAPEL BUDDY ONBOARDING:
┌─────────────────────────────────────────────────────────────┐
│ RESPONSABILIDADES BUDDY │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUEM: Membro experiente do time (não manager) │
│ │
│ DEVERES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PRIMEIRA SEMANA: ││
│ │ • Check-in diário 15-min ││
│ │ • Parear nas primeiras tarefas juntos ││
│ │ • Revisar todos PRs no mesmo dia ││
│ │ • Disponível para "perguntas bobas" (sem julgamento) ││
│ │ • Apresentar aos membros do time ││
│ │ ││
│ │ SEMANAS 2-4: ││
│ │ • 2-3 check-ins por semana ││
│ │ • Primeiro reviewer em PRs ││
│ │ • Parear em tarefas complexas ││
│ │ • Navegar questões organizacionais ││
│ │ ││
│ │ MÊS 2+: ││
│ │ • Check-in semanal ││
│ │ • Transição para relacionamento time normal ││
│ │ • Retrospectiva sobre experiência onboarding ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALOCAÇÃO TEMPO BUDDY: │
│ Semana 1: ~4 horas (20% da semana) │
│ Semana 2-4: ~2 horas (10% da semana) │
│ Mês 2: ~1 hora (5% da semana) │
│ │
│ Isso é TRABALHO REAL. Tarefas buddy reduzidas conforme. │
│ │
└─────────────────────────────────────────────────────────────┘
Segurança Psicológica
Criando Ambiente Seguro
PSICOLOGIA NOVO HIRE:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUINDO CONFIANÇA │
├─────────────────────────────────────────────────────────────┤
│ │
│ MEDOS COMUNS NOVO HIRE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Vou fazer pergunta boba e parecer incompetente" ││
│ │ "Todo mundo parece saber tudo" ││
│ │ "Eu já deveria ter descoberto isso" ││
│ │ "Meu código não é tão bom quanto o deles" ││
│ │ "Eles erraram me contratando" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMPORTAMENTOS QUE CONSTROEM SEGURANÇA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "Ótima pergunta, não sabia isso por meses" ││
│ │ ✅ "Deixa eu te mostrar como eu abordaria isso" ││
│ │ ✅ "Cometi o mesmo erro quando comecei" ││
│ │ ✅ "Aqui está o que NÃO está documentado..." ││
│ │ ✅ "Sua perspectiva fresca encontrou issue real" ││
│ │ ││
│ │ ❌ "Isso está nos docs" (sem ajudar a encontrar) ││
│ │ ❌ "Você já deveria saber isso" ││
│ │ ❌ Suspirar quando fazem perguntas ││
│ │ ❌ Criticar PR sem explicar por quê ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NORMAS EXPLÍCITAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Dizer aos novos hires Dia 1: ││
│ │ ││
│ │ "Você vai fazer perguntas que achamos óbvias. ││
│ │ Isso é ESPERADO. Significa que docs incompletos. ││
│ │ Sua confusão nos ajuda a melhorar. ││
│ │ ││
│ │ Se travado 30 minutos, pergunte. Não espere. ││
│ │ Queremos interrupções na semana 1. ││
│ │ É assim que você aprende mais rápido." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘