Faire tourner des développeurs sur un projet est-il une bonne ou une mauvaise idée?

38

Je travaille sur une petite équipe qui va commencer à travailler sur un nouveau grand projet avec une autre petite équipe. L’autre équipe travaille actuellement sur un système existant sur lequel elle travaille depuis des années.

Le responsable a décidé que les développeurs de mon équipe effectueraient une rotation tous les quelques mois pour remplacer les développeurs travaillant sur le système hérité. Ainsi, l’autre équipe aura la possibilité de travailler sur le nouveau projet et de mieux comprendre le nouveau système.

Je souhaite connaître les avantages et les inconvénients (le cas échéant) de la rotation des développeurs du projet tous les 2-3 mois.

Je sais qu'il s'agit d'une question similaire à celle-ci: "La rotation du développeur principal est-elle une bonne ou une mauvaise idée?" , mais cette question concerne un développeur principal. Cette question concerne la rotation de l’ensemble de l’équipe sur le projet (le responsable technique du nouveau projet peut ne pas être remplacé - je ne sais pas encore).

Christian P
la source
2
Il y a une question à ce sujet chez ProjectManagement StackExchange - Connaissez-vous des entreprises qui font tourner les développeurs entre différents projets sur une base régulière?
Spoike
2
Je n'ai pas l'habitude d'en faire une question subjective / argumentative en donnant mon opinion personnelle à la question. Mon sentiment est que ce n'est pas une bonne idée, mais peut-être qu'il y a quelque chose que je ne sais pas :)
Christian P
1
Quelle raison le responsable a-t-il donnée quand vous lui avez demandé pourquoi? Il est dans l'intérêt d'une entreprise de partager la connaissance d'un produit au cas où les développeurs s'en iraient.
Dcaswell
1
C'est un problème. Si votre direction n’est pas déjà complètement transparente à ce sujet, c’est probablement un signe qu’ils n’ont pas réfléchi du tout.
Aaronaught
1
Ce que je suggérerais, c’est que vous fassiez partie de l’équipe initiale qui commence le projet et qui est composée de certains développeurs actuels et de nouveaux développeurs. Gardez-les à travers le projet. À la fin, les développeurs lagacy prennent en charge le nouveau produit et les nouveaux développeurs se joignent à d'autres développeurs existants pour réaliser le prochain projet. De cette façon, l’équipe reste la même à travers le projet (ou la version majeure), mais les personnes habituées se familiarisent avec ce qu’elles soutiendront plus tard. Les nouvelles recrues devraient généralement être léguées à moins d’avoir une compétence particulière que votre équipe n’a pas besoin de faire pour le projet.
HLGEM

Réponses:

76

Je suis surpris que tout le monde pense que c'est une si bonne chose. Les auteurs de Peopleware (qui, IMO, est encore l’un des rares ouvrages précieux sur la gestion de projets logiciels qui méritent d’être lus) méritent vraiment l’ opposition . Presque toute la partie IV du livre est consacrée à cette question.

L' équipe logicielle est une unité fonctionnelle extrêmement importante. Les équipes ont besoin de jell pour devenir vraiment productives. Il faut du temps ( beaucoup de temps) pour que les membres de l'équipe gagnent le respect de chacun, apprennent les habitudes et les bizarreries de chacun, ainsi que leurs forces et leurs faiblesses.

Personnellement, par expérience personnelle, je peux dire qu’après une année de travail avec certaines personnes, j’ai appris à rire de certaines choses qui me raillaient jadis, mes estimations en tant que chef d’équipe sont bien meilleures, et il n’est pas trop difficile de Faites distribuer le travail de manière à rendre tout le monde heureux. Ce n'était pas comme ça au début.

Maintenant, vous pourriez dire: "Oh, mais nous ne séparons pas toute l'équipe, nous ne faisons que déplacer quelques personnes." Mais considérez (a) à quel point leurs remplaçants seront aveuglément improductifs au début, et (b) combien de fois vous vous retrouverez, vous ou une autre équipe, à dire, sans même penser, "J'ai vraiment aimé X" ou "Cela aurait toujours plus facile avec Y " , offensant subtilement et inconsciemment les nouveaux membres et créant des schismes au sein de l’équipe existante, semant même le mécontentement des" anciens "membres.

Les gens ne le font pas exprès , bien sûr, mais cela se produit presque à chaque fois. Les gens le font sans réfléchir. Et s’ils s’y obligent, ils finissent par se concentrer davantage sur la question et sont frustrés par le silence forcé. Les équipes et même les sous-équipes vont développer des synergies qui se perdent lorsque vous vissez la structure. Les auteurs de Peopleware appellent cela une forme de "teamicide".

Cela étant dit, même si la rotation des membres de l'équipe est une pratique horrible, la rotation des équipes elles - mêmes est parfaitement satisfaisante. Bien que les sociétés de logiciels bien gérées devraient avoir une certaine notion de propriété du produit, il n’est pas aussi dérangeant pour une équipe de la transférer dans un projet différent, à condition que l’équipe ait réellement la possibilité de terminer l’ancien projet ou du moins de l’apporter. un niveau dont ils sont contents.

En ayant des relais d' équipe au lieu de relais de développeur , vous obtenez les mêmes avantages que ceux attendus des développeurs en rotation (documentation, "pollinisation croisée", etc.) sans les effets secondaires désagréables sur chaque équipe. Pour ceux qui ne comprennent pas vraiment la gestion, cela peut sembler moins productif, mais soyez assuré que la perte de productivité résultant de la scission de l'équipe est totalement inférieure à la perte de productivité résultant du déplacement de cette équipe vers un projet différent.

PS Dans votre note de bas de page, vous indiquez que le responsable technique peut être la seule personne à ne pas faire l'objet d'une rotation. C'est à peu près garanti de gâcher les deux équipes. Le responsable technique est un leader et non un manager. Il doit gagner le respect de l'équipe et ne doit pas simplement être autorisé par des niveaux de gestion supérieurs. Confier toute une équipe à la direction d'un nouveau responsable avec lequel ils n'ont jamais travaillé et qui risque fort d'avoir des idées différentes sur l'architecture, la convivialité, l'organisation du code, l'estimation, etc. pour le leader essayant de construire une crédibilité et très improductif pour les membres de l'équipe qui commencent à perdre de la cohésion en l'absence de leur ancien leader. Parfois, les entreprises ontfaire cela, c’est-à-dire si le prospect quitte ou obtient une promotion, mais le faire par choix semble insensé.

Aaronaught
la source
2
Ne désapprouvez absolument pas - même si ce n’est pas sans défauts - les équipes peuvent et doivent construire des empires, parfois ceux-ci se désagrègent. La productivité n’est pas toujours le but le plus important d’un mangeur autre pourrait être.
mattnz
4
@mattnz: Quel "jeu final" existe-t-il pour un gestionnaire autre qu'une productivité élevée, la rétention des employés et la possibilité de livrer dans les délais / dans le budget? Je parle ici bien sûr de responsables éthiques , qui souhaitent véritablement faire ce qu’il ya de mieux pour la société et n’utilisent pas l’équipe ou le projet comme un moyen de poursuivre leurs objectifs de carrière personnels. Une entreprise de logiciels veut des empires - les empires sont stables et rapportent de l'argent - et oui, les empires peuvent tomber, mais ils sont beaucoup moins susceptibles de tomber qu'un château de cartes.
Aaronaught
2
la rotation est meilleure que les gens qui quittent la société entièrement
warren
4
@ Warren: Si ces deux options sont vos seules, alors la dernière est presque inévitable.
Aaronaught
3
Je ne comprends vraiment pas cette réponse du tout. Tous les membres d'une équipe doivent être des professionnels et bien travailler avec les autres, à supposer que tous les membres de l'équipe soient réellement compétents, ce qui pose un problème différent. La rotation des membres de l’équipe est souvent le seul choix possible pour un responsable qui manque de personnel de manière chronique dans les deux produits ou dont l’attrition constitue une menace sérieuse. Il est souvent très difficile de trouver un bon talent en premier lieu. La rotation des membres de l'équipe est un moyen de couvrir les paris contre les développeurs qui partent. Il est également plus équitable que les développeurs travaillent sur des logiciels existants lorsqu'ils souhaitent apprendre quelque chose de nouveau.
maple_shaft
18

Je ne vois pas beaucoup d'inconvénient ici moi-même. La rotation vous obtient:

  • Pollinisation croisée des connaissances institutionnelles - tout le monde connaît le projet d'héritage et le nouveau, du moins en théorie.
  • Formation croisée - différents projets exigent souvent des choses différentes. Vous vous développez beaucoup plus en tant que développeur travaillant dans des projets laids et hérités que dans des projets nouveaux et propres.
  • Des projets fondamentalement meilleurs - rien de tel qu'une nouvelle équipe pour vous aider à terminer la documentation et à nettoyer les processus laids avec lesquels vous êtes prêt à vivre mais que vous n'admettrez pas publiquement.
  • Meilleur code - plus de têtes sont meilleures dans la plupart des cas.
  • Améliorations probables du moral - la variété est le parfum de la vie. Et qui veut rester bloqué dans le mode de correction des bogues du projet hérité / enregistrement des gaines en permanence. N'oubliez pas non plus que votre "nouveau" projet deviendra un jour un héritage. Voulez-vous y rester à jamais?

Le seul inconvénient est sans doute la baisse de productivité que vous subissez lorsque vous changez de lieu, mais cela ne devrait que faire mal au premier tour. Ensuite, les deux parties auront du temps aux deux endroits et les parties laides du transfert seront probablement mieux comprises et peut-être résolues.

Wyatt Barnett
la source
18
Je ne vois pas comment mon moral s’améliorerait si je devenais «rétrogradé» pour travailler sur le système existant.
Telastyn
3
Quelques inconvénients sont le temps de développement initial et les autres tâches spécifiques de l'équipe héritée ayant des priorités moins élevées.
Oded
16
@Telastyn Si mon ancienne société avait cessé ses activités, je continuerais à travailler là-bas. Bien sûr, c’est chiant de faire tourner, mais c’est encore plus grave de savoir que vous ne serez jamais virés simplement parce qu’ils ont besoin d’un outil de développement traditionnel.
BeardedO
8
@Telastyn et Christian et d'autres: C'est votre problème si vous le voyez comme une rétrogradation. Travailler sur des systèmes hérités est un défi en soi qui peut vous donner une expérience extrêmement précieuse à utiliser à votre avantage dans le développement de champs verts. Le développement de Greenfield devrait avoir beaucoup moins de "crédibilité" qu’il en a, car il est beaucoup plus facile que de tenter de créer de nouvelles fonctionnalités sur une base existante, même sans dette technique importante. Le développement du champ brun est l'endroit où vous trouvez les vrais artisans. Oui, vous les trouvez ailleurs aussi, mais pas ceux qui sont durs sur le champ de bataille.
Marjan Venema
8
@MarjanVenema - Désolé, des travaux d'entretien à Cobol ne vont pas faire avancer ma carrière. Bien sûr, il se peut que le travail doive être fait et que cela puisse même constituer une expérience précieuse - mais si mon responsable me change de poste à plein temps, mon CV sera publié dès que possible. Le fait est que certains développeurs vont percevoir cela comme une rétrogradation, peu importe ce que c'est. Équilibrer cette perception avec le désir de pollinisation croisée n'est pas mon problème, c'est le problème du gestionnaire; c'est leur travail .
Telastyn
6

Fait intéressant, selon mon expérience, nous avons souvent commencé nos projets avec cette intention même. En fin de compte, nous avons souvent omis de concrétiser cette intention en raison des contraintes imposées au nouveau projet et de la conviction que la formation croisée coûte trop cher.

J’espère toujours que nous y sommes parvenus, car à long terme, j’estime qu’il est avantageux pour toutes les parties - équipe, entreprise, client et logiciel. 2/3 mois semble être une période suffisamment longue pour que le risque d’impact négatif important soit limité. Il n’ya pas de changement de contexte pour les développeurs impliqués, sauf au moment du basculement, où ils peuvent se consacrer au projet alternatif.

Quelques avantages possibles non mentionnés:

  • Meilleure gestion de projet. Si les chefs de projet des deux projets sont à bord, il est de leur intérêt de travailler dur pour que les périodes de transition ne soient pas pénibles pour l'un ou l'autre projet. C’est à son tour (en fonction de votre configuration) de permettre une collaboration plus étroite entre les chefs de projet et les équipes de développement.
  • Meilleure documentation (proactive). Si vous savez que vous êtes en train de changer de projet, ce n'est pas seulement dans le meilleur intérêt du projet, le meilleur intérêt des entreprises, des meilleures pratiques en général, mais aussi dans le meilleur intérêt de chaque développeur de rendre la vie facile tout en rebondissant. environ.
  • Le moral est un gros problème. Si vos développeurs n'en ont pas marre de rester sur un projet hérité, ils ne sont peut-être pas les développeurs que vous souhaitez! S'ils le font, le fait de les changer et de faire travailler d'autres développeurs leur donnera le sentiment d'être amoureux de votre entreprise - ils pourraient bien ranger les morceaux de code qu'ils pensaient que personne ne verrait jamais aussi bien. Les systèmes hérités sont souvent considérés comme des projets de deuxième classe, ce qui leur nuit souvent au détriment de cette possibilité.
JohnMark13
la source
Je pense que c'est comme ça que ça se passe dans la plupart des entreprises. Des objectifs ambitieux, mais les exigences de redressement rapide et d’évitement minimal des coûts immédiats excluent généralement la formation croisée et le développement croisé en raison de la perte de productivité liée à la mise au courant rapide des projets.
BBlake
2
@BBlake Oui, malheureusement, c'est le cas. C'est regrettable, car il est très risqué pour une entreprise de "restreindre" la connaissance de systèmes importants à un nombre inférieur de personnes.
Marjan Venema
1
Malheureusement, la plupart des entreprises, y compris la grande banque mondiale que j'ai récemment quitté pour travailler ailleurs, sont plus intéressées par le résultat net de ce projet ou de ce cycle de la semaine ou de ce cycle budgétaire que par la planification des coûts à prévoir lorsqu'un développeur senior ( comme moi) part. Avec aucun budget pour la formation croisée sur les applications seulement, j'avais une connaissance avancée de. Ajoutez à cela des dizaines d’heures de travail perdues à localiser des problèmes de production que j’aurais pu résoudre en quelques heures à cause de la connaissance des systèmes. À courte vue, mais c'est la manière d'entreprise.
BBlake
@Marjan: Je serais prêt à parier que les coûts liés à la formation croisée régulière seront de loin supérieurs aux coûts de formation d'un nouvel employé si nécessaire. Maintenant, si toute une équipe quitte, c'est une autre affaire.
Dunk
1
@Dunk: Je ne sais pas ce qui se passerait. L’entraînement croisé n’a pas à aller aussi loin que de faire de l’entraîneur formé un expert du domaine qui n’est pas directement le sien. Cela doit seulement aller jusqu'à faire en sorte que l'entreprise ne soit pas immédiatement prise au dépourvu et risque de perdre des clients lorsque les experts sur le terrain partent, ce qui bloque le développement de ce secteur. Personne n'est irremplaçable, mais les entreprises courent des risques lorsque des connaissances ou des compétences importantes sont limitées à très peu de personnes. Et les coûts pour que ce risque devienne une réalité peuvent être très très élevés.
Marjan Venema
4

La rotation est une bonne chose pour l'entreprise et peut également l'être pour les développeurs.

Il y a beaucoup de bonnes raisons et Wyatt en a mentionné beaucoup dans sa réponse.

Cela étant dit, dans votre cas, vous constaterez peut-être qu'en introduisant ce projet, les développeurs qui passent du projet plus récent au projet hérité risquent de ne pas être heureux, il est donc nécessaire de bien expliquer pourquoi cela se produit et combien de temps est pour, et le plan pour aller de l'avant.

Il serait peut-être bon de penser à ne pas échanger les équipes en bloc pour commencer et à faire pivoter 1 ou 2 développeurs pour commencer, bien que cela puisse sembler être une rétrogradation (que certaines personnes pourraient voir).

ozz
la source
J'aime l'idée d'échanger juste un ou deux développeurs pour commencer. Cela aidera à réduire l’impact négatif initial sur la productivité.
SuperM
Vous avez affaire à des développeurs de logiciels, pas à des gens normaux. Les développeurs de logiciels ont tendance à être logique. Ils ne peuvent pas être manipulés aussi facilement que le grand public en incorporant des idées telles que celles mentionnées ci-dessus. D'autres astuces sont plus efficaces sur eux (par exemple, des moniteurs plus volumineux, des ordinateurs plus rapides), mais pas de chicane politique comme cette idée tente de le faire. Ce sera un inconvénient pour les membres de la nouvelle équipe de développement, quoi qu'il arrive. Les promesses de récompenses (voir ci-dessus) sont à peu près le seul moyen de dissimuler le mauvais goût. Bien sûr, ce sera génial (au début) pour les mainteneurs, jusqu'à ce qu'ils réalisent qu'ils ne sont pas prêts.
Dunk
2

D'accord avec Aaronaught, il est très étrange de voir combien de personnes ne voient tout simplement pas d'inconvénients. Peu de méchants pensent que l'on peut pointer très vite - le code n'a pas de propriétaire et quand tout le monde est responsable de tout, la qualité n'est pas bonne . Les développeurs ne sont pas des ressources (même s'ils sont appelés ainsi très souvent par les responsables), ce sont des personnes et pour l'équipe, il est très important de se connaître, la rotation y crée un peu de chaos. Si vous travaillez pour un projet plus longtemps, vous deviendrez un expert (non seulement dans le domaine, mais dans ce projet), vous saurez d'où vient la plupart des problèmes, qui vous obtiendra les meilleures réponses ou peut-être des connaissances de domaine plus spécifiques, etc. Si vous êtes nouveau, vous devrez apprendre tout ce que vous pensez, cela ralentira donc les progrès. Mais bien sûr, il est également bon de connaître les autres pratiques de votre organisation, comment d'autres équipes construisent et organisent. Il est particulièrement utile que vos projets soient liés d'une manière ou d'une autre. Par exemple, un projet est associé à un autre (pas nécessairement directement), ce qui vous permettra de mieux comprendre la situation dans son ensemble. Et bien sûr, la diffusion de l’expertise est bonne (si vous aurez le temps d’obtenir ces connaissances).

Dainius
la source
Cet article est plutôt difficile à lire (mur de texte). Pourriez - vous l' esprit modifier ing dans une meilleure forme?
moucher
2

Je suis d'accord avec la réponse principale d'Aaronaught et j'ai quelques ajouts.

  • Les gens n'aiment pas être forcés.
  • Dans un contexte commercial hiérarchique, des responsabilités peuvent être attribuées à des personnes qui leur sont ultérieurement retirées. Cela peut juste faire partie du travail. Cependant, plus cela se produit souvent, moins ces personnes se sentiront responsables de tout ce qui leur est attribué.
  • Le premier point s’applique également aux travaux d’entretien sur des choses que les gens eux-mêmes n’ont pas créées. Nettoyer le désordre des autres (ou plus neutre: travail inachevé) n'est pas particulièrement motivant pour la plupart des créateurs.
  • La philosophie "un programmeur est un programmeur est un programmeur, ce sont des plug-ins anonymes à insérer dans les projets en fonction des besoins" ne permet à aucun programmeur de se sentir apprécié ou de se soucier davantage des tâches qui lui sont assignées.

Le moment idéal pour réaffecter quelqu'un, c'est quand ils commencent à s'ennuyer de ce qu'ils font. Il n'y a plus rien à gagner, tout est sous contrôle, le travail est fait. Dans ce cas, ils se présentent généralement et demandent eux-mêmes d'autres opportunités.

Bien sûr, la réalité est têtue et souvent, il n’ya pas de choix. Quelqu'un peut être nécessaire ailleurs, pour une raison quelconque. Ce n'est pas forcément mauvais, cela peut aussi donner l'impression qu'une personne est importante et si elle doit résoudre un gros problème, elle aura un crédit.

Le simple fait de déplacer les gens pour diffuser des connaissances va probablement augmenter le taux de roulement. De cette façon, les connaissances seront diffusées, mais elles le seront à l’extérieur de la société, ce qui n’est probablement pas l’intention.

Martin Maat
la source
0

TL; DR Faites-en une équipe, puis une équipe de soutien de 2 projets.

Pour faire écho à @Aaronaught, je pense que le mélange d’équipes peut être problématique, car il faut du temps pour s’acclimater à de nouvelles pratiques, processus, etc. Si vous faites tourner trop de personnes pour qu’elles perdent rapidement leur identité, l’équipe perdra son identité. Cela conduit à plus de questions, de confusion et de temps passé à essayer de rattraper cette identité.

D'un autre côté, s'il y a un effort concerté pour réunir les deux équipes en une seule et avoir un soutien d'équipe pour deux projets, je pense que cela fonctionne très bien tant que l'équipe n'est pas trop grosse. J'ai fait partie de nombreuses équipes qui soutiennent plusieurs projets. Plus la technologie est proche des 2 projets, plus la transition est facile. D'après mon expérience, le coût élevé de la transition d'un projet à un autre vient lorsque l'on croise des langues, un serveur / client (en particulier une interface graphique), un secteur (médical, Web, jeux) ou d'autres lignes similaires. L'astuce consiste à amener suffisamment de personnes à travailler sur le projet assez souvent pour en retirer des avantages, mais pas aussi souvent que le coût de la transition dépasse les avantages.

Les avantages d’attirer un plus grand nombre de personnes sur un projet sont assez bien connus, de même que les coûts.

dietbuddha
la source
1
"Tant que l'équipe n'est pas trop grande" est la clé ici, je pense; Si chaque équipe compte 10 personnes, une équipe de 20 personnes est probablement trop grosse. De plus, s'il existe une séparation physique entre les équipes (le PO ne spécifie pas), elle ne fonctionnera pas comme une seule équipe et rendra les choses plus désorganisées. Cela pourrait fonctionner, mais cela dépend de la situation (les équipes peuvent être fusionnées efficacement) et des objectifs de la direction (la fusion est plus ou moins permanente, cela ajoutera plus de ressources, mais n'atteindra pas les mêmes objectifs qu'un projet. rotation).
Aaronaught
0

La rotation des programmeurs est une bonne chose du point de vue de l’entreprise et du développeur.

Du point de vue de l'entreprise

  1. La direction apprendra quels sont les points forts et les points faibles d'un développeur, qu'ils soient capables de gérer plusieurs tâches ou non et de s'adapter aux changements.
  2. Si un développeur quitte l'entreprise pour une raison quelconque, l'entreprise dispose déjà d'une sauvegarde prête pour l'avenir.
  3. Cela améliorera les performances du projet, car de nombreuses personnes y travailleront, la même chose sera testée par de plus en plus de développeurs. (Test de gaspillage des ressources minimisé)
  4. Tous les membres de l'équipe travaillent en équipe, ce qui augmentera les performances du projet et, à l'avenir, la direction apprendra quel type d'équipe doit être constitué lors de la mise en œuvre d'un module ou d'une tâche difficile.

Du point de vue du développeur

  1. Cela rendra le développeur plus positif à mesure que sa confiance augmentera.
  2. Les développeurs obtiennent de meilleures idées de la part des autres membres du code d'équipe et peuvent utiliser cette technique lors de futurs développements.
  3. De meilleures idées et suggestions d’autres membres de l’équipe, la productivité des développeurs augmente.

Une seule chose principale, il faut garder à l’esprit que,

La rotation des programmeurs ne devrait pas être très fréquente. après 60% à 70% du développement effectué, seul le déplacement sera bénéfique.

Pragnesh Karia
la source
3
Je vois beaucoup d'assertions chauves faites ici. Certains n'ont presque rien à voir avec la rotation ("la direction apprendra à connaître les forces et les faiblesses de chaque développeur"?), D'autres sont mal définis ou n'ont tout simplement aucun sens ("tous les membres de l'équipe travaillent en équipe et cela augmentera la performance du projet "?). Sur quoi sont basés tous ces points? Avez-vous une source? Est-ce une expérience personnelle? Si oui, quelle expérience? Votre "perspective d'entreprise" provient-elle de votre expérience de manager ou de chef d'équipe? Avez-vous vraiment vu l'une de ces choses fonctionner dans la pratique?
Aaronaught
1
La plupart des avantages proposés semblent en réalité être simplement liés au fait de faire partie d'une équipe et non d'une rotation entre équipes ...
Aaronaught
Le premier "La direction va apprendre à connaître la force et la faiblesse de chaque développeur." C’est en fait l’opposé, car c’est beaucoup plus facile de cacher ses faiblesses lorsqu’on se déplace d’un endroit à un autre, il ya toujours plus de gens / logiciels à blâmer, pourquoi il était tard, buggy, pas fait.
Dainius
Il n'y a aucun moyen en h ... que la performance du projet ne subisse pas un impact très négatif. Pourquoi croyez-vous que la performance d'un projet serait "améliorée"?
Dunk