L '«équipe chirurgicale» de Fred Brooks gère-t-elle efficacement le facteur bus?


10

Mon équipe de 4 développeurs expérimentés travaille sur une grande application Windows modulaire (environ 200 KLoC). Je me suis concentré sur la base de code principale depuis le début du projet (il y a 3 ans) et j'ai progressivement évolué vers un poste de développeur semi-principal, même si je ne suis pas le chef d'équipe.

Notre itération actuelle est une actualisation de l'interface utilisateur hautement prioritaire demandée par la haute direction, impliquant environ 15 modifications de la base de code principale. Interrogé par le directeur, j'ai estimé que chacun des 15 changements prendrait moins de quatre heures pour moi de terminer , un total de moins de 7 jours de travail. Je me suis ensuite porté volontaire pour effectuer le travail. Au lieu de cela, le gestionnaire a décidé de répartir uniformément les 15 tâches entre les quatre développeurs.

Dans les trois jours qui se sont écoulés depuis que nous avons commencé à travailler, j'ai observé deux choses:

  1. Les autres membres inexpérimentés de l'équipe ont effectué environ 1 tâche ou moins chacun.

  2. La loi de Brook en action: j'ai passé environ la moitié de mon temps à fournir de l'aide (en essayant de les coacher sur l'utilisation des composants). En conséquence, je n'ai terminé que 2 tâches moi-même, au lieu des 5 ou 6 attendues.

J'ai approché mon manager avec ma préoccupation que nous étions en retard et j'ai de nouveau suggéré que je termine les tâches restantes. Ma demande a été aimablement refusée et les raisons invoquées pour répartir la charge uniformément étaient doubles:

  1. Limitez le facteur camion / bus - incitez les autres développeurs à développer ces compétences maintenant, afin qu'à l'avenir, tout travail puisse être confié à n'importe qui, pas seulement à moi.
  2. Pour éliminer un «goulot d'étranglement» (moi) et accélérer le travail.

Pour être clair, je n'ai aucun problème avec: a) investir le temps d'enseignement, b) les personnes touchant mon code, ou c) la sécurité d'emploi. En fait, je suggère régulièrement au chef d'équipe de former d'autres développeurs sur certains aspects de la base de code principale pour réduire les risques.

Dans cette itération, nous avons également une grande collection de correctifs de bogues de haute priorité ciblés, il semblerait donc que plus de progrès pourraient être réalisés si la charge de travail était redistribuée.

Dans Mythical-Man-Month, Brooks propose une " équipe chirurgicale " où chaque équipe est composée d'un responsable + sous-responsable (le manager et moi), et de quelques rôles mineurs. J'ai l'impression que nous tombons naturellement dans cette organisation, mais mon manager y travaille. Je pense que le facteur de bus est déjà pris en charge (le gestionnaire connaît bien le code de base) et que le goulot d'étranglement n'existe pas réellement (impliquer plus de développeurs ne fera pas accélérer le travail). Je pense qu'à cet égard, une équipe chirurgicale est une bonne chose.

Ce sont mes sentiments, mais je ne suis pas un gestionnaire expérimenté, et nous n'avons pas eu à faire face au facteur bus (frapper du bois). Brooks avait-il raison? Avez-vous travaillé dans une "équipe chirurgicale" où le facteur bus est entré en jeu? Existe-t-il de meilleures techniques pour gérer la distribution de l'expertise?

Questions similaires:


1
Considérez-le comme une formation à la communication de vos compétences à l'équipe.

Réponses:


5

En fait, je dirais que vous suivez le modèle de "l'équipe chirurgicale". Chanceux!

Une partie de l'intérêt de ce modèle est que les membres inférieurs de l'équipe ont un rôle d'assistant. Lorsque l'équipe ne fait pas de chirurgie cardiaque, il est bon de bouger plus lentement et de lui donner une chance de mettre en pratique certaines de ses compétences ou de suivre une formation croisée en matière de responsabilités.

C'est le travail du chirurgien d'examiner et de gérer son équipe en recherchant les points faibles et en les résolvant, tout en étant le meilleur développeur. Vous ne pouvez pas demander à un non-chirurgien (chef d'entreprise) de le faire, car il ne comprend pas les compétences requises, un peu comme un apprenti d'un maître artisan.

Ainsi, le manager profite de cette opportunité pour travailler sur l'un de ses autres objectifs. Si au cours de celui-ci, une faille est révélée dans l'équipe, il peut y faire face avant que cela ne devienne un problème. Disons, en embauchant un autre développeur.

Ou, les juniors pourraient faire une erreur. C'est le moment idéal pour eux de le faire, car ils ont quelqu'un qui veille sur leur épaule. Oscar Wilde a déclaré

L'expérience est simplement le nom que nous donnons à nos erreurs.

Si ces juniors n'ont jamais l'occasion de faire des erreurs, ils ne s'amélioreront jamais. Cela ne vole pas seulement votre équipe de futurs développeurs expérimentés, mais dans un sens, les prive d'une opportunité qu'ils auraient dû avoir.


Merci d'avoir répondu. Déjà, cette expérience révèle définitivement deux faiblesses de notre équipe: 1) notre base de code de base est trop grande et a besoin de plus de modularisation, et 2) lorsque nous modulons davantage, d'autres développeurs doivent prendre la tête des nouveaux composants, au lieu de moi. Le plus gros problème, qui ne fait pas nécessairement partie de ma question initiale, est que je connais bien plus le code que le gestionnaire (qui est le chirurgien "officiel"), donc il ne délègue pas efficacement comme il pourrait l'imo .
Kevin McCormick

@KevinMcCormick - Il semble que vous devriez permettre à votre manager de s'inquiéter de ces choses. Ajustez vos estimations pour inclure désormais l'aide aux membres de votre équipe dans leurs tâches. Vous avez de nombreuses raisons de le faire.
Ramhound

@Ramhound, certainement vrai, et j'en ai même déjà discuté avec le manager et il l'a accepté à l'avenir. Une partie du déséquilibre des compétences dont il n'était pas au courant, et il a offert son aide. Il sait que le projet s'appuie fortement sur moi, que nous travaillons tous les deux à résoudre.
Kevin McCormick

7

Notre entreprise fonctionnait comme vous le suggérez. Nous n'avions que deux personnes qui comprenaient une partie critique du code. Chaque fois qu'une tâche apparaissait dans cette partie du code, plutôt que de passer quelques semaines à mettre quelqu'un d'autre au courant, la tâche lui était assignée car ils pouvaient la terminer en quelques jours. Cela a plutôt bien fonctionné pendant un certain temps.

Ce qui s'est passé, c'est que leur assiette est devenue si pleine que même s'ils pourraient terminer une tâche en 2 jours, il faudrait des semaines pour passer en haut de leur liste. Les managers auraient des batailles verbales féroces sur la tâche la plus urgente. Les tâches dépendantes urgentes ne seraient pas exécutées.

Finalement, les managers en ont eu assez d'attendre et ont commencé à former leurs propres équipes. Oui, c'était beaucoup plus lent pendant un certain temps, mais maintenant notre débit est bien meilleur.

Vous pouvez être dans cette première phase maintenant où vous pouvez gérer le travail, mais vous n'avez aucun moyen de prédire quand vous entrerez dans la deuxième phase. Voici un indice: cela se produit toujours au moment le plus gênant possible. Votre manager a raison de prendre le coup quand vous avez encore un peu de répit.

Oui, c'est frustrant de voir quelqu'un se débattre avec quelque chose que vous pourriez faire vous-même beaucoup plus rapidement et facilement. Essayez d'être parent d'un enfant de deux ans. Vous le faites parce que cela aide toute l'équipe à s'améliorer. C'est le travail de votre manager de vous soucier du calendrier. Si vous vous inquiétez des bogues de haute priorité non résolus, mettez-vous au défi de voir à quelle vitesse vous pouvez les corriger.


Merci d'avoir répondu! Je peux certainement dire que la «phase 2» est une vraie peur, étant donné que nous avons un autre employé d'un autre projet qui est un goulot d'étranglement très visible, et cela a causé des problèmes majeurs dans le passé. Je ne sais pas si notre projet a les mêmes problèmes, donc je suppose qu'il y a un peu de réflexe qui se passe ici. Quoi qu'il en soit, je profite de l'occasion pour partager certaines connaissances et peut-être révéler certaines faiblesses dans la documentation, la modularité du code, etc. Et oui, c'est incroyablement frustrant! C'est réconfortant d'entendre quelqu'un d'autre qui ressent la même chose.
Kevin McCormick

6

Vous n'êtes peut-être pas un goulot d'étranglement maintenant, mais vous le serez éventuellement si vous continuez à faire tout le travail vous-même. Votre manager se rend compte qu'il est assez important pour vous d'apprendre à déléguer pour risquer que votre projet soit en retard - faites-lui confiance. Une fois que vous aurez appris à lâcher prise, vos juniors commenceront à apprendre et à produire beaucoup plus sous votre direction.


Merci pour la réponse, je suis tout à fait d'accord pour dire qu'une personne qui fait tout le travail représente un risque élevé et que le gestionnaire en est conscient. Dans ce cas, cependant, je ne fais pas tout le travail. Les autres membres de l'équipe sont très productifs lorsqu'ils travaillent sur d'autres tâches, telles que la correction de bogues et le travail sur des sous-composants - et non sur l'architecture du système principal. Serait quelque peu similaire à suggérer à quelqu'un de l'équipe Windows Media Player de MS d'apporter des modifications au noyau Windows.
Kevin McCormick

@KevinMcCormick - Et si le lecteur multimédia est ajouté au noyau Windows, excuse valable pour le faire. Il semble que vous ne souhaitiez pas que les membres de l'équipe se familiarisent avec l'architecture du système principal, et je ne vois pas la raison de le faire, cela ne vous aiderait qu'à long terme.
Ramhound

@Ramhound, oui, bien sûr, dans ce cas, ce serait certainement vrai. Je veux que les autres s'approprient ce que j'ai écrit, apportent des modifications et le comprennent (je fournis régulièrement de la formation et de la documentation). Je ne pense tout simplement pas que l'approche «tout le monde travaille sur tout au même degré» soit efficace par rapport à un certain niveau d'attribution de rôle, car nous avons tous des compétences et des compétences différentes.
Kevin McCormick

3

Vous appliquez une contrainte qui peut ne pas être présente ou aussi importante que vous le pensez. Plus précisément, vous vous inquiétez du temps qui s'écoule jusqu'à la fin. En revanche, votre manager ne semble pas concerné par les contraintes de temps perçues.

Si vous retirez le délai de livraison de votre question, vous commencerez rapidement à vous demander pourquoi vous posez la question en premier lieu.

Cela ne veut pas dire que le temps est toujours disponible, et vous avez déclaré qu'il s'agit d'une demande hautement prioritaire de la haute direction. Mais vous n'êtes pas au courant de toutes les conversations que votre patron a eues avec eux. Il a peut-être négocié plus de temps afin que vous passiez ce temps à former les autres membres de l'équipe.

Et bien que vous pensiez que le facteur bus a déjà été résolu, votre patron pourrait se tourner vers la prochaine demande à venir qui ne rentrera pas facilement dans 7 jours de travail par l'un de ses développeurs vedettes. Il est beaucoup plus sûr de former l'équipe sur une itération plus petite où l'ampleur objective du risque est beaucoup plus petite.

J'ai été un goulot d'étranglement critique auparavant; et honnêtement, ce n'est pas un endroit agréable. Dans mon cas, le vice-président des TI et moi avons parlé et nous avons trouvé un plan pour résoudre définitivement le problème. Ça faisait mal, mais ça faisait beaucoup moins mal que si j'avais été transporté par camion.

Il est facile d'entrer dans l'état d'esprit de tout ce qui doit être éliminé le plus rapidement possible. Un bon manager repère les rares opportunités où un peu de retard (pour le cross-training / education) peut rapporter des dividendes importants par la suite.


Merci d'avoir répondu! J'aimerais pouvoir tous les accepter. La contrainte de temps est très réelle dans ce cas, mais comme d'autres l'ont dit, il n'y a jamais de bon moment pour investir dans ce type de temps. J'aimerais savoir comment vous avez résolu votre situation.
Kevin McCormick

3
+1 Certains patrons peuvent être des idiots, mais souvent votre patron a une perspective plus large et vous n'avez qu'à lui faire confiance.
Phil

@Phil - Il semble honnêtement que dans ce cas, le patron pourrait avoir une bonne perspective. Laissez-le s'inquiéter de la chronologie, craignez d'être en retard, il a tout de même fourni l'estimation. Pire cas, le moment critique arrive et vous finissez tout le reste vous-même.
Ramhound
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.