O onboarding é o momento em que a maioria das parcerias técnicas dá certo — ou começa a falhar em silêncio.

Não por falta de capacidade técnica.
Mas porque o sistema de trabalho não está claro.

Quando o onboarding se arrasta, os sintomas aparecem rápido:

PRs ficam lentos porque padrões de código não estão alinhados
QA entra tarde porque expectativas nunca foram definidas
Slack vira documento de requisitos
Líderes gastam mais tempo coordenando do que construindo
A pergunta surge: “Por que a velocidade caiu?”

Este guia é um playbook prático de onboarding de squads remotos, focado em manter velocidade desde a primeira semana — com atenção especial ao uso correto de horários compartilhados de trabalho, que fazem a diferença entre um time distribuído e um time desconectado.

O objetivo real do onboarding

Muita gente acha que onboarding é “liberar acesso”.

Isso é só o passo zero.

O objetivo real é simples:

Entregar um PR limpo na primeira semana
e operar com previsibilidade a partir da segunda.

Tudo neste playbook existe para garantir isso.

Por que o onboarding costuma matar a velocidade

• Os mesmos erros se repetem:

• não existe uma fonte única de decisões e requisitos

• padrões de repositório não estão claros

• ambientes locais e pipelines não batem

• QA não sabe o que validar nem quando

• dúvidas simples viram ciclos de 24h

• ninguém sabe quem aprova, revisa ou decide

A correção é direta: definir o sistema antes de escrever código.

Playbook de Onboarding — Primeiras 2 Semanas

Dia 1 — Alinhamento e acesso (ainda não é para codar)

Objetivo: eliminar bloqueios básicos e alinhar como o time trabalha.

Checklist Dia 1

Acessos

• Repositório liberado com permissões corretas

• Ambiente de desenvolvimento e homologação acessíveis

• Processo de gestão de secrets definido

• Regras de VPN / segurança esclarecidas

Contexto do projeto

• O que estamos construindo e por quê

• Objetivo do MVP ou da entrega atual (1 parágrafo)

• Métrica de sucesso definida

• Lista inicial do que não está no escopo

Fluxo de trabalho

• Ferramenta de gestão (Jira, Linear, etc.) alinhada

• Canais de comunicação definidos

• Janela de horário compartilhado combinada

Única reunião necessária (15–25 min)
Alinhamento de:

• como o time trabalha

• regras de PR

• definição de pronto

• onde decisões ficam registradas

• como escalar bloqueios

Dia 3 — Ambiente e fluxo de repositório

Objetivo: garantir que local, CI e deploy falem a mesma língua.

Checklist Dia 3

Padrões de repositório

• Estratégia de branches definida

• Template de PR criado

• Estilo de código e lint confirmados

• Responsáveis por review definidos

CI/CD

• Pipelines funcionando

• Checks obrigatórios claros

• Ambiente de deploy definido

• Estratégia de rollback compreendida

Observabilidade

• Ferramenta de logs/erros definida

• Padrão mínimo de logs acordado

Resultado esperado:
Todos conseguem rodar o projeto localmente e passar no pipeline.

Dia 5 — O primeiro PR limpo

Objetivo: criar confiança no fluxo real de entrega.

Checklist Dia 5

PR

• PRs pequenos e revisáveis

• SLA de review dentro do horário compartilhado

• Regra clara de “pronto / não pronto”

• Critério de merge definido

Qualidade

• Checklist do fluxo crítico

• Lista inicial de regressão

• Classificação de bugs definida

• “Pronto” exige validação mínima de qualidade

Ritmo

• Modelo de relatório semanal criado

• Horário fixo para demo e alinhamento

• Regra clara para bloqueios

Resultado esperado:
Um PR real, revisado e integrado sem atrito.

Semana 2 — Cadência e previsibilidade

Objetivo: transformar entregas em sistema.

Checklist Semana 2

Ritmo

• Planejamento leve definido

• Checkpoint intermediário (se necessário)

• Checklist de prontidão para entrega

• Demo e relatório semanais fixos

Visibilidade

• Métricas mínimas escolhidas:

  • tempo de PR

  • tempo até primeiro review

  • WIP

  • qualidade na validação

  • status de entrega

Risco

• Responsabilidades claras

• Documentação essencial registrada

• Processo de substituição entendido, se necessário

Resultado esperado:
Gestão consegue prever entregas com base em sinais reais.

Rituais mínimos que protegem a velocidade

Não é sobre mais reuniões. É sobre as certas.

• planejamento semanal curto

• updates assíncronos e objetivos

• janela diária para reviews e desbloqueios

• demo e relatório semanais

Isso mantém foco sem sobrecarregar.

Como usar bem o horário compartilhado

Não transforme em reunião contínua.

Use para:

• revisão de PR

• desbloqueios rápidos

• priorização

• demos

• validação de entrega

Trabalho profundo fica assíncrono.
Horário compartilhado remove atrito.

Scorecard rápido de onboarding

Ao final da segunda semana, você deve responder “sim” para:

PRs fluem sem gargalo
qualidade está integrada ao fluxo
definição de pronto é clara
relatório semanal existe
entrega é previsível
liderança não precisa caçar status

Se mais de dois pontos falham, a velocidade vai cair depois.

Como a Wima faz onboarding de squads

A Wima não faz onboarding “adicionando pessoas”.
Faz onboarding instalando um sistema de entrega.

• horário compartilhado de trabalho

• regras claras de PR

• qualidade dentro do sprint

• visibilidade semanal

• responsabilidades explícitas

• controle de risco

Por isso o onboarding não reduz velocidade — ele cria base para escalar.

Perguntas comuns

Quanto tempo leva um bom onboarding de squad remoto?
Duas semanas são suficientes para criar cadência estável quando o sistema é bem definido.

Qual o maior erro no onboarding técnico?
Achar que liberar acesso é suficiente. Fluxo e regras vêm antes do código.

Por que horário compartilhado importa tanto?
Porque reduz ciclos de decisão e evita que pequenos bloqueios virem dias perdidos.

Como saber se o onboarding funcionou?
Quando o time entrega sem atrito e a gestão enxerga progresso sem esforço.