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


38

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).


2
Há uma dúvida sobre isso no ProjectManagement StackExchange - Você conhece alguma empresa que
Spoike 6/09/13

2
Eu não costumava transformar isso em questão subjetiva / argumentativa, dando minha opinião pessoal na questão. Minha intuição é que esta não é uma boa ide, mas talvez há algo que eu não sei sobre :)
Christian P

1
Que razão o gerente deu quando você perguntou por que? É do interesse de uma empresa compartilhar conhecimento compartilhado sobre um produto, caso os desenvolvedores saiam.
dcaswell

1
Isso é um problema. Se o seu gerenciamento ainda não está sendo completamente transparente sobre isso, é provavelmente um sinal de que eles ainda não pensaram nisso.
Aaronaught

1
O que eu sugeriria é que você faça a equipe inicial que inicia o projeto composta por alguns devlopers legados atuais e alguns novos devlopers de projetos atuais. Mantenha-os através do objeto. No final, os devlopers de lagacy suportam o novo produto e os novos devlopers se juntam a outros desenvolvedores legados para fazer o próximo projeto. Dessa forma, a equipe é a mesma através do projeto (ou versão principal), mas as pessoas herdadas se adiantam no que apoiarão mais tarde. Os novos contratados geralmente começam com legado, a menos que possuam alguma habilidade especial que sua equipe não tenha necessidades para o projeto.
HLGEM

Respostas:


76

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.


2
Não discorde totalmente - por mais que isso não exija falhas - as equipes podem e constroem impérios, às vezes essas ruínas Produtividade nem sempre é o objetivo mais importante de uma manjedoura, que (se é que é boa), está olhando mais para o final do jogo do que outro pode ser.
mattnz

4
@mattnz: Que "jogo final" existe para um gerente que não seja a alta produtividade, a retenção de funcionários e a capacidade de entregar dentro do prazo / orçamento? Estou falando de gerentes éticos aqui, é claro, que realmente querem fazer o melhor para a empresa e não estão usando a equipe ou o projeto como veículo para promover seus próprios objetivos pessoais de carreira. Uma organização de software deseja impérios - impérios são estáveis ​​e ganham dinheiro - e sim, impérios podem cair, mas são muito menos propensos a cair do que um castelo de cartas.
Aaronaught

2
rotação é melhor do que as pessoas que deixam a empresa inteiramente
Warren

4
@warren: Se essas duas opções são suas únicas, a última é quase inevitável.
Aaronaught 9/09/13

3
Eu realmente não entendo essa resposta. Todo mundo em uma equipe deve ser profissional e trabalhar bem com outras pessoas, assumindo que todos os membros da equipe são realmente competentes, o que é um problema diferente. Os membros rotativos da equipe geralmente são a única opção para um gerente com insuficiência crônica de recursos em ambos os produtos ou onde o desgaste representa uma ameaça séria. Geralmente, é muito difícil encontrar bons talentos em primeiro lugar. A rotação de membros da equipe é uma maneira de proteger as apostas contra a saída dos desenvolvedores. Também é mais justo para os desenvolvedores que trabalham com software legado quando desejam aprender algo novo.
Maple_shaft

18

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.


18
Não vejo como minha moral melhoraria se eu fosse "rebaixado" para trabalhar no sistema legado.
Telastyn

3
Algumas desvantagens estão no tempo inicial de desenvolvimento e as outras tarefas específicas da equipe herdada recebem prioridades mais baixas.
Oded

16
@Telastyn Se minha empresa antiga tivesse saído do trabalho legado, eu ainda estaria trabalhando lá. Claro que é péssimo rodar, mas é ainda mais difícil saber que você nunca será rodado simplesmente porque eles precisam de um desenvolvedor legado.
precisa saber é o seguinte

8
@Telastyn, Christian e outros: o problema é seu se você vê isso como um rebaixamento. Trabalhar em sistemas legados é, por si só, um desafio que pode proporcionar uma experiência incrivelmente inestimável para usar em seu benefício no desenvolvimento de campos verdes. O desenvolvimento greenfield realmente deve ter muito menos "cred" do que tem, pois é muito mais fácil do que tentar criar novos recursos em uma base existente, mesmo que sem muita dívida técnica. O desenvolvimento do campo marrom é onde você encontra os verdadeiros artesãos e mulheres. Sim, você os encontra em outros lugares também, mas não no campo de batalha endurecido.
Marjan Venema

8
@MarjanVenema - Desculpe, fazer alguns trabalhos de manutenção em Cobol não vai avançar na minha carreira. Claro, o trabalho pode precisar ser feito e pode até ser uma experiência valiosa - mas se meu gerente me mudar para esse período integral, terei meu currículo o mais rápido possível. O fato da questão é que alguns desenvolvedores vão perceber isso como um rebaixamento, independentemente do que ele realmente é. Equilibrar essa percepção com o desejo de polinizar cruzadamente não é problema meu, é problema do gerente; esse é o trabalho deles .
Telastyn

6

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.

Eu acho que é assim que acaba na maioria das empresas. Objetivos elevados, mas as demandas de resposta rápida e redução de custos imediata mínima geralmente impedem o treinamento e o desenvolvimento cruzados devido à produtividade perdida de trazer alguém novo para acelerar um projeto.
precisa saber é o seguinte

2
@Blake Sim, infelizmente é esse o caso. Infelizmente, porque é um risco muito míope e bastante alto para uma empresa "restringir" o conhecimento de sistemas importantes a um número menor de pessoas.
Marjan Venema

1
Infelizmente, a maioria das empresas, incluindo o principal banco mundial que deixei recentemente para trabalhar em outros lugares, está mais interessada nos resultados deste projeto, no ciclo semanal ou orçamentário, do que no planejamento antecipado dos custos que ocorrerão quando um desenvolvedor sênior ( como eu) sai. Sem orçamento para treinamento cruzado em aplicativos, apenas eu tinha familiaridade avançada. Adicione as dezenas de horas de trabalho perdidas rastreando os problemas de produção que eu poderia resolver em algumas horas porque conhecia os sistemas. Míope, mas essa é a maneira corporativa.
BBlake

@Marjan: eu gostaria de apostar que os custos incorridos com a realização de treinamento cruzado regularmente serão muito, muito mais altos do que os custos de treinamento de um novo contratado, conforme necessário, se alguém sair. Agora, se uma equipe inteira sair, isso é outra questão.
quer

1
@ Dunker: Eu não sei o que faria. O treinamento cruzado não precisa ir tão longe quanto tornar a cruz treinada como especialista no campo que não é diretamente seu. Ele só precisa ir tão longe quanto garantir que a empresa não fique imediatamente em perigo e correndo o risco de perder clientes quando os especialistas em campo saírem, fazendo com que o desenvolvimento nesse campo seja interrompido. Ninguém é insubstituível, mas os negócios correm riscos quando conhecimentos ou habilidades importantes são restritos a muito poucas pessoas. E os custos desse risco de se tornar realidade podem ser muito, muito altos.
Marjan Venema

4

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).


Eu gosto da idéia de trocar apenas 1-2 desenvolvedores para começar. Isso ajudará a reduzir o impacto negativo inicial na produtividade.
SuperM

Você está lidando com desenvolvedores de software, não com pessoas normais. Os desenvolvedores de software tendem a ser lógicos. Eles não podem ser tão facilmente manipulados quanto o público em geral, incorporando idéias como as descritas acima. Outros truques são mais eficazes neles (por exemplo, monitores maiores, computadores mais rápidos), mas não a linguagem política, como essa idéia está tentando fazer. Será negativo para os membros da nova equipe de desenvolvimento, não importa o quê. Promessas de recompensas (ou seja, veja acima) são a única maneira de encobrir o mau gosto. Claro, será ótimo (a princípio) para os caras da manutenção, até que eles percebam que não estão preparados para isso.
quer

2

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).


é difícil ler este post (parede de texto). Você se importaria de editá -lo em uma forma melhor?
Gd #

2

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.


0

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.


1
"Contanto que a equipe não seja muito grande" é fundamental aqui, eu acho; se cada equipe tem 10 pessoas, é provável que uma equipe de 20 pessoas seja muito grande. Além disso, se houver alguma separação física entre as equipes (o OP não especifica), ele não funcionará como uma única equipe e tornará as coisas mais desorganizadas. Definitivamente , isso pode funcionar, mas depende da situação (as equipes podem ser fundidas de maneira eficaz) e também dos objetivos da gerência (a fusão é mais ou menos permanente, adicionará mais recursos, mas não alcançará os mesmos fins que um projeto rotação).
Aaronaught

0

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.


3
Eu vejo muitas afirmações carecas sendo feitas aqui. Alguns deles não têm quase nada a ver com rotação ("a gerência conhecerá a força e a fraqueza de um desenvolvedor em particular"?), Outros têm frases desajeitadas ou simplesmente não fazem sentido ("todos os membros da equipe trabalham em equipe e isso aumentará o desempenho do projeto "?). Em que todos esses pontos se baseiam? Você tem uma fonte? É uma experiência pessoal? Se sim, que experiência? A sua "perspectiva da empresa" vem da experiência como gerente ou líder de equipe? Você realmente viu alguma dessas coisas funcionar na prática?
Aaronaught

1
A maioria destes benefícios propostos realmente parecem estar relacionado com simplesmente estar em uma equipe em vez de ser girado entre equipes ...
Aaronaught

primeiro "A gerência conhecerá a força e a fraqueza de um desenvolvedor em particular". é realmente o oposto, porque é muito mais fácil esconder suas fraquezas quando você se desloca de um lugar para outro, sempre há mais pessoas / software para culpar, por que era tarde, de buggy, não terminado.
Dainius

Não há como ... o desempenho do projeto não será impactado negativamente. Por que você acreditaria que o desempenho de um projeto seria "aprimorado"?
quer
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.