7 passos para acelerar o processo de onboarding

Os projetos de software são muito mais voláteis hoje em dia, do que eram antes. Os requisitos estão sempre a ser alterados, a tecnologia está em constante evolução e a rotatividade nas equipas está a aumentar. É cada vez mais comum ter pessoas a entrar e a sair de um projeto, por inúmeras razões. Algumas podem-se evitar. Outras nem por isso.

Independentemente dos motivos da rotatividade elevada nas equipas de projeto, é importante definir estratégias para garantir que estas mudanças têm o menor impacto possível no sucesso do projeto.

Em relação a este assunto, as empresas e respetivas equipas de desenvolvimento de software têm muito a aprender com a comunidade de open-source.

Um dos principais desafios que os projetos de open-source enfrentam é garantir que a barreira colocada à entrada de novos responsáveis é pequena ou inexistente. As pessoas devem ser capazes de, com o mínimo de esforço possível, entender o projeto, os caminhos a seguir e como contribuir para o mesmo, tornando-se num elemento útil o mais fácil e rapidamente possível.

Com esse desafio em mente, existem algumas práticas comuns entre projetos de open-source bem-sucedidos, que podem ser aplicadas durante o processo de integração de novos membros na equipa.

O planeamento do projeto é uma parte importante do repositório do mesmo. Juntamente com a descrição do projeto, este planeamento ajuda os novos membros da equipa a ter uma ideia rápida dos objetivos a cumprir.

Neste documento, podemos adicionar uma lista de recursos do que “fazer”, “não fazer” e do que eventualmente se “pode fazer”, incluindo ainda os motivos por trás de cada decisão.

Desta forma, não será necessário repetir sempre a mesma conversa cada vez que a equipa recebe um novo membro.

Se estás a começar a planear o teu projeto, podes encontrar um modelo de planeamento de projeto aqui, que te pode ser útil.

Configurar um ambiente de desenvolvimento complexo pode ser dispendioso. Todo o tempo aqui investido, é tempo que o programador não está a usar para acrescentar valor ao próprio projeto. Este custo é ainda maior quando outro membro da equipa precisa de intervir e ajudar o novo programador com a tarefa em questão.

Não é suposto a configuração do ambiente de desenvolvimento demorar dias ou semanas; deve apenas demorar algumas horas – ou minutos.

O processo deve ser o mais planeado e automatizado possível. Os novos membros da equipa devem ser capazes de configurar os seus ambientes de desenvolvimento apenas com a documentação de apoio. Se eles precisarem de ajuda, porque esta documentação está desatualizada ou não é clara o suficiente, isto significa que o novo membro da equipa acabou de ganhar uma oportunidade para fazer o seu primeiro contributo para o projeto, atualizando a documentação e os scripts de configuração.

Um bom código deve ser previsível e de fácil leitura. As convenções são extremamente importantes. A equipa deve acordar as convenções de código a serem utilizadas, e garantir que estas são aplicadas de uma forma automática. Se as convenções de formatação e nomenclatura forem consistentes, a base de código será mais fácil de ler e entender, o que significa que as novas contribuições serão mais fáceis de fazer e rever.

Linters (alguns exemplos no GitHub aqui) e ferramentas de análise de código estático (top 10 do G2 aqui) são cruciais para ajudar o projeto a continuar no caminho certo, relativamente às convenções de programação e práticas recomendadas.

Os testes devem ser automatizados e integrados no processo de CI / CD. Deve ser relativamente fácil escrever um novo teste.

Os testes têm um papel muito importante na ajuda e integração dos novos membros da equipa. Conseguem não só dar uma sensação de segurança ao alterar ou adicionar código, como podem também ser essenciais para compreender a estrutura de base do código.

Testes relevantes e de escrita fácil são bons para todos os membros da equipa. No entanto, os testes podem ser ainda mais relevantes na orientação e integração de um novo membro da equipa ao adicionar código ao projeto ou a corrigir problemas existentes.

A forma como os problemas são apresentados e geridos é muito importante para reduzir barreiras à entrada de novos membros da equipa.

Os problemas devem ser apresentados de uma forma clara, e com todas as informações necessárias. É por isso que os templates são úteis. Assim, todos os membros da equipa sabem que informações precisam de ser dadas e onde podem encontrar a informação relevante para resolver o problema ou adicionar uma funcionalidade ao sistema.

Na exposição dos problemas, deve ser dada informação útil como a descrição do comportamento esperado e atual, e os passos a serem dados para reproduzir esse mesmo comportamento.

As discussões sobre as tarefas de um projeto de TI (Tecnologias de Informação) devem estar disponíveis para toda a equipa, e o seu histórico deve ser guardado. Isto ajuda a equipa a manter-se em sintonia, e dá ao novo membro da equipa um contexto valioso para conseguir resolver um bug ou compreender o porquê da decisão de um design ou implementação.

Os sistemas de gestão de tarefas podem ajudar bastante neste aspeto, visto que, por norma, estes permitem que a equipa adicione comentários e informações extra que ajudam a criar uma timeline e documentação relevante para cada tarefa.

Sempre que possível, deve-se rotular problemas simples de resolver com a etiqueta “Good-First-Issue”. Esta é uma informação que pode ser valiosa para a integração de novos membros na equipa. Estes problemas vão ajudar um novo membro a familiarizar-se com o projeto enquanto, em simultâneo, acrescenta valor ao mesmo.

Colocando em prática cada um destes 7 passos, há uma maior probabilidade de acelerar o processo de onboarding de novos membros na equipa.

Na Growin, já experienciamos melhorias incríveis e conseguimos aumentar significativamente a nossa produtividade. A integração de novos membros tende a fluir melhor em projetos onde estas ideias são tidas em consideração e guiam o processo de tomada de decisões. Os novos programadores começam a acrescentar valor ao projeto mais rapidamente e com um impacto maior – não só na eficiência do funcionamento da equipa, como também na motivação de todos os envolvidos, visto que minimizam o tempo investido em tarefas menos relevantes para atingir o objetivo final.

Ao reduzir as barreiras à entrada de novos membros e manter as coisas simples, previsíveis e bem definidas, os novos programadores da equipa podem focar-se naquilo que realmente gostam de fazer: desenvolver software de excelência!

Já tiveste algum problema com o onboarding de novos membros na equipa? Conta-nos mais sobre o assunto para que possamos entrar em contacto e partilhar algumas dicas úteis.

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –