La rotation du développeur principal est-elle une bonne ou une mauvaise idée?

Je travaille au sein d'une équipe qui est plate sur le plan organisationnel depuis sa création il y a plusieurs mois. Mon manager n'est pas technique et cela signifie que toute notre équipe est responsable de la prise de décision.

Mon manager commence à se rendre compte qu'il y a plusieurs avantages à avoir un développeur principal, à la fois pour lui (un seul point de contact et une seule partie responsable pour les tâches) et pour le nôtre (résolution des litiges, conseils techniques organisés, etc.).

Parce que l'équipe a été plate, une préoccupation est que le choix d'un développeur principal puisse décourager les autres. Un non-développeur a suggéré à mon responsable que la rotation du développeur principal était un moyen possible d'éviter ce problème. Un développeur serait conduit un mois, un autre le lendemain, etc.

Est-ce une bonne idée? Pourquoi ou pourquoi pas?

Gardez à l'esprit que cela signifie que tous les développeurs - Tous les développeurs sont bons, mais pas nécessairement également adaptés au leadership.

Et si ce n'est pas le cas , comment puis-je recommander que nous évitions cette approche sans donner l'impression que c'est simplement pour des raisons égoïstes?

Ne tournez pas.

Je ne pense pas que quiconque gagne quoi que ce soit grâce à la rotation de la position (à part ceux qui ne méritent pas d'être le chef de file pourraient obtenir plus d'argent qu'ils n'en reçoivent actuellement).

Avoir un développeur principal brillant qui peut faire ce qui suit fait des merveilles pour le processus de développement:.

1. Sait déléguer.
2. Est en contrôle.
3. Est un développeur expérimenté.

Il est une source unique pour le reste de l'équipe de rechercher et de demander conseil. Il est également le médiateur entre les cadres supérieurs et l'équipe de développement principale. Je ne connais aucune équipe de direction qui aime faire face au changement (à moins que ce soit eux qui l'instituent).

Si vous êtes vraiment le mieux placé pour ce poste, tout le monde le sait. Tout le monde le saurait (par exemple, la gestion de niveau supérieur, votre coéquipier, etc.). Dites que vous ne pensez pas que la rotation de la position en vaut la peine (si vous le croyez). Ensuite, asseyez-vous et laissez-les faire le rendez-vous - abstenez-vous de laisser tomber le nom ou toute sorte d'auto-promotion, car cela vous ferait paraître non professionnel

Être développeur principal comporte deux parties:

• Leadership technique Pour le leadership technique, il est logique de choisir un développeur principal différent au niveau du projet. Faites de chaque développeur un responsable technique pour un projet différent, en le tournant si nécessaire au fur et à mesure que les projets tournent. Ce type d'approche peut gérer la dynamique de l'équipe et s'assurer que tout le monde est correctement mis au défi

• Communication Un point de contact unique pour la communication avec le monde extérieur est bon pour le monde extérieur et mauvais pour le point de contact. Quiconque est coincé avec la balle de communication aura moins de temps pour faire un vrai travail et devra courir pour obtenir des informations de tout le monde à transmettre. Si vous êtes le meilleur communicateur et que vous êtes prêt à arrêter de faire autant de travail amusant en échange de toutes les discussions, plus de pouvoir pour vous.

Ce n'est pas nécessairement une mauvaise idée, à condition que les développeurs impliqués soient engagés et (idéalement) capables.

J'ai du mal à trouver des références pour cela (mais je continuerai à chercher), mais si je me souviens bien, certaines entreprises agiles le font - elles font tourner le titre de "chef d'équipe" soit à chaque itération, soit à un autre moment prédéfini période. Cela favorise l'implication des développeurs et donne à chacun une chance de faire une partie de la gestion d'équipe / communication externe sans déplacer définitivement un développeur de développer dans ce rôle.

Certains inconvénients incluent la perte potentielle d'informations (cela peut être atténué de plusieurs façons) et un potentiel plus élevé de «mauvais» leadership. Il peut également être difficile de maintenir une vision / direction pour l'équipe. Cependant, si tout le monde est d'accord avec cette approche et que les membres de l'équipe sont bien informés et intéressés à faire fonctionner un tel système, cela peut valoir la peine.

Si vous tournez, ne le faites pas pendant un projet. Il n'y a rien de intrinsèquement mauvais à attribuer différents rôles à différentes personnes pour différents projets, en fonction de la personne la plus appropriée dans chaque poste pour ce projet particulier. Mais ne faites pas de Joe "programmeur principal" juste parce que c'est son temps sur la liste pour effectuer le travail. Il n'est peut-être pas qualifié pour cela, il peut même ne pas vouloir le travail.

Faire tourner le développeur principal en fonction du temps est une mauvaise idée.

Tout le monde est un bon développeur ne signifie pas que tout le monde est un bon leader. Et l'un est un bon leader ne signifie pas qu'il convient au leader de ce programme.

Je pense que l'importance des missions assignées aux développeurs est différente, et le leadership de chaque développeur est différent. Je pense que vous pouvez conseiller à votre manager de tenir un vote. Chacun vote 2 personnes pour le meilleur candidat, et la personne qui obtient le plus de votes devrait être le développeur leader

Je suis enclin à convenir avec Jonathan Khoo que la rotation du développeur principal pourrait être une mauvaise idée. En général, pour les projets plus importants, il existe un seul responsable technique qui dirige le projet et cette personne peut avoir plusieurs responsables de composants qui lui rendent compte pour discuter de divers problèmes à l'échelle du système.

Cependant, un point important que Jonathan n'a pas mentionné est que le responsable technique développe également un niveau élevé de connaissances institutionnelles que d'autres sur le projet pourraient ne pas avoir. En faisant tourner le responsable technique, vous leur demandez de développer ces connaissances chaque fois que quelqu'un est nommé dans le poste. De plus, le responsable développera une relation avec les clients en dehors du projet, car ils devraient idéalement être présents pour certaines des réunions (plus importantes) avec les utilisateurs finaux.

Avoir un responsable technique est bien, mais si vous essayez de les faire pivoter, vous découvrirez peut-être que vous vous portez mieux sans.

Je pense que vous devez d'abord déterminer quel est le rôle de cette personne, plus que qui le fait et pour combien de temps.

Vous devez également déterminer si cela va changer considérablement la façon dont vous travaillez et si cela réduira vos performances. Avoir une seule personne doit «approuver» chaque ligne de votre code plutôt que n'importe quel pair, ce qui peut avoir un effet sérieux.

Différents rôles spécifiques peuvent être attribués à différents membres de l'équipe, sans qu'aucun d'entre vous ne soit «supérieur». Celui qui est le mieux à même de communiquer entre le gestionnaire et les autres peut se voir attribuer un rôle spécifique pour le faire, mais cela ne signifie pas qu'il est un "développeur principal", et ce n'est peut-être pas la personne qui est la meilleure techniquement ou la meilleure faire des revues de code.

Je serais prêt à parier que même si l'équipe est apparemment plate, il y a déjà un leader parmi eux, et ils le savent tous déjà.

Les organigrammes reflètent rarement la façon dont les gens travaillent réellement. Graphiques particulièrement idéalisés comme "une équipe plate".

Si votre organisation est plate, faites suivre à tous vos développeurs une formation sur l'analyse des exigences et des solutions (RSA) pour qu'ils suivent un processus formel. Vous pouvez ensuite affecter plusieurs experts en la matière (PME) à un projet et obtenir un processus documenté pour toutes les solutions.

De plus, puisque vous avez mentionné que le gestionnaire n'est pas technique, cette personne peut toujours piloter le processus RSA et faciliter la communication. Vous pouvez également désigner une PME en tant que chef de file, projet par projet, pour aider à la facilitation et développer ses compétences individuelles.

Pourquoi l'équipe de développement ne vote-t-elle pas anonymement? J'utiliserais le vote préférentiel.

1. Vous pouvez sélectionner quelqu'un dans votre équipe pour diriger votre équipe.
2. Votre patron peut embaucher une autre personne expérimentée pour occuper ce poste

PS Je ne pense pas que la rotation soit une bonne idée, la personne doit avoir des compétences en communication et avoir une bonne expérience dans la gestion d'une équipe.

Comme votre question le suggère, toute l'équipe est responsable de la prise de décision, je vous suggère de la garder de la même manière. Cependant, pour communiquer et signaler aux autorités extérieures à l'équipe, vous pouvez sélectionner un coordinateur d'équipe dans l'équipe. Ses responsabilités incluraient tout ce qui n'est pas technique. Pour tous les aspects techniques, l'équipe devrait s'asseoir et discuter de la même manière que vous le faites actuellement. Quelle que soit votre décision, elle sera communiquée au monde extérieur via le coordinateur . Cette position peut être pivotée facilement sur une base temporelle.

L'autre approche peut être d'avoir un développeur principal basé sur le niveau d'expérience> expérience sur le même projet> expérience dans la même entreprise. Et si besoin est, la position peut être tournée sur une base de phase à phase. Idéalement, chaque phase de développement a son propre ensemble d'exigences et de livrables, qui peuvent être planifiés et travaillés comme un mini-projet. Avoir une piste différente pour chaque phase minimiserait presque tous les impacts négatifs de la rotation.

Au lieu d'avoir un développeur principal en rotation, ayez un chef de projet en rotation, quelqu'un qui a le plus de connaissances et de compréhension pour mener à bien le projet x.

Le développeur principal est généralement une promotion et doit être mérité.

Mais pour aider à former et à développer des compétences en leadership, permutez qui est en charge des différents projets, puis mesurez clairement dans quelle mesure ils l'ont fait ou pas.

Il doit y avoir un chef d'équipe de la même manière qu'un capitaine sur un navire suffisamment gros.

Si le gestionnaire ne remplit pas ou ne peut pas remplir ce rôle, l'un des développeurs doit être nommé pour le remplir.

Je pense que vous devez d'abord réaliser collectivement à quel point vous êtes chanceux d'avoir le pouvoir de prendre toutes les décisions techniques au sein de l'équipe de développement. Combien d'équipes souffrent du fardeau d'une hiérarchie de microgestion qui leur impose leurs caprices techniques, entraînant souvent des choix incohérents, des cauchemars de compatibilité et la frustration des développeurs ...

Dans les avantages d'un lead de développement que vous mentionnez, certains d'entre eux (conseils techniques organisés ...) devraient déjà se produire s'il y avait effectivement une personne naturellement exceptionnelle en termes de compétences techniques. Si tel est le cas, je ne vois pas comment faire officiellement de cette personne un développeur principal donnerait de meilleurs résultats que ceux que vous obtenez maintenant. Si un tel membre de l'équipe n'existe pas dans votre équipe, je ne vois pas comment donner officiellement l'autorité technique à une personne conduirait à de meilleurs résultats que la discussion et la décision collective.

Je vois beaucoup plus de valeur dans la création d'un leader organisationnel - un coordinateur comme le dit le danois. Pas un manager, pas un patron mais quelqu'un qui organiserait le processus de prise de décision collective et agirait comme porte-parole de l'équipe, une interface avec l'extérieur. Si vous optez pour cette méthode, la rotation peut être une bonne idée pour éviter les problèmes susmentionnés - différences de salaire, jalousie ...

Parfois, être un leader est plutôt une responsabilité plus lourde qu'autre chose. Quelqu'un doit assumer la responsabilité des choix, c'est ainsi que la société fonctionne quand personne d'autre ne veut le faire.

Le fait qu'une équipe veuille faire tourner le leader peut signifier que tout le monde sent qu'il peut assumer la responsabilité de ce qu'il fait, et qu'il ne veut favoriser personne, et cela semble être une bonne chose: il n'y a pas de rancune et tout le monde veut que l'équipe réussisse.

Dans ces cas, quand il y a des décisions difficiles à prendre, il suffit de voter pour ces décisions, et lorsque vous avez besoin d'un représentant pour parler à d'autres personnes, il suffit d'élire quelqu'un qui a les meilleures compétences en communication.

Tout d'abord, je pense que vous devez séparer les rôles. Il n'y a aucune raison que la personne agissant comme point de contact entre l'équipe et le reste de l'entreprise doive nécessairement être également la personne qui prend les décisions techniques finales.

Agir en tant que point de contact ne devrait conférer aucune autorité, donc la rotation de cette responsabilité sur un calendrier fixe ne devrait pas être nécessaire. Je dirais que l'équipe s'assoit, tout le monde dit à quel point cela lui dérangerait (certaines personnes pourraient l'aimer, d'autres pourraient être fortement opposées à le faire), puis voter pour quelqu'un pour remplir le rôle. Faites comprendre qu'ils peuvent le remettre à quelqu'un d'autre chaque fois qu'ils en ont marre de le faire.

Quant au côté technique du plomb. Si tout le monde a le même ensemble de compétences et à peu près le même niveau d'expérience, alors bien sûr, laissez tout le monde essayer de devenir un chef de file. L'important est de ne absolument pas changer en cours de projet. Attendez le début d'un nouveau projet, puis choisissez le responsable qui a le plus d'expérience dans ce domaine ou au hasard.