Ao entrar em uma empresa qual seria o processo ideal de on boarding na sua opinião?

[felquis]

A pergunta é muito abrangente, pois pode ter uma necessidade bem diferente em empresas menores e maiores em N diferentes dimensões como os objetivos pessoais/profissional da pessoa, projetos de magnitudes diferentes, equipes que pensam de forma diferente, mudança de cidade, estado entre outros. Abs

🔥

edit1: fiz a issue pelo celular e acabei deixando erros, corrigi eles.

[fabiorocha]

Opa @felquis, tudo bom? Acho esse tópico interessante porque geralmente é um pouco negligenciado e os devs novos são forçados a "se virar".

Um pouco de background: trabalhei em empresas de todos os tamanhos, desde pequenas empresas com 5 pessoas até empresas com muita gente. Vou escrever aqui um pouco do que penso sobre onboarding e o que eu vejo que tem funcionado mais.

Acho que a qualidade de um onboard pode ser medida com algumas métricas, sendo que algumas das quais acho mais importantes:

• Em quanto tempo o novo membro da equipe se torna produtivo.

• O quanto o novo membro da equipe torna o time menos produtivo ao ser adicionado ao time, por tirar tempo dos outros membros com perguntas, por exemplo.

• Como um time produtivo não é só produtivo por questões técnicas, temos que adicionar aqui: em quanto tempo o novo membro vira parte do time, em outras palavras, em quanto tempo esse novo membro deixa de ser visto como um novo membro e vira parte do time.

Visto esses objetivos eu vejo que um onboard bem sucedido precisa abordar, pelo menos, os seguintes aspectos:

• Tecnologia

Quais tecnologias/frameworks/linguagens são utilizados pelo time? Como uma pessoa que está começando no time pega o ritmo com essas tecnologias?

• Produto

Muito dificilmente uma pessoa entra de cara num projeto que está iniciando. Geralmente novos devs entram em um projeto que já é desenvolvido há algum tempo, que já tem uma certa complexidade. Daí, como essa pessoa que tá começando conseguiria entender a arquitetura do projeto? Como entender os padrões de projetos utilizados no produto?

• Domínio

Um projeto de software geralmente resolve um problema de algum domínio específico. Como a pessoa que tá iniciando vai aprender sobre esse domínio? Quem é o cliente do projeto? Quais as dores desses clientes? Que problemas são mais importantes de serem resolvidos?

• Cultura

Como falei, nem tudo é sobre o projeto. Tem uma parte, muito importante, que é o fator humano: o time e sua cultura. Nesse aspecto, como integrar o novo membro à equipe? Como tornar esse desenvolvedor parte do grupo?

Onboarding

Dado tudo isso, o que eu tenho visto que funciona é o seguinte. Onboarding tem que ser um processo contínuo, feito o tempo todo, mesmo que pessoas novas não estejam entrando no time.

Como fazer isso:

• Ter um Evernote/Wikipedia/OneNote com tudo que o time faz de repetitivo. Como fazer setup do ambiente, onde baixar tudo que se precisa pra iniciar no projeto, como rodar os testes, etc. Isso é atualizado o tempo todo pelo time. Tudo que é útil que é falado por email ou no Slack, vai pra Wiki. Isso gera um repositório de informações fantástico.

• Reuniões técnicas: aqui toda semana às quintas-feiras alguém do time apresenta algum tópico, tanto sobre a arquitetura do projeto, quanto sobre tecnologias utilizadas ou futuras, etc. Essas reuniões são gravadas e adicionadas à wiki que mencionei aí emcima. Uma pessoa começando tem muitos videos técnicos disponíveis pra assistir quando quiser, que entram em mais detalhes que a wiki.

• Reuniões não-técnicas: o nosso time de duas em duas semanas faz algum evento. Seja sair pra tomar cerveja, seja um almoço mais demorado, enfim, qualquer coisa não relacionada ao trabalho. Isso pode parecer bobagem mas é uma das melhores formas de criar uma cultura de time e de integrar as pessoas. Acho isso bem importante.

Acho que isso tudo, feito continuamente torna o processo de onboarding muito mais fácil. Aquela pessoa que tá começado vai ter uma imensidão de recursos à disposição e vai conseguir atingir aquelas métricas lá de cima: ser produtivo mais rápido, não diminuir a produtividade do time e se integrar ao time mais rapidamente.

Acho que é isso que já vi de bom por aí, quais sugestões você daria? Abs!

[filipedeschamps]

@fabiorocha que resposta sensacional!!!

Hoje no pagar.me temos muitos problemas de onboarding no time de desenvolvimento. Nos reorganizamos em squads e estamos esperançosos que isto irá contribuir, dado que a entropia ficará meio que afunilada em um só tema.

[fabiorocha]

@filipedeschamps Valeu!

Muito legal que vocês tão utilizando Squads aí. Depois escreve sobre a experiência de vocês! Uma das culturas de engenharia que eu mais gosto é a do Spotify, que utiliza esse esquema. Já deu uma olhada na cultura deles?

Spotify Engineering Culture - part 1
Spotify Engineering Culture - part 2

Interessante que você levantou esse ponto de como a organização dos times impacta em onboarding. Eu não faço ideia...