A rotação de desenvolvedores em um projeto é uma ideia boa ou ruim?

Estou surpreso que todo mundo acha que isso é uma coisa boa. Os autores do Peopleware (que, IMO, ainda é um dos poucos programas preciosos livros de gerenciamento de projetos realmente vale a pena ler) discordo totalmente. Quase toda a Parte IV do livro é dedicada a este assunto.

A equipe de software é uma unidade funcional incrivelmente importante. As equipes precisam se tornar realmente produtivas. Leva tempo (um lote de tempo) para que os membros da equipe conquistem o respeito uns dos outros, aprendam os hábitos e as peculiaridades e os pontos strongs e fracos dos outros.

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íderes de equipe são muito melhores, e não é É muito difícil distribuir o trabalho para deixar todo mundo feliz. Não foi assim no começo.

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

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é subequipes desenvolverão sinergias que se perdem quando você se envolve com a estrutura. Os autores do Peopleware chamam isso de "teamicide".

Dito isto, mesmo que a rotação dos membros da equipe seja uma prática horrível, girar as próprias equipes está perfeitamente bem. Embora empresas de software bem administradas devam ter algum conceito de propriedade de produto, não é tão perturbador para uma equipe transferir toda a equipe para um projeto diferente, contanto que a equipe realmente conclua o projeto antigo ou, pelo menos, o leve para um nível que eles estão felizes com.

Por ter entradas em equipe ao invés de em desenvolvedor , você obtém todos os benefícios que você espera obter com desenvolvedores rotativos (documentação, "polinização cruzada", etc. .) sem nenhum dos efeitos colaterais desagradáveis em cada equipe como uma unidade. Para aqueles que realmente não entendem de administração, pode parecer menos produtivo, mas tenha certeza de que a produtividade perdida ao dividir a equipe supera totalmente a produtividade perdida ao mover a equipe para um projeto diferente.

P.S. Em sua nota de rodapé você menciona que o líder técnico pode ser o único pessoa não a ser rotacionado. Isso é praticamente garantido para bagunçar ambas equipes. O líder de tecnologia é um líder, não um gerente, ele ou ela tem que ganhar o respeito da equipe, e não é simplesmente concedida autoridade por níveis mais altos de gerenciamento. Colocar uma equipe inteira sob a direção de uma nova liderança com quem nunca trabalharam e com muita probabilidade de ter idéias diferentes sobre coisas como arquitetura, usabilidade, organização de 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 a coesão na ausência de sua antiga liderança. Às vezes, as empresas têm para fazer isso, ou seja, se o lead sair ou for promovido, mas fazê-lo por escolha parecerá insano.

    

Eu não vejo muita desvantagem aqui. A rotação te leva:

• 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 um desenvolvedor que trabalha em projetos herdados do que em projetos novos e limpos.
• Projetos fundamentalmente melhores - nada como ter uma nova equipe chegando para fazer com que você termine a documentação e limpe os processos feios com os quais você está disposto a conviver, mas não admitir publicamente.
• Melhor código - mais cabeças são melhores na maioria dos casos.
• Melhorias prováveis na moral - a variedade é o tempero da vida. E quem quer ficar preso no modo legado de correção de bugs do projeto / modo de gravação de dutos permanentemente. Também tenha em mente que seu "novo" projeto se tornará legado em algum momento, você quer ficar preso lá para sempre?

Provavelmente, a única desvantagem é a queda de produtividade que você recebe ao trocar de lugar, mas isso só deve prejudicar a primeira rodada. Depois, ambos os lados terão algum tempo de assento em ambos os lugares e as partes feias do handoff provavelmente serão melhor compreendidas e talvez resolvidas.

    

Curiosamente, na minha experiência, muitas vezes iniciamos nossos projetos com essa intenção. Na linha de frente, muitas vezes deixamos de agir com base nessa intenção devido a restrições no projeto mais recente e a crença de que o treinamento cruzado é muito caro.

Eu sempre desejei que tivéssemos conseguido, no longo prazo, acredito que seja benéfico para todas as partes - equipe, empresa, cliente & Programas. 2/3 meses soa como um período longo o suficiente para que haja um risco limitado de qualquer impacto negativo sério, não há mudança de contexto acontecendo para os desenvolvedores envolvidos, exceto no ponto de transição em que eles podem se dedicar ao projeto alternativo. / p>

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

• Melhor gerenciamento de projetos. Se os gerentes de projeto de ambos os projetos estiverem a bordo, é de seu interesse trabalhar duro, de modo que os períodos de transição não sejam penosos para nenhum dos projetos. Este é o turno (dependendo da sua configuração) poderia 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 no melhor interesse do projeto, o melhor interesse das empresas, a melhor prática em geral, mas agora, em cada um dos interesses dos desenvolvedores, facilitar a vida enquanto eles estão saltando. ao redor.
• A coisa da moral é um grande negócio, se os seus desenvolvedores não tiveram o suficiente de ficarem presos em um projeto legado, então eles podem não ser os desenvolvedores que você quer! Se tiverem, mudá-los e convencer outros desenvolvedores a fazê-los sentirem amor por sua empresa - eles podem simplesmente arrumar os pedaços de código que eles achavam que ninguém veria também. Os sistemas legados são frequentemente vistos como projetos de segunda classe, o que muitas vezes é em detrimento deles, talvez assim você ajuda a mudar essa percepção.

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

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

Sendo assim, na sua situação, você pode descobrir, ao introduzir isso, que os desenvolvedores que estão migrando do projeto mais recente para o projeto legado podem não estar felizes, então é necessário que haja uma comunicação muito clara sobre o motivo pelo qual isso está acontecendo e quanto tempo é, 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 como destacar as pessoas para um rebaixamento (o que algumas pessoas podem ver).

    

Concordo com Aaronaught que é muito estranho ver quantas pessoas simplesmente não vêem desvantagens. Poucos pensam mal, que você pode apontar muito rápido - código não tem dono e quando todo mundo é responsável por tudo não é tão bom para a qualidade. Os desenvolvedores não são recursos (mesmo que eles são chamados assim com muita frequência pelos gerentes), eles são pessoas e para a equipe é muito importante conhecer uns aos outros, a rotação faz um pouco de caos lá. Se você trabalha para algum projeto por mais tempo, você se tornará um especialista (não apenas no domínio, mas nesse projeto), você saberá de onde vieram os problemas, quem obterá melhores respostas ou talvez algum conhecimento de domínio mais específico etc. Se você é novo, precisará aprender tudo o que pensa, por isso vai atrasar 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 estão relacionados de alguma maneira, por exemplo, um projeto é insumo para outro (não necessário diretamente), por isso vai ter uma melhor compreensão do panorama geral. E, é claro, espalhar conhecimento é bom (se você tiver tempo para obter esses conhecimentos).

    

TL; DR Crie uma equipe e, em seguida, uma equipe que apóia dois projetos.

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

Por outro lado, se houver um esforço conjunto para unir as duas equipes em uma equipe e tivermos dois projetos de suporte à equipe, acho que isso funciona muito bem, desde que a equipe não seja muito grande. Eu fiz parte de várias equipes que apoiam vários projetos. Quanto mais próximos da tecnologia os dois projetos forem, mais fácil será a transição. Na minha experiência, o custo mais elevado na transição de um projeto para outro ocorre quando se cruzam idiomas, cliente / servidor (especialmente GUI), indústria (médica, web, jogos) ou outras linhas semelhantes. O truque é fazer com que pessoas diferentes trabalhem no projeto com frequência suficiente para obter os benefícios, mas não com tanta frequência que o custo de transição exceda os benefícios.

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

    

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

Da empresa em potencial

1. O gerenciamento saberá, a força e a fraqueza de um desenvolvedor específico, se ele pode manipular multitarefas ou não e se adaptar às mudanças.
2. Se algum desenvolvedor sair da empresa por algum motivo, a empresa já terá o backup pronto para o futuro.
3. Melhorará o desempenho do projeto, pois muitas pessoas trabalharão nele, a mesma coisa será testada por mais e mais desenvolvedores. (Testando o desperdício de recursos minimizado)
4. Todos os membros da equipe trabalham em equipe e isso irá impulsionar o desempenho do projeto e, no futuro, a gerência saberá que tipo de equipe precisa ser feito durante a implementação de um módulo ou tarefa difícil.

Do desenvolvedor em potencial

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

Apenas uma coisa importante, é preciso ter em mente que

A rotação de programadores não deve acontecer com muita frequência. depois de 60% - 70% de desenvolvimento feito, então apenas a mudança será benéfica.