Compartilhamento de Conhecimento Turbinado
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Um dos desafios que tive que enfrentar algumas vezes na minha carreira foi como acelerar a integração de um time de desenvolvimento de software, especialmente no que diz respeito ao compartilhamento de conhecimento.
Por que é difícil?
Ainda me lembro de assistir a uma apresentação antiga do Dan North onde ele insistia no mesmo ponto: sempre existe uma história por trás de qualquer decisão tomada em um projeto. E esse é o principal problema que vejo ao entrar em um novo time: sempre existe uma história, e você provavelmente não a conhece.
Trabalhar em uma nova base de código para mim é como se mudar para uma casa em um bairro novo. Leva um tempo até você saber onde ficam todas as lojas, qual é o melhor caminho para chegar a qualquer lugar e onde comprar coisas de madrugada. Em um projeto de software, você não sabe exatamente onde as coisas estão no código, leva tempo para entender a lógica por trás do design e você tem medo de fazer grandes mudanças, mesmo quando elas deveriam ser feitas!
Então, ao integrar um time com uma quantidade considerável de novos desenvolvedores, existe o risco de que eles não consigam ser efetivos por um bom tempo, ou que na urgência de serem efetivos acabem mudando o que não precisa ser mudado, sendo contraproducentes no final das contas.
Lá vamos nós de novo
Esse desafio surgiu novamente no meu último projeto, onde estávamos começando a trabalhar na nossa segunda release e queríamos incluir um time de desenvolvedores na China no que se tornaria nosso novo time distribuído.
Felizmente, conseguimos passar 2 semanas juntos como um time co-localizado em Xi’an, mas ainda assim precisávamos usar esses 10 dias úteis para integrar 5 novos desenvolvedores que tinham pouca ou nenhuma experiência na base de código em que estávamos trabalhando.
Dessa vez, decidimos tentar algo fora do comum, com alguma inspiração vinda do meu período na ThoughtWorks University (o que o Sumeet chamaria de workscaping), no que poderia ser descrito como uma mistura de pareamento promíscuo e showcases muito frequentes.
O que isso significa?
A ideia era:
- Rotacionar os pares a cada 2 horas
- Após cada bloco de 2 horas, o time parava e cada par fazia uma apresentação de 5 minutos sobre o que tinha feito
- Tínhamos um espaço de 30 minutos disponível no final do dia para ter uma discussão mais aprofundada sobre tópicos em que os novos desenvolvedores tinham dúvidas
Alguns dos benefícios que esperávamos alcançar eram:
- Todos trabalhariam juntos várias vezes, melhorando o relacionamento entre os membros do time
- Os novos desenvolvedores teriam a oportunidade de mexer em diferentes partes do código bem cedo, ouvindo as histórias dos mais antigos sobre o que estava ali e por quê
- Ao apresentar de volta para o time, todos teriam a chance de levantar perguntas e entender um pouco mais sobre um tópico específico
- O compartilhamento constante de informação permitiria que os novatos tivessem mais perguntas respondidas e entregassem funcionalidades mais rápido, o que sempre ajuda na confiança
Então o dia começava com um stand-up normal, e após 2 horas o time se reunia e dava uma volta pela sala, ouvindo o que tinha acontecido. Os pares então rotacionavam e começavam de novo. Repita isso 4 vezes e o dia acaba.
Como foi?
No geral, o resultado foi bastante bom na minha opinião. A maioria dos resultados que esperávamos alcançar realmente aconteceram, especialmente a comunicação dentro do time, que estava ótima após alguns dias.
Depois de uma semana fazendo isso, a maioria das pessoas começou a sentir a necessidade de trabalhar mais horas sem interrupção, então mudamos nosso ritmo para 2 rodadas de 4 horas e eventualmente para rotacionar os pares uma vez por dia, onde acabamos estabilizando. Apesar de ter sido antes do esperado, pareceu um ponto natural onde as pessoas tinham conhecimento suficiente para entregar e queriam focar nisso, o que provavelmente pode ser considerado um sucesso.