Nós sabemos: o processo de onboarding de novas pessoas desenvolvedoras para seu time não é uma 'receita de bolo' simples de ser reproduzida. As variáveis são incontáveis: projeto, senioridade, linguagem, cultura, presencial vs. remoto, perfil e etc. Apesar disso, podemos mitigar falhas de execução e evolução de novas pessoas do seu time com uma premissa básica: combatendo a famosa preguiça.

preguiça
estado de prostração e moleza, de causa orgânica ou psíquica.

Calma. Todos nós somos pessoas preguiçosas em determinado nível para alguma coisa (ou alguém) e está tudo bem. A questão aqui é: enquanto gestão do seu time, se você quiser que as coisas fluam com menor atrito, você não poderá adotar um comportamento preguiçoso.

Depois de algum tempo, notei que algumas coisas funcionavam melhor na maior parte dos casos do que outras e pode funcionar para você também:

Analise previamente o perfil

A entrada de uma nova pessoa no seu time não deve ser uma surpresa. Partindo desse pressuposto, entendemos que terá algum período de tempo para analisar o perfil previamente, seja nas entrevistas/dinâmicas iniciais antes da movimentação/contratação ou até mesmo dando aquela leve visitada no perfil do LinkedIn e GitHub. Não é preciso aqui um dossiê. Seja breve e busque compreender:

Quais experiências passadas;
Quais linguagens e tecnologias já trabalhou/estudou anteriormente e;
Qual o momento de carreira.

Muito provavelmente, com os links corretos, você terá o mínimo dessas informações em 2 cliques e 3-4 minutos de investigação.

Tenha empatia

A nova pessoa integrante não terá mesmo contexto e, jamais, aprenderá/absorverá informações na mesma velocidade que você (queira ou não; sendo mais rápido ou não). Portanto:

Dê tempo suficiente para ambientação (stack, repositórios e tecnologias no geral);
Insira a pessoa em rotinas do seu time;
Quebre barreiras de comunicação que possa existir entre demais;
Fique perto e esteja disponível;
Não jogue a pessoa na fogueira (todo mundo tá vendo você sendo babaca).

Promova resultados rápidos

Sabe aquele erro que está parado no backlog há mais de duas semanas e ninguém o assume/prioriza? Seria interessante atribuí-lo para a nova pessoa desenvolvedora do seu time afim de 'desafiá-la', certo? Errado. Novamente: todo mundo tá vendo você sendo babaca.

Opte por atribuir tarefas simples, que forneçam feedbacks quase instantâneos. Isso garantirá que a nova pessoa integrante passe pelas barreiras iniciais (ambiente, instalação de dependências, permissões, etc.), comece a trafegar razoavelmente entre a aplicação e sinta-se útil (sim, isso é importante).

Contextualize

Ler código não é difícil. Difícil é compreender o porque das coisas: finalidades, contratos, exceções, estruturas e todo o resto. Aqui, deve ocorrer a primeira contextualização macro de como as coisas funcionam. Procure usar ferramentas visuais e que interajam em conjunto: Miro, slides ou papel. Exemplifique:

Arquitetura;
Responsabilidade de serviços/aplicações;
Fluxo de dados entre serviços;
Tecnologias utilizadas;
Decisões importantes que foram assumidas no passado;
Organização/Atribuição de demais times/squads (caso existam);
Comportamentos esperados;
Objetivo do produto.

Suba alguns níveis

Após a nova pessoa integrante botar a mão no código e receber contextualização, certamente, é hora de subir alguns níveis de dificuldade/responsabilidade de tarefas. O feedback nesse momento não precisa ser instantâneo mas, atente-se para que não seja algo trabalhoso demais (manter a pessoa 'agarrada' numa tarefa por tempo demais é improdutivo e desmotivador - em qualquer cenário).

Nesse momento, é comum que ocorram inseguranças: demora em enviar o Pull Request mesmo com a tarefa já desenvolvida localmente e revalidação excessiva do escopo da tarefa são sintomas comuns. Na maior parte das vezes é simples de resolver: apenas abram o Pull Request (se necessário, até mesmo revisem juntos). Deixe claro que a abertura de uma solicitação de alteração é nada mais que isso e que poderão realizar alterações nessa solicitação a qualquer momento.

Contextualize novamente

Você não deve esperar que tudo seja absorvido na primeira contextualização e agora que foram assumidas tarefas de maior complexidade, muito provavelmente, surgiram mais duvidas. Repasse os itens da contextualização anterior e aprofunde onde necessário. Abra o projeto e mostre o código em funcionamento, se for o caso.

Dê clareza na direção

Chegando aqui, você como boa pessoa observadora já deve ter notado as principais dificuldades e pontos de falha de comunicação que ocorreram no meio desse processo. Clarifique:

Deixe claro o momento atual do projeto;
Deixe claro o momento atual do time;
Deixe claro a próxima grande entrega;
Deixe claro a principal atribuição/responsabilidade de curto prazo para a nova pessoa do seu time.

Mais uma vez: isso não é uma receita. Esses 'passos' foram notados com sucesso por experiências que vivi até aqui. Absorva o que considerar relevante e adeque para a sua realidade (se considerar viável). Que seu time possa ser mais eficiente daqui em diante.

Até a próxima! 🖖

# Onboarding

Pare de realizar onboardings preguiçosos