A rotação de desenvolvedores em um projeto é uma boa ou má idéia?

Estou trabalhando em uma equipe pequena que começará a trabalhar em um grande projeto novo com outra equipe pequena. A outra equipe está atualmente trabalhando em um sistema legado no qual trabalha há anos.

O gerente decidiu que os desenvolvedores da minha equipe girariam a cada poucos meses para substituir os desenvolvedores que trabalham no sistema legado. Dessa forma, a outra equipe terá a chance de trabalhar no novo projeto e entender melhor o novo sistema.

Quero conhecer os benefícios e as desvantagens (se houver) de alternar os desenvolvedores do projeto a cada 2-3 meses.

Sei que essa é uma pergunta semelhante a "A rotação do desenvolvedor principal é uma boa ou má idéia?" , mas essa pergunta se concentra em um desenvolvedor líder. Esta pergunta é sobre rotacionar a equipe inteira dentro e fora do projeto (o líder técnico do novo projeto pode ou não ser rotacionado - ainda não sei).

Estou surpreso que todos pensem que isso é uma coisa tão boa. Os autores do Peopleware (que, na OMI, ainda é um dos poucos preciosos livros de gerenciamento de projetos de software que realmente valem a pena ler) discordam totalmente. Quase toda a parte IV do livro é dedicada a essa mesma questão.

A equipe de software é uma unidade funcional incrivelmente importante. As equipes precisam gelificar para se tornar realmente produtivas. Leva tempo ( muito tempo) para os membros da equipe ganharem o respeito uns dos outros, aprenderem os hábitos e peculiaridades, pontos fortes e fracos.

Certamente, por experiência pessoal, posso dizer que, depois de um ano trabalhando com certas pessoas, aprendi a rir de certas coisas que costumavam me irritar, minhas estimativas como líder de equipe são muito melhores e não é muito difícil. distribuir o trabalho para fazer todos felizes. Não era assim no começo.

Agora você pode dizer: "Ah, mas não estamos dividindo a equipe inteira, apenas movendo algumas pessoas". Mas considere (a) quão cegamente improdutivas serão as substituições deles no começo e (b) quantas vezes você se encontrará ou outras equipes dizendo, sem nem pensar: "Eu realmente gostei de X" ou "Isso teria foi mais fácil com Y ainda por perto " , ofendendo sutil e inconscientemente os novos membros e criando cismas dentro da equipe existente, até semeando descontentamento entre os membros" antigos ".

As pessoas não fazem isso de propósito , é claro, mas isso acontece quase sempre. As pessoas fazem isso sem pensar. E se eles se forçam a não fazê-lo, acabam se concentrando ainda mais na questão e ficam frustrados com o silêncio forçado. Equipes e até sub-equipes desenvolverão sinergias que se perdem quando você mexe com a estrutura. Os autores da Peopleware chamam isso de uma forma de "teamicide".

Dito isto, mesmo que os membros da equipe rotativa sejam uma prática horrível, a equipe rotativa é perfeitamente adequada. Embora as empresas de software bem administradas devam ter algum conceito de propriedade do produto, não é tão perturbador para uma equipe mover toda a equipe para um projeto diferente, desde que a equipe realmente termine o projeto antigo ou, pelo menos, um nível que eles estão felizes.

Ao ter períodos de equipe em vez de de desenvolvedor , você obtém todos os mesmos benefícios que você esperaria obter com desenvolvedores rotativos (documentação, "polinização cruzada" etc.) sem nenhum dos efeitos colaterais desagradáveis ​​em cada equipe como uma unidade. Para quem realmente não entende de gerenciamento, pode parecer menos produtivo, mas tenha certeza de que a produtividade perdida ao dividir a equipe diminui totalmente a produtividade perdida ao mudar a equipe para um projeto diferente.

PS Na nota de rodapé, você menciona que o líder técnico pode ser a única pessoa a não ser rotacionada. Isso é garantido para atrapalhar as duas equipes. O líder técnico é um líder, não um gerente, ele ou ela tem que ganhar o respeito da equipe e não é simplesmente concedido autoridade por níveis mais altos de gerenciamento. Colocar uma equipe inteira sob a direção de um novo líder, com quem eles nunca trabalharam e que provavelmente têm idéias diferentes sobre coisas como arquitetura, usabilidade, organização do código, estimativa ... bem, será estressante como o inferno para o líder tentando construir credibilidade e muito improdutivo para os membros da equipe que começam a perder coesão na ausência de seu antigo líder. Às vezes as empresas têmfazer isso, ou seja, se o lead sair ou for promovido, mas fazê-lo por escolha parece insano.

Eu não vejo muita desvantagem aqui. A rotação leva você a:

• Polinização cruzada do conhecimento institucional - todos conhecerão o projeto legado e o novo, pelo menos em teoria.
• Treinamento cruzado - projetos diferentes exigem coisas diferentes com frequência. Você cresce muito mais como desenvolvedor trabalhando em projetos feios e antigos do que em projetos greenfield agradáveis ​​e limpos.
• Projetos fundamentalmente melhores - nada como ter uma nova equipe entrando para fazer você terminar a documentação e limpar os processos feios com os quais deseja viver, mas não admite publicamente.
• Melhor código - mais cabeças são melhores na maioria dos casos.
• Prováveis ​​melhorias no moral - a variedade é o tempero da vida. E quem quer ficar preso no modo de correção de erros do projeto legado / gravação de dutos permanentemente. Lembre-se também de que seu "novo" projeto se tornará legado em algum momento. Deseja ficar para sempre lá?

Provavelmente, a única desvantagem é a queda de produtividade causada pela troca de lugar, mas isso só deve doer muito na primeira rodada. Posteriormente, ambos os lados terão algum tempo de assento em ambos os lugares e as partes feias da transferência provavelmente serão melhor compreendidas e talvez resolvidas.

Curiosamente, em minha experiência, começamos nossos projetos com essa mesma intenção. No final, muitas vezes falhamos em agir com essa intenção devido a restrições no projeto mais recente e a uma crença de que o treinamento cruzado é muito caro.

Eu sempre gostaria que tivéssemos conseguido, porém, a longo prazo, acredito que seja benéfico para todas as partes - equipe, empresa, cliente e software. 2/3 meses parece um período suficientemente longo para que haja um risco limitado de qualquer sério impacto negativo; não há mudança de contexto para os desenvolvedores envolvidos, exceto no ponto de mudança no momento em que eles podem se dedicar ao projeto alternativo.

Alguns benefícios possíveis não mencionados:

• Melhor gerenciamento de projetos. Se os gerentes de ambos os projetos estiverem presentes, é de seu interesse trabalhar duro para que os períodos de transição não sejam dolorosos para nenhum dos projetos. Por sua vez (dependendo da sua configuração) pode resultar em uma colaboração mais estreita entre os PMs e as equipes de desenvolvimento.
• Melhor documentação (proativa). Se você sabe que está entrando e saindo de um projeto, não é apenas do melhor interesse do projeto, do interesse da empresa, das melhores práticas em geral, mas agora, em cada desenvolvedor, o melhor interesse para facilitar a vida enquanto estão saltando por aí.
• O moral é um grande problema, se seus desenvolvedores não tiverem o suficiente de ficarem presos em um projeto legado, talvez eles não sejam os desenvolvedores que você deseja! Se o fizerem, alternar entre eles e fazer com que outros desenvolvedores trabalhem nisso fará com que sintam amor pela sua empresa - eles podem apenas arrumar os trechos de código que pensavam que ninguém jamais veria também. Os sistemas legados são frequentemente vistos como projetos de segunda classe, o que geralmente prejudica, talvez dessa maneira você ajude a mudar essa percepção.

A rotação é uma coisa boa para a empresa e também para os desenvolvedores.

Há muitas boas razões e Wyatt mencionou muitas delas em sua resposta.

Dito isto, na sua situação, você pode descobrir que, ao apresentar isso, os desenvolvedores que estão migrando do projeto mais recente para o projeto herdado podem não estar felizes, portanto, é necessário haver uma comunicação muito clara sobre o motivo e o tempo que isso está acontecendo. é para, e o plano daqui para frente.

Pode ser bom pensar em não trocar as equipes por atacado para começar e girar 1 ou 2 desenvolvedores para começar, embora isso possa parecer destacar pessoas para um rebaixamento (que algumas pessoas podem ver).

Concordo com o Aaronaught que é muito estranho ver quantas pessoas simplesmente não vêem desvantagens. Poucos pensam mal, que você pode apontar muito rapidamente - o código não tem proprietário e quando todos são responsáveis ​​por tudo não são tão bons quanto à qualidade . Os desenvolvedores não são recursos (mesmo que sejam chamados assim com muita frequência pelos gerentes), são pessoas e para a equipe é muito importante que se conheçam, a rotação faz um pouco de caos por lá. Se você trabalha em algum projeto por mais tempo, se tornará um especialista (não apenas no domínio, mas nesse projeto), saberá de onde vieram os problemas, quem obterá as melhores respostas ou talvez alguns conhecimentos mais específicos sobre o domínio etc. Se você é novo, precisará aprender tudo isso, para diminuir o progresso. Mas é claro que também é bom conhecer outras práticas em sua organização, como outras equipes constroem e organizam. É especialmente bom se os seus projetos estiverem relacionados de alguma maneira, por exemplo, um projeto é inserido para outro (não é necessário diretamente), para obter uma melhor compreensão do panorama geral. E é claro que disseminar conhecimentos é bom (se você tiver tempo para obter esses conhecimentos).

Concordo com a principal resposta de Aaronaught e tenho algumas adições.

• As pessoas não gostam de ser empurradas.
• Em um ambiente de negócios hierárquico, as pessoas podem receber responsabilidades que são posteriormente retiradas delas novamente. Isso pode ser apenas parte do trabalho. No entanto, quanto mais isso acontecer, menos provável será que essas pessoas se sintam responsáveis ​​por qualquer coisa que lhes seja atribuída.
• O primeiro ponto também se aplica ao trabalho de manutenção de coisas que as próprias pessoas não criaram. Limpar a bagunça de outras pessoas (ou de forma mais neutra: trabalho inacabado) não é particularmente motivador para a maioria das pessoas que criam.
• A filosofia "um programador é um programador é um programador, eles são plug-ins anônimos para serem inseridos nos projetos conforme necessário" não faz nenhum programador se sentir apreciado ou se importar mais com as tarefas atribuídas a ele.

O momento perfeito para reatribuir alguém é quando eles começam a ficar entediados com o que estão fazendo. Não há mais nada a ganhar, tudo está sob controle, o trabalho está feito. Nesses casos, eles geralmente se apresentam e solicitam outras oportunidades.

É claro que a realidade é teimosa e, muitas vezes, não há escolha; alguém pode ser necessário em outro lugar por qualquer motivo. Isso não é necessariamente ruim, também pode fazer com que uma pessoa se sinta importante e, se ela resolver algum grande problema, haverá crédito nela.

Apenas embaralhar pessoas para espalhar conhecimento provavelmente aumentará a rotatividade. Dessa forma, o conhecimento será espalhado, mas será espalhado para fora da empresa, o que provavelmente não é a intenção.

TL; DR Crie uma equipe e, em seguida, uma equipe apoie 2 projetos.

Para ecoar o @Aaronaught, acho que misturar equipes pode ser problemático, pois pode levar tempo para se adaptar a novas práticas, processos etc. Se você girar muitas pessoas rapidamente, a equipe perderá sua identidade. Isso leva a mais perguntas, confusão e tempo gasto tentando compensar essa identidade.

Por outro lado, se houver um esforço conjunto para unir as 2 equipes em uma equipe e tiver 1 equipe para apoiar 2 projetos, acho que funciona muito bem desde que a equipe não seja muito grande. Eu fiz parte de várias equipes que suportam vários projetos. Quanto mais próximos os dois projetos de tecnologia, mais fácil é a transição. Na minha experiência, o custo mais alto na transição de um projeto para outro ocorre ao cruzar idiomas, cliente / servidor (principalmente GUI), setor (médico, web, jogo) ou outras linhas semelhantes. O truque é conseguir que pessoas diferentes trabalhem no projeto com freqüência suficiente para obter os benefícios, mas não com tanta frequência que o custo da transição exceda os benefícios.

Então, os benefícios de obter mais pessoas em um projeto são bastante conhecidos, assim como os custos.

A rotação de programadores é algo bom do ponto de vista da empresa e do desenvolvedor.

Do ponto de vista da empresa

1. A gerência conhecerá a força e a fraqueza de um desenvolvedor em particular, se ele pode lidar com multitarefa ou não e adaptável às mudanças.
2. Se algum desenvolvedor deixar a empresa por algum motivo, a empresa já terá o backup pronto para o futuro.
3. Ele aprimorará o desempenho do projeto, pois muitas pessoas trabalharão nele, a mesma coisa é testada por mais e mais desenvolvedores. (Teste de desperdício de recursos minimizado)
4. Todos os membros da equipe trabalham em equipe e isso aumentará o desempenho do projeto e, no futuro, a gerência saberá que tipo de equipe precisa ser feita ao implementar o módulo ou tarefa difícil.

Do ponto de vista do desenvolvedor

1. Isso tornará o desenvolvedor mais positivo à medida que sua confiança aumentar.
2. Os desenvolvedores obtêm idéias cada vez melhores de outros colegas de equipe e podem usar essas técnicas no desenvolvimento futuro.
3. A partir de melhores idéias e sugestões de outros membros da equipe, a produtividade do desenvolvedor aumenta.

Apenas uma coisa principal, é preciso ter em mente que,

A rotação dos programadores não deve acontecer com muita frequência. após o desenvolvimento de 60% a 70%, somente a troca será benéfica.