Checklist de Onboarding de Desenvolvedores

Uma progressão cronológica do clone ao primeiro PR mesclado para engenheiros Python novos (ou novos neste sistema) - ordenado antes da chegada, dia 1, semana 1 e contínuo.

Como Usar Este Checklist

• Percorra os itens em ordem cronológica - itens anteriores desbloqueiam os posteriores.
• O colega é o responsável por marcar as caixas com o novo desenvolvedor, não por ele.
• Cumpra o piso exigido antes do dia 2; os itens do teto polim a semana 1.
• Qualquer item que exceda o tempo alocado é um bug de ferramenta ou documentação - corrija para a próxima contratação.

Fase 1 - Antes da Chegada

1. Acesso pré-arquivado: Organização GitHub, CI, console de nuvem (staging somente leitura), rastreador de erros, wiki de documentação - o acesso é o principal bloqueador do primeiro dia.
2. Enviar README + link da doc de onboarding: Documento canônico no repositório docs/onboarding.md com o nome do proprietário.
3. Atribuir colega: Colega nomeado (não gerente) com check-in diário de 15 minutos na semana 1.
4. Ambiente de desenvolvimento de hardware ou nuvem: Imagem de laptop ou modelo Codespaces com Python 3.14 + uv documentado.
5. Primeiro ticket pronto: "Bom primeiro issue" focado em 1-2 arquivos com critérios de aceitação claros.

Fase 2 - Dia 1

6. Clonar e inicializar: git clone, uv sync, uv run pytest -q verde conforme Checklist de Configuração de Ambiente.
7. Executar o aplicativo localmente: uv run uvicorn app.main:app --reload ou make run - acesse /health no navegador ou curl.
8. Extensões IDE: Python, Ruff, mypy/pyright conforme padrão da equipe; formatar ao salvar habilitado.
9. Conhecer a equipe: Visão geral da arquitetura de 30 minutos - monólito vs serviços, principais armazenamentos de dados, cadência de implantação.
10. Orientação sobre a leitura do código: Orientação do Código com Q&A do colega.

Fase 3 - Semana 1

11. Rastrear uma solicitação de ponta a ponta: Siga a rota HTTP até o banco de dados e de volta - desenhe um diagrama pessoal.
12. Ler convenções: Convenções e Guia de Estilo - regras do ruff, formato de commit.
13. Observar revisão de código: O colega percorre um PR aberto - o que os revisores esperam (Diretrizes de Revisão de Código).
14. Primeiro PR mesclado: Pequena alteração real (correção de documentação, adição de teste, erro de digitação em mensagem de erro) - não um branch descartável.
15. Registrar lacunas na documentação: Cada "Tive que perguntar" se torna um PR para o documento de onboarding na mesma semana.

Fase 4 - Contínuo (30-90 Dias)

16. Observar plantão (se aplicável): Emparelhar em um incidente de staging ou simulação de exercício de incêndio.
17. Assumir um pequeno recurso: Ticket dimensionado para 2-3 dias com nota de design, se necessário.
18. Apresentar aprendizado: Demonstração de 5 minutos ou documento sobre um subsistema descoberto.
19. Contribuir para python-rules ou ADR: Propor um esclarecimento de regra a partir de confusão durante o onboarding.
20. Retro de feedback: Novo contratado + colega + gerente - o que adicionar/remover deste checklist.

Aplicando o Checklist em Ordem

• Fase 1-2 (1-10): Acesso e testes locais verdes antes de esperar contribuições de código.
• Fase 3 (11-15): O primeiro PR mesclado prova que o pipeline funciona para este humano, não apenas para CI.
• Fase 4 (16-20): Propriedade e feedback fecham o ciclo para a próxima contratação.

FAQs

Relacionados

• Checklist de Configuração de Ambiente - ferramentas
• Orientação do Código - estrutura
• Melhores Práticas da Equipe - normas da equipe
• Configuração do Git - configuração do git

Versões da Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ e uv 0.6+.