Onboardings efetivos

Quando um integrante novo é adicionado a uma equipe de desenvolvimento, é padrão (mesmo que informalmente) fazer algum tipo de onboarding, isto é, uma introdução as regras de negócio e a arquitetura do sistema. Esse onboarding pode ocorrer de muitas maneiras, mas normalmente ocorre com integrantes mais seniors do time explicando em linhas gerais o que for julgado necessário, e em times que exploram pair programming esse processo continua naturalmente até o novo integrante se tornar tão habituado como os demais. Pair programming é extremamente efetivo nesse caso (especialmente quando é uma equipe acostumada com isso, e não apenas uma forma de onboarding).

Infelizmente, a maior parte das empresas e seus times não são habituados ao pair programming, e nesse caso, após as explicações iniciais, normalmente o novo integrante recebe uma tarefa e deve executá-la sozinho, com a premissa de que pode pedir ajuda sempre que necessário.

Entretanto, as vezes a própria disposição das mesas na empresa (por exemplo cubículos) ou mesmo uma personalidade mais introspectiva pode desestimular perguntas. Embora possa acontecer com qualquer nível de senioridade dependendo da personalidade e especialmente do grau de auto-exigência / ansiedade em colaborar logo, isso fica ainda mais crítico quando o desenvolvedor a ser agregado ao time tem pouca experiência profissional codando (por exemplo um estagiário ou desenvolvedor júnior).

Nesse caso, a preocupação compreensível de estar "atrasando o projeto" com perguntas "óbvias", ou tomando tempo dos outros desenvolvedores que certamente tem tarefas "mais essenciais ao projeto" fica ainda mais evidente. Isso constantemente leva esses desenvolvedores a perguntar menos e tentar resolver suas tarefas sozinhos com ajuda de ferramentas como o stackoverflow ou fóruns.

Isso tem seu lado positivo já que procurar essas ferramentas e tentar buscar um certo nível de autonomia são indicadores de amadurecimento. Contudo, essas tarefas iniciais caso não possam ser acompanhadas com pair programming devem ser atribuídas de forma mais criteriosa.

Caso não seja possível dar uma tarefa fácil por falta delas no backlog, ou ainda exista o interesse proposital de atribuir uma tarefa um pouco mais difícil para de forma saudável desafiar o novo integrante, deixe isso bem claro de forma transparente. Muitas vezes essa pequena informação pode aliviar sentimentos que podem surgir na cabeça do novo desenvolvedor em que ele acha que está performando mal ou tendo dificuldades demais, o que desmotivam e tornam a curva de aprendizado menos efetiva.

Ou como Katherine Wu disse no excelente post how to be a better junior developer (infelizmente apenas em inglês, trecho traduzido livremente):

".. se como mentor você quer intencionalmente deixar um desenvolvedor junior sofrer um pouquinho para aprender alguma coisa, deixe-o saber que você está fazendo isso. Dessa forma elimina-se sentimentos como o da síndrome do impostor, no qual a pessoa perde sua auto-confiança porque acredita erroneamente que a tarefa deveria ser mais fácil mesmo que de fato seja difícil.  Eu mesma fiz esse erro muitas vezes. É preciso ter cuidado quando atribuímos desafios para pessoas e deixá-las saber o quão difícil é esperado que um problema seja."