Um dev novo entra no seu time remoto. Recebe um e-mail de boas-vindas com dezessete links. Uma mensagem no Slack dizendo "qualquer dúvida, me chama". Um convite de calendário para um 1:1 na semana seguinte.
No terceiro dia, ele ainda está preso configurando o ambiente. No quinto, já leu muita documentação, mas não subiu nenhum código. Na segunda semana, se sente desconectado e atrasado.
Esse é o onboarding padrão na maioria das empresas. Ninguém faz isso de propósito. Só não existe um propósito. Este é o roteiro que usamos com cada profissional que alocamos. Ele deixa a pessoa produtiva em 48 horas.
Antes do primeiro dia (o checklist de pré-onboarding)
O onboarding começa antes do primeiro dia. Se você deixa para criar os acessos no primeiro dia, já desperdiçou as horas em que a pessoa está mais motivada.
72 horas antes da data de início, resolva isto:
- Crie todos os acessos: GitHub ou GitLab, Slack, Jira ou Linear, AWS ou GCP (o que ela for usar), e-mail, VPN
- Adicione a pessoa aos canais certos do Slack (canal do time, canais de projeto, canais sociais)
- Mande um documento de boas-vindas com: quem é quem no time, uma visão geral do produto (no máximo 2 páginas), um resumo da stack e o link para o guia de configuração do ambiente
- Defina um buddy (falo dele mais abaixo)
- Coloque três reuniões na agenda do primeiro dia: 30 minutos de boas-vindas com a liderança direta, 45 minutos de apresentação do produto com o buddy e 30 minutos de visão geral da arquitetura com alguém sênior
O objetivo: quando a pessoa abrir o notebook no primeiro dia, todos os acessos funcionam e ela sabe exatamente como vão ser as primeiras seis horas.
Manhã do primeiro dia: orientação e contexto
9h: conversa de boas-vindas com a liderança (30 min). Não é uma apresentação de processos. É uma conversa entre pessoas. "Isto é o que o time está fazendo neste trimestre. É aqui que você entra. É isto que vai significar sucesso nos seus primeiros 30 dias." Seja específico. "Você vai trabalhar na refatoração do checkout com a Ana e o Marcos" é melhor do que "você vai entrar no time de plataforma".
9h45: configuração do ambiente. Deveria levar menos de uma hora se o guia estiver atualizado. O buddy precisa estar disponível no Slack nesse período para responder na hora. Se levar mais de uma hora, o guia está desatualizado. Corrija.
11h: apresentação do produto com o buddy (45 min). Tela compartilhada. Navegue pelo produto como usuário. Mostre os fluxos principais. Aponte as partes bem feitas e as partes bagunçadas. Seja honesto. "Este módulo tem boa cobertura de testes. Aquele outro é legado e ninguém quer mexer." Honestidade gera confiança mais rápido do que uma apresentação polida.
Tarde do primeiro dia: primeiro commit
13h: visão geral da arquitetura (30 min). Alguém sênior mostra como o código está organizado. Não arquivo por arquivo. O quadro geral: como os serviços conversam, onde os dados ficam, como funciona o deploy, onde o pipeline de CI/CD está configurado. Desenhe um diagrama se ajudar.
14h: primeira tarefa. Essa parte é decisiva. Tenha um card pequeno e bem definido pronto. Algo como "atualizar o texto da página de configurações" ou "adicionar um campo que falta na resposta da API". O card precisa caber em 2 ou 3 horas e mexer no código real, não num ambiente de teste isolado.
O objetivo é um PR mergeado no primeiro dia. Não importa se a mudança é minúscula. O efeito psicológico é enorme. "Subi código no meu primeiro dia" gera um embalo que dura a semana inteira.
17h: check-in de fim de dia com o buddy (15 min). Uma conversa rápida. "Como foi? Alguma coisa confusa? Algo te travando?" Isso não é opcional. Dev remoto nem sempre avisa por conta própria quando está travado. Dê a ele um momento estruturado para isso.
Segundo dia: primeira contribuição de verdade
Manhã: segunda tarefa. Esta precisa ser um pouco mais complexa. A correção de um bug que exige entender um módulo específico. Uma feature pequena que passa por dois serviços. Algo que obrigue a pessoa a ler código existente, não só escrever código novo.
Tarde: participar de um ritual do time. Planning, refinamento ou retro. Tanto faz qual. O objetivo é ver como o time se comunica e toma decisões. Incentive a pessoa nova a fazer perguntas durante a reunião. "O que significa essa sigla?" é uma pergunta totalmente válida no segundo dia.
O sistema de buddy
O buddy é a parte mais importante deste roteiro. Sem ele, o dev novo acaba lendo documentação em silêncio e se sentindo perdido.
Um bom buddy não precisa ser a pessoa mais sênior do time. Precisa ser alguém que:
- Conhece o código o bastante para responder perguntas do tipo "onde acontece X?"
- Responde rápido no Slack (em até 30 minutos durante o expediente)
- Tem paciência com perguntas que podem parecer óbvias
- Tem tempo livre: não escolha alguém que está no meio de uma entrega crítica
O compromisso do buddy é de 2 a 3 horas de disponibilidade espalhadas pela primeira semana. Não é muito, mas precisa ser explícito. "Você é o buddy do Lucas nesta semana" é diferente de "fica de olho no pessoal novo".
O checkpoint do fim da primeira semana
No fim da primeira semana, a liderança faz um check-in de 30 minutos. Três perguntas:
- "O que está mais claro agora do que estava na segunda-feira?"
- "O que ainda está confuso?"
- "Tem alguma coisa que você precisa e ainda não tem?"
Registre as respostas. O que ainda está confuso vira ação para o buddy ou para o time. O que falta é resolvido na hora.
O que a maioria das empresas pula
Três coisas que quase todo mundo pula e não deveria:
Uma primeira tarefa já escolhida. Dizer para alguém "dá uma olhada no backlog e pega alguma coisa" no primeiro dia paralisa. Escolha a tarefa por ele. Faça ser fácil. Faça ser real.
Documentação assíncrona que está realmente atualizada. Se o README não é atualizado há seis meses, é pior do que não ter README. Documentação velha gera falsa confiança e tempo perdido. Antes de a pessoa começar, peça para o buddy conferir se o guia de configuração funciona.
Conexão entre as pessoas. Dev remoto precisa conhecer os colegas como gente, não só como avatar do Slack. Marque uma call informal com o time na primeira semana. Sem pauta. Só conversa. Parece detalhe, mas afeta diretamente o quanto a pessoa se sente à vontade para pedir ajuda quando trava.
O roteiro de onboarding em 48 horas não é complicado. Ele só é intencional. Cada hora dos dois primeiros dias está planejada. Cada pergunta tem alguém para responder. Cada tarefa já vem escolhida e com escopo definido.
As empresas que acertam no onboarding remoto não fazem nada de mágico. Elas só não deixam nada ao acaso.
