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

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:

• Comment augmenter le facteur bus et se spécialiser en même temps?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

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.

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.

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.

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.