Lecture: The Soul Of A New Machine (partie 2)

Avant de poursuivre la lecture de cet article, je vous recommande de faire un tour par la partie 1 qui vous posera tout le contexte.

Le management à Data General n'était pas tendre avec ses employés. Voici quelques morceaux choisis... Avant un petit crochet par des aspects Techniques.

Le management des ingénieurs chez Data General

• Le Mushroom Management était légion chez DG (comme dans beaucoup d’autres boites aux USA) : Isoler l’équipe dans l’entreprise (aucune information descendante), leur donner des tonnes de travail sans rien leur expliquer et ne pas les considérer comme des êtres humains (cf. leurs horaires de travail), et voir ce qu’il en sort.

« put ‘em in the dark, feed ‘em shit, and watch ‘em grow ».

• Le chef de projet use beaucoup des effets d’annonce au sein de son entreprise en promettant la lune à son propre management, quitte à complètement passer à côté de ces deadlines affichées. Cela permet à son Projet de rester à flot (exploitation des biais cognitifs d'optimisme, et de self-serving), mais aussi de mettre la pression sur l’équipe du Projet Eagle.

• Une pratique mise en avant de manière récurrente concerne le fait de recruter des ingénieurs inexpérimentés pour faire le job car ils ne savent pas ce qu’il n’est pas possible de faire, vont donner 150% d’eux-mêmes pour y arriver, et vont finir par obtenir quelque chose qui s’en rapproche de manière satisfaisante. Le tout en étant moins payé. Data General semblait beaucoup miser sur cette stratégie.

• L’entreprise compte beaucoup sur la compétition entre les différents services. Cela oblige les services à se battre et justifier au maximum leurs besoins en ressources. Cela est poussé à son paroxysme car les employés doivent constamment se battre pour obtenir du temps de travail d’une personne d’un service transverse (l’équipe OS par exemple) ou même pour simplement avoir... un stylo.

• Un jeu d'équilibriste étrange mais productif est opéré par Tom West. Le Chef de Projet, très froid et distant, endosse volontairement une attitude "d'ennemi" vis-à-vis de l'équipe Projet. Ceci par le biais du Mushroom Management. L'effet créé est alors le suivant : l'équipe pense alors qu'elle développe seule la machine, sans l'aide de personne ni même du Chef. Cela fait monter en eux une état d'esprit féroce, "c'est notre machine" se disent-ils. Cette attitude booste leur force de travail et leur productivité. La réalité est tout autre : le Chef de Projet les aide dans l'ombre (négociation des bons budgets pour leur permettre de poursuivre leurs travaux notamment); mais ce quiproquo volontaire arrange bien le Chef de Projet qui le fait alors perdurer.

• A l'extérieur de l'équipe, le Chef de Projet se bat bien pour elle. Il redouble de critiques envers les autres services, mais n'en accepte aucune sur le sien. Il fait en sorte de ne pas polluer leur travail sur Eagle avec des considérations politiques inter services. Il agit véritablement en tampon entre son équipe et le reste du monde. Il paie même les boissons lors des évènements d'équipe. Évidemment, il ne leur dit rien à ce sujet et demande à ses plus proches lieutenants au sein du Projet de ne rien révéler (cf. le jeu d'équilibriste ci-dessus). Et il est à noter qu'il est lui-même au bord de la rupture pendant les 2 ans du Projet Eagle.

• Ce jeu de Tom West, à rester froid, distant et dédaigneux envers les ingénieurs de son équipe a également permis à tous d’avoir une soupape de décompression. Un ennemi commun envers qui râler (jamais directement devant lui) lorsque les choses vont mal, pour éviter de s'entre-tuer à coups d'oscilloscope. Ce qui aurait été contre-productif lors du debug d'Eagle où de toute façon la tension et les divergences d'opinion sont inévitables. Encore une fois, c'était savamment orchestré de la part de Tom West.

• Tom West réalise très tôt que l'intensité de travail au sein du Projet va créer un post partum sans précédent à la fin de celui-ci pour chaque personne ayant contribué. Il sent bien que la plupart des personnes (ingénieurs ou non) ont attaché leur raison de vivre ainsi que leur identité au produit qu'ils développent. Il travaille alors dans l'ombre, en parallèle au Projet, à la définition d'une nouvelle ligne de produits Data General, et planifie qui ira travailler sur quel produit et à quel moment. Tout cela pour faciliter la transition de tout le monde vers l'après Eagle.

• A la fin du Projet, au moment où ils peuvent sortir la tête de leurs analyseurs logiques et terminaux, les ingénieurs ont des sentiments très divers, aigre-doux. Ils ont la sensation d'avoir été laissés pour compte par l'entreprise qui leur a donné le minimum de ressources possibles pour mener a bien le développement de "leur" machine. D'un autre côté, ils ont apprécié la liberté dont ils ont pu jouir dans tous leurs choix techniques de conception. A quel point auraient-ils voulus être encadrés ? Attendaient-ils que Tom West leur "tape dans le dos" quand ça allait mal ? Le livre n'apporte pas de réponses.

• Tom West, le Projet terminé, ressent de véritables symptômes de sevrage. Eagle fonctionne, il est en production, et tout cela est derrière eux. Pourtant, pendant un temps, il se réveille à répétition la nuit en sueur et stressé.

La résolution de problèmes sur un ordinateur en conception : Eagle

• Beaucoup de temps est perdu dans le debug par ce comportement régulier : un ingénieur repère une erreur (de câblage d'un circuit intégré sur une carte, par exemple), passe un certain temps à la diagnostiquer puis à la corriger. La correction choisie initialement est une correction rapide, provisoire. La personne prévoit d'y revenir plus tard pour appliquer un correctif définitif et stable. Mais la personne oublie. Il est en effet plus plaisant de passer au problème suivant à résoudre... Plusieurs semaines plus tard de mystérieux problèmes apparaissent et se font très handicapants dans le développement de la machine. Il se trouve que ces étranges phénomènes étaient dus au premier problème ou à sa réparation à la va-vite !

• Certains ingénieurs semblent davantage portés sur la non-régression que les autres. Lorsqu'une modification est faite sur la machine pour corriger un problème, il est primordial de tester si cette correction ne vient pas faire dysfonctionner quelque chose qui fonctionnait auparavant par ailleurs. Les ingénieurs expérimentés font alors des tests dits de non-régression, dans cette optique. Les plus jeunes n'en font pas, et cela finit par faire perdre pas mal de temps un peu plus tard...

• Un jour, un circuit intégré sur une carte de test semble plus lent que les autres. Cela crée un certain nombre de dysfonctionnements. La plupart des ingénieurs estiment qu’il faut changer la puce et poursuivre le travail. Un ingénieur davantage expérimenté leur fait prendre conscience qu’une puce plus lente que les autres sera légion en production série et qu’ignorer ce problème maintenant revient à aller aux devants de grandes déconvenues dans le futur. Il faut que le hardware et le software soient capables de fonctionner avec ces puces plus lentes.

Dans le prochain et dernier article sur The Soul Of A New Machine, je remettrai un couche sur la technique, parlerai de la place de l'ordinateur dans la Société US de l'époque, et terminerai avec quelques passage sur la psyché en jeu dans le Projet Eagle.

Aurélien NARDINI