- Les entreprises dépensent beaucoup pour rattraper des capacités opérationnelles comme l’excellence manufacturière à la Toyota, la qualité six-sigma ou la chaîne d’approvisionnement à la Dell, mais les programmes d’amélioration débouchent rarement sur des performances durables
- Le TQM est un cas typique : largement adopté à une époque, puis rapidement abandonné. Parmi les entreprises du Fortune 1000, moins de 10 % disposaient d’un programme TQM bien développé
- La cause des échecs tient moins au choix d’un outil particulier qu’à la manière dont un nouveau programme s’articule avec des structures physiques, économiques, sociales et psychologiques ; l’amélioration devient au fond un problème de système
- Quand l’écart de performance se creuse, l’organisation doit choisir entre Work Harder — travailler davantage — et Work Smarter — gagner en capacité —, mais la seconde option est facilement écartée à cause des délais et du risque d’échec
- Les Shortcuts, qui réduisent le temps consacré à l’amélioration, sont attrayants car ils augmentent la production à court terme, mais l’accumulation d’une dégradation des capacités qui n’apparaît que plus tard peut enfermer l’organisation dans un Capability Trap
Le paradoxe de l’échec des programmes d’amélioration
- Les entreprises investissent activement dans l’amélioration des processus afin de développer des capacités opérationnelles comme la fabrication, la qualité, la compréhension client ou la gestion de la chaîne d’approvisionnement
- En 1997, les dépenses cumulées des entreprises américaines en conseil en management et en formation dépassaient 100 milliards de dollars, une part importante servant à rattraper les capacités opérationnelles des entreprises les plus performantes
- Malgré quelques réussites spectaculaires, beaucoup de programmes d’amélioration ne produisent pas de résultats significatifs
- Le TQM illustre bien ce paradoxe
- Dans les années 1980, il s’est largement diffusé parmi les entreprises américaines sous l’effet du succès des entreprises japonaises
- Au milieu des années 1990, l’intérêt du monde académique et des médias économiques a diminué, et le TQM a été supplanté par de nouvelles innovations comme le re-engineering
- Les entreprises qui se sont sérieusement engagées dans la discipline et les méthodes du TQM ont obtenu de meilleures performances que leurs concurrentes
- Une étude a montré que, parmi les entreprises du Fortune 1000, moins de 10 % disposaient d’un programme TQM bien développé
- Une autre étude indiquait que le TQM était le troisième outil de gestion le plus utilisé en 1993, mais qu’il était retombé à la 14e place en 1999
- Les anciennes techniques d’amélioration réapparaissent parfois sous un autre nom
- Les disciplines centrales du contrôle statistique des procédés et de la réduction de la variabilité ont conduit au six-sigma
- Les quality circles ont été rebaptisés high-performance work teams
Plus difficile que l’outil : la structure de mise en œuvre
- Les outils et techniques d’amélioration de la performance se sont multipliés rapidement, et l’essor des technologies de l’information ainsi que des consultants a rendu plus facile l’apprentissage de qui utilise quelle méthode
- Pour la plupart des managers, l’obstacle principal n’est pas de connaître une nouvelle méthode, mais de la mettre en œuvre avec succès dans le travail quotidien
- Des capacités comme un programme qualité six-sigma ne s’achètent pas comme un produit clé en main ; elles doivent être développées au sein de l’organisation
- Pendant plus de dix ans, plus de 12 études de cas approfondies ont été menées dans les secteurs des télécommunications, des semi-conducteurs, de la chimie, du pétrole, de l’automobile et des produits de loisir
- Elles ont mobilisé l’observation, des entretiens avec les participants, des archives et des indicateurs quantitatifs
- Des modèles ont également été développés pour saisir la dynamique de la mise en œuvre et de l’amélioration
- Si la plupart des organisations ne tirent pas pleinement parti des innovations d’amélioration, cela tient très peu au choix d’un outil particulier
- Un nouveau programme d’amélioration fonctionne là où s’articulent outils, équipements, opérateurs, managers et structures physiques, économiques, sociales et psychologiques : c’est donc un problème systémique
La physique fondamentale de l’amélioration : temps et capacité
- La performance réelle d’un processus est déterminée par le temps de travail effectif (Time Spent Working) et par la capacité du processus (Capability) à accomplir ce travail
- Dans l’industrie, la production nette utilisable est déterminée par le produit du temps de travail quotidien et de la productivité, c’est-à-dire la production utilisable par heure de travail
- On peut améliorer la performance soit en travaillant davantage, soit en investissant davantage dans l’amélioration, mais les résultats diffèrent
- Si l’on augmente le temps de travail hebdomadaire de 20 %, la production peut augmenter de 20 % tant que les heures supplémentaires sont maintenues
- L’amélioration de la capacité du processus augmente la production de tout le temps de travail engagé par la suite
- Les heures supplémentaires consacrées à la reprise de produits défectueux n’augmentent la production que tant qu’elles continuent, alors que l’élimination des causes racines des défauts réduit durablement le besoin de reprise
- La capacité est traitée comme un stock d’actifs qui s’accumule au fil du temps
- Le temps consacré à l’amélioration accroît l’investissement dans la capacité
- Comme il faut du temps pour trouver les causes racines, découvrir, tester et mettre en œuvre des solutions, il existe un délai entre l’activité d’amélioration et l’évolution de la capacité
- À cause de l’usure des machines, des dérives de procédé, du vieillissement de la conception et de l’obsolescence des procédures, une capacité qui n’est pas entretenue régulièrement se dégrade
- Les délais d’amélioration varient selon la complexité technique et organisationnelle du processus
- Pour des améliorations relativement simples, comme le rendement des machines dans un job shop, le délai se compte en mois
- Pour des processus complexes comme le développement produit, il peut se compter en années, voire davantage
- Dans les organisations où le taux de renouvellement des produits et du personnel est élevé, la durée de vie des capacités améliorées est elle aussi plus courte
La tension entre Work Harder et Work Smarter
- La direction fixe une Desired Performance sous forme d’objectifs comme la demande client, le volume de traitement des demandes d’indemnisation ou le nombre de nouveaux produits lancés par trimestre
- L’écart entre la performance réelle et l’objectif devient le Performance Gap, et dans les organisations étudiées, il était rare de trouver des processus dépassant les attentes
- Dans les organisations réticentes à augmenter les ressources ou à recruter davantage, il existe deux options de base pour combler l’écart de performance
-
Boucle Work Harder
- En présence d’un écart de performance, les managers augmentent la pression de travail par des moyens comme l’accélération du rythme, les heures supplémentaires, des objectifs plus agressifs ou des pénalités en cas de non-atteinte
- Des moyens plus subtils, comme la fréquence des revues de performance, le niveau de détail des revues ou le rang hiérarchique des évaluateurs, relèvent également de cette pression de travail
- Dans une entreprise, un vice-président senior examinait la performance de chaque machine sur le terrain de l’usine, ce qui envoyait le message qu’il fallait faire tourner les machines à tout prix
- Un chef de projet dont le calendrier d’un sous-système prenait du retard s’est vu imposer un appel de suivi toutes les heures jusqu’à ce que le prototype respecte les spécifications
-
Boucle Work Smarter
- Les managers peuvent chercher à augmenter la capacité du processus en lançant des programmes d’amélioration, en encourageant l’expérimentation de nouvelles idées ou en investissant dans la formation
- Si cela fonctionne, la capacité s’améliore avec le temps, le débit augmente et l’écart de performance se réduit
- Les investissements d’amélioration peuvent avoir un effet plus important à long terme, mais il existe un délai considérable avant que les effets n’apparaissent, ainsi qu’un risque d’échec dans la découverte des causes racines ou l’application de nouveaux outils
- Face à un problème urgent, l’option Work Harder est souvent choisie
- Si une ligne de production dédiée à un client important s’arrête, un manager aura plus facilement tendance à relancer la ligne et à imposer des heures supplémentaires jusqu’à la fin des expéditions qu’à financer une formation sur l’amélioration de la fiabilité
- Si l’organisation ne revient pas aux activités d’amélioration une fois la réponse de court terme terminée, le fait de travailler plus devient le mode opératoire standard
Boucles de réinvestissement et piège de capacité
- Comme les organisations disposent de très peu de ressources excédentaires, quand la pression de travail augmente, les personnes réduisent les activités non productives comme les pauses et augmentent les heures supplémentaires
- Pour les travailleurs du savoir, les heures supplémentaires sont souvent non rémunérées et s’étendent aux nuits et aux week-ends, au détriment de la famille et de la vie collective
- Quand il n’est plus possible d’augmenter davantage le temps de travail, il ne reste qu’à réduire le temps consacré à l’amélioration pour faire face à un écart de performance qui continue de croître
-
Boucle Reinvestment
- Quand l’investissement dans l’amélioration réussit, la performance augmente, l’écart de performance se réduit, et davantage de temps peut être consacré à l’amélioration : un cercle vertueux se met en place
- À l’inverse, répondre à un écart de débit par la pression de travail réduit le temps d’amélioration, fait décliner la capacité et creuse encore davantage l’écart de performance, créant un cercle vicieux de pression renforcée et d’amélioration réduite
- Dans les cas d’amélioration réussie, les ressources dégagées par les gains de productivité étaient explicitement réaffectées aux activités d’amélioration afin de renforcer le processus de réinvestissement
- Dans de nombreuses organisations, la pression sur les coûts et les délais conduit à des réductions d’effectifs ou à des objectifs de performance plus élevés, ce qui retire des ressources à l’amélioration et entraîne une stagnation, voire une baisse, des capacités
-
Boucle Shortcuts
- Les raccourcis, comme supprimer les réunions d’amélioration, reporter une maintenance préventive planifiée ou ignorer les exigences de documentation, augmentent immédiatement le temps de travail effectif
- Comme la dégradation des capacités n’apparaît pas tout de suite, ces raccourcis semblent efficaces et attrayants à court terme
- Un manager qui reporte la maintenance préventive obtient un sursis en évitant un arrêt planifié et en économisant les coûts de maintenance, mais il paiera plus tard avec une baisse du rendement et du temps de fonctionnement due au vieillissement et à l’usure des équipements
- Un ingénieur logiciel qui saute la documentation peut terminer son projet à temps, mais il en paiera le prix quelques semaines ou quelques mois plus tard lorsqu’il faudra corriger des bugs découverts en test
-
Capability Trap
- Work Harder augmente d’abord immédiatement le débit total, tandis que le coût de la réduction du temps d’amélioration n’apparaît que plus tard, créant une situation de better-before-worse
- Work Smarter réduit la production à court terme, mais au fil du temps la hausse de la capacité compense la baisse de l’effort de travail et améliore la performance : une dynamique de worse-before-better
- L’interaction entre Shortcuts et Reinvestment peut enfermer une organisation dans un Capability Trap, un cercle vicieux de déclin des capacités
2 commentaires
Avis sur Hacker News
Mes souvenirs sont un peu flous, mais j’ai un bon exemple
Dans une organisation, il y avait un traitement de commandes important, dans un contexte où l’on ne pouvait pas partir du principe que toutes les informations nécessaires arriveraient, ni qu’elles arriveraient correctement. Nous avons donc créé une logique de validation qui nettoyait les entrées et modifiait la façon de les traiter, et nous avons conservé des métriques indiquant quelles validations avaient été déclenchées pour chaque commande. Quand nous ajoutions une nouvelle validation, nous y associions aussi une date.
En publiant ces métriques et en les partageant de temps en temps, quand quelqu’un demandait « Que se passe-t-il si XYZ ? », nous pouvions répondre : « C’est déjà géré, et nous avons évité que #### commandes soient bloquées à cause de XYZ. »
Cela montrait que l’équipe travaillait avec prudence, que ce type de travail était nécessaire pour que le système continue à bien fonctionner, et que nous pouvions l’étayer par des données. Grâce à cela, les discussions dans l’organisation sont passées de « pourquoi n’y a-t-on pas pensé ? » à « que fait-on maintenant ? », et la reconnaissance de la qualité préventive est remontée dans la hiérarchie.
La plupart des équipes se seraient contentées de regarder des métriques comme le taux de réussite des commandes, mais mesurer le nombre de fois où de mauvaises données ont été traitées permet d’échapper au piège où le bon travail reste invisible.
J’ai vécu exactement la même chose récemment au travail
En tant que tech lead/architecte de l’organisation, j’ai passé en revue des projets récemment lancés et repéré des points à corriger absolument à cause de graves problèmes de fiabilité/performance. Plusieurs releases d’une équipe figuraient en haut de la liste, mais le PM de cette équipe, l’engineering manager et les personnes au-dessus ont ignoré toutes les inquiétudes, en disant qu’il fallait donner la priorité aux mises à jour fonctionnelles.
Quelques mois plus tard, pendant mes vacances, l’incident est arrivé : escalade sev 1, plusieurs clients furieux, et même le CEO/CTO impliqués. L’équipe même qui avait écrit le code bâclé en question et ignoré les avertissements a travaillé jour et nuit pour rétablir le service, et la voilà désormais héroïque. Le manager, en particulier, a gagné en réputation dans l’entreprise pour avoir beaucoup communiqué pendant la panne et fait preuve de leadership.
Réparer les problèmes créés par d’autres est plus impressionnant. Je n’ai pas très envie de couvrir d’éloges quelqu’un qui corrige sa propre erreur, et je n’attends pas non plus d’éloges quand je corrige les miennes. Je m’excuserais auprès de tout le monde pour avoir causé le problème au départ.
La question du titre me fait sans cesse réfléchir à ma propre valeur
Si j’aide quelqu’un en 40 minutes à débloquer un problème sur lequel il était coincé depuis 3 mois, ma valeur est évidente pour tout le monde. Mais si je travaille avec lui depuis le début et que personne ne reste coincé pendant 3 mois, ma valeur devient floue. Je ne sais pas comment gérer ce paradoxe.
Quand on y consacre plus d’efforts et de temps, il arrive souvent que la récompense reste en retrait tandis qu’on attend de nous encore plus d’efforts et de temps. La valeur et les opportunités ressemblent davantage à un processus chaotique vis-à-vis de l’effort et du temps.
Au final, il faut essayer de maintenir une charge de travail assez légère pour garder les idées claires et pouvoir saisir les opportunités quand elles se présentent. Des collègues honnêtes et équilibrés aident, mais au bout du compte, c’est quelque chose qu’il faut faire soi-même.
Même si mon manager essaie d’expliquer, à la prochaine vague de licenciements, c’est peut-être ma tête qui tombera.
Ils ont bien parlé à d’autres entreprises du fait que j’étais bon pour ce genre de travail, mais rien n’a suivi. C’était la première et la dernière fois que je travaillais en freelance pour une petite entreprise.
Ainsi, le moral de l’équipe ne s’effondre pas. Les membres de l’équipe ont psychologiquement besoin que leur contribution individuelle soit reconnue.
Ces managers ont souvent été de bons contributeurs individuels avant de devenir team leads, et comme ils maîtrisent eux-mêmes la discipline, ils sont les mieux placés pour évaluer les contributeurs individuels qu’ils encadrent.
Il faut décrire de façon vivante les catastrophes évitées, pour que les gens puissent s’en faire une image claire.
Une autre variante consiste à surallouer des ressources pour empêcher un problème qui s’est effectivement produit une fois, tout en accordant moins d’attention à des problèmes plus graves mais qui ne se sont pas encore produits.
C’est un problème de management. Même s’il aurait été rationnel de faire autre chose de plus important, personne n’a envie d’être tenu responsable si le même incident se reproduit.
Une petite blessure est remplacée par une organisation rigide et peu flexible. Ce n’est pas parce qu’une chose s’est produite une fois qu’il faut forcément tout changer pour qu’elle ne se reproduise jamais, et ce genre de réaction excessive peut devenir un lourd fardeau à l’avenir.
Il peut être préférable d’accepter la perte et de reconnaître que cela pourrait se reproduire, plutôt que de surinvestir dans la prévention au nom d’une garantie absolue.
Une politique consistant à ne pas allouer de ressources de prévention tant qu’un événement ne s’est pas réellement produit a une certaine rationalité.
J’ai passé une année misérable à essayer de convaincre les gens qu’ils surréagissaient à une panne et que le problème effectivement survenu avait une solution très simple. Mais quand un cadre dirigeant estime que son poste pourrait être menacé par une récidive, il ordonne à tout le département de passer en revue et de corriger le code présentant des problèmes similaires. Et, bizarrement, il prête l’oreille aux voix les plus fortes qui proposent des solutions massivement surconçues.
Une autre fois, une expiration de mot de passe a provoqué une panne dans la stack de trading. L’effort consacré à une solution maison ridiculement complexe pour faire en sorte que cela « ne se reproduise plus jamais » était ahurissant. Au final, après plus d’un an de travail, tout a été abandonné et remplacé par une solution centralisée beaucoup plus simple, celle qu’il aurait fallu adopter dès le départ.
Cela me rappelle un ancien employeur. Chaque fois que je demandais du feedback, on me répétait : « Ici, rien ne devient prioritaire sans PIR (post-incident response). »
Vers la fin, quand un ticket lié à un PIR arrivait, je le marquais comme doublon du vrai ticket qui aurait pu empêcher l’incident, mais qui dépérissait dans le backlog. Le fait de n’avoir aucune influence pour empêcher des problèmes prévisibles dans notre périmètre a énormément sapé le moral de l’équipe.
La plupart des membres de l’équipe ont tout simplement cessé de proposer des améliorations, parce que le management ne nous autorisait pas à tirer nous-mêmes des tickets.
Cela décrit très bien l’enfer dans lequel le Scrum d’entreprise est en train de se transformer.
Agile signifiait littéralement travailler vite et améliorer ses capacités par cycles rapides. Mais Scrum est devenu une version pire du processus de planification qu’il était censé remplacer.
La manière dont Scrum découpe le travail en problèmes immédiatement visibles aggrave au contraire cette boucle. À long terme, cela devient un système de tickets où les incendies remontent vers le haut et la dette technique est repoussée vers le bas.
En plus, il produit des chiffres d’efficacité faciles à suivre mais dénués de sens, parfaits pour que consultants et dirigeants jouent à l’optimisation.
Je peux me permettre de dire ça : certains de mes meilleurs amis sont Scrum Masters.
Je comprends pourquoi. Parmi toutes les choses possibles à faire, quelqu’un doit décider quoi faire. Cette fonctionnalité rapportera-t-elle de l’argent ? Qu’en est-il d’un travail qui n’est pas une fonctionnalité mais réduit les coûts de ressources ? Et la dette technique, qui ralentit la livraison de fonctionnalités ?
Je ne suis pas dirigeant, mais au bout du compte, quelqu’un là-haut a la responsabilité de faire survivre l’entreprise, de gagner de l’argent et de nous payer nos salaires. Comme nous, ils doivent prendre des décisions avec le peu d’informations dont ils disposent. Il leur faut donc un moyen de comparer « combien cela coûte et quelle valeur cela apporte » avec « combien ceci coûte et quelle valeur ceci apporte ».
Il fallait une façon de l’estimer, et quand l’industrie tech a présenté Agile comme cet outil, ils s’y sont accrochés. À qui la faute ?
C’est ainsi qu’ont suivi les estimations fréquentes, le suivi des plannings et les cérémonies. Certains ne pensent pas que cela devait naturellement en découler, et je suis d’accord. Mais quoi qu’il en soit, ces cérémonies sont devenues une partie du culte.
Nous avons abandonné Scrum, ainsi que les réunions de refinement, les estimations de stories et les story points. Désormais, nous rencontrons formellement le PM une fois par mois et, au niveau de l’équipe, nous ne faisons qu’une estimation en tailles de t-shirt de notre situation actuelle. Pour le reste, nous donnons des mises à jour quand le PM le demande ou quand nous estimons que c’est nécessaire. Cela nous donne de l’autonomie, mais aussi la responsabilité d’alerter à temps si la situation commence à paraître inquiétante. Il faut toujours « estimer », parce qu’au final les dirigeants doivent prendre des décisions. Mais dans l’ensemble, c’est assez léger et vraiment libérateur.
Tout le monde était engagé dans le processus, et l’équipe Scrum réservait 20 % de l’effort à la priorisation du traitement de la dette. La vélocité de chacun était aussi assez précise pour intégrer 20 % supplémentaires de travail sur des sujets d’intérêt personnel, et les priorités des parties prenantes remplissaient les 60 % restants.
Lors de certains sprints, s’il fallait pousser pour terminer une epic ou un objectif d’équipe, ou si une urgence/un bug imposait de changer les priorités, on pivotait.
Ajouter plein de processus juste parce qu’on a envie d’ajouter du processus ne crée pas de valeur.
Cela me rappelle cette BD que j’avais affichée au bureau : https://naksecurity.medium.com/the-detriments-of-hero-cultur...
C’est pourquoi, dans beaucoup de cultures d’entreprise, si un problème n’est pas dans votre périmètre immédiat, il est plus payant de ne pas le prévenir proactivement, même si vous savez comment le corriger. Il suffit de laisser le problème se révéler, devenir l’urgence de quelqu’un, puis de le corriger.
Bien sûr, à long terme, une telle organisation ne peut pas bien tourner, donc il faut aussi prévoir de partir.
« Personne n’est reconnu pour avoir corrigé un problème qui ne s’est jamais produit » (2001) [pdf] me revient en tête
J’y pense chaque fois qu’un youtubeur ou un clickbait sur les réseaux sociaux affirme que le bug de l’an 2000 n’a pas été grand-chose
La raison pour laquelle ce n’a pas été grand-chose, c’est que des milliers de vétérans comme moi ont passé des nuits blanches pendant des mois à faire en sorte que ça marche
Je me souviens encore de la tension au compte à rebours de minuit UTC. Puis à nouveau au compte à rebours de l’heure de l’Est, et encore une fois à l’heure locale. Je n’ai vraiment pu souffler qu’une fois l’heure du Pacifique passée en 2000
On le saura en 2038
Sur la même période, Y2K est aussi un très bon exemple. Il ne s’est presque rien passé de visible, mais si les gens l’avaient simplement ignoré, il est très probable que beaucoup de choses se seraient produites
Et pas parce que mon salaire en dépendait. Il y avait évidemment plein d’autres opportunités de travail. C’était un problème qui aurait réellement pu paralyser le secteur de l’énergie et toucher de grandes entreprises ainsi que les innombrables organisations qui en dépendaient. D’après cette expérience, je pense que de nombreux secteurs comme la finance ou l’exploitation des ressources auraient subi le même choc, directement ou indirectement
C’est donc un bon exemple. Je rencontre encore des gens qui se souviennent de Y2K comme d’une agitation sans importance. Ce n’en était pas une. Si ça n’a pas été un problème pour vous, c’est parce que beaucoup de gens ont travaillé dur pour l’empêcher
Ces problèmes n’étaient pas immensément complexes, mais ils étaient répandus, importants, et demandaient une énorme charge de travail. Ce n’était pas vraiment un défi d’ingénierie du calibre d’un alunissage à mettre au crédit de l’humanité ; c’était plutôt comme corriger une multitude de stupides problèmes de joints toriques du Challenger avant l’explosion
Résultat, le jour J, il ne restait que quelques bugs résiduels mineurs. Les journaux ont bien fait quelques blagues, mais le grand public est globalement passé à autre chose
Je travaille dans le climat, et j’espérais — ou j’espère encore — que la même chose se produise. Mais il semble que cela va bientôt forcément attirer l’attention de tout le monde
Quand on est préparé, il ne se passe rien d’intéressant, la vie continue, et les gens se souviennent juste de quelqu’un ouvrant son ordinateur portable pour appuyer sur quelques boutons
Quand on ne l’est pas, le réseau électrique texan gèle, des gens meurent, perdent leurs économies, et cela devient « personne n’aurait pu imaginer que ce serait aussi grave »
Pour être honnête, j’ai participé à ce travail. Ce qui est drôle, c’est qu’on m’a rappelé chez un ancien client pour corriger un problème que mon propre travail passé avait littéralement créé. Dès que j’ai vu le problème, je l’ai corrigé en 20 minutes. Puis ça a enchaîné avec des « tant que vous êtes là, vous pourriez aussi regarder ça… », et ça a duré environ deux ans, jusqu’à ce que le service soit fermé et transféré à New York
Au moins, j’ai été reconnu en heures facturables
Comme cet article a été écrit juste après, je pensais que ça parlerait de Y2K
À la fin des années 90, j’ai travaillé pendant plusieurs années sur des projets Y2K, pour aider à éviter que des infrastructures critiques au Royaume-Uni ne s’arrêtent à minuit. Sans nos efforts, par exemple, le pays de Galles se serait retrouvé sans eau ni gaz
Et pourtant, par la suite, j’ai entendu des phrases comme « puisqu’il ne s’est rien passé, ce n’était clairement pas un problème ; pourquoi a-t-on dépensé autant pour Y2K ? » ou « Y2K était une arnaque inventée par l’industrie IT »
Nous avons gagné. Nous avons réussi à empêcher le bug de l’an 2000, c’était difficile, et nous n’étions même pas sûrs d’avoir tout attrapé avant minuit. Mais au lieu d’être félicités, certains y ont vu la preuve que nous avions surfacturé. Les gens sont étranges
Ce qui est agaçant, c’est que, pour le changement climatique aussi, le meilleur scénario ressemble à ça. Si nous réussissons effectivement à éviter l’apocalypse, tous les « climatosceptiques » auront l’impression d’avoir eu raison
Commentaires sur Hacker News
En voyant le titre, cela m’a rappelé une vieille anecdote chinoise intéressante. C’est aussi un peu ironique que Toyota ait récemment été pris dans un scandale : https://www.bbc.com/news/articles/c1wwj1p2wdyo
Le roi Wen de Wei demanda à Bian Que : « Si tes trois frères sont tous médecins, lequel est le plus doué ? » Bian Que répondit : « Mon frère aîné est le plus doué, le deuxième vient ensuite, et moi je suis le moins bon. »
L’aîné repère la maladie avant même qu’elle ne prenne forme et l’élimine discrètement ; sa réputation ne dépasse donc pas la famille. Le deuxième soigne la maladie au moment où elle commence à apparaître ; son nom ne dépasse donc pas les ruelles du village. Quant à Bian Que, il pique les vaisseaux, utilise des remèdes puissants et incise la chair ; ce sont ces gestes visibles qui lui valent sa renommée auprès des seigneurs
J’ai déjà vu une entreprise où le « département qui souffre » recevait des compliments et une hausse de budget au trimestre suivant pour avoir héroïquement réparé les problèmes qu’il avait lui-même créés
Pendant ce temps, mon service, qui tournait bien discrètement, peinait déjà simplement à garder les lumières allumées
À cause du fossé entre une direction non technique qui comprend à peine ce qu’est un double-clic et l’ingénierie qui fait réellement tourner l’entreprise, c’est un problème grave dans ce secteur. À part faire venir des dirigeants issus de l’ingénierie, je vois mal la solution
Certains problèmes doivent envoyer un signal de douleur vers le haut avant d’être réparés, afin que la direction puisse en tirer des leçons
Cela dit, concevoir les bonnes incitations est difficile, et il ne faut pas que la haute direction crée une structure où les subordonnés et les services n’osent pas exposer leur douleur et leurs problèmes. Comme il est fréquent que des gens masquent les signaux avec de bonnes intentions, il faut aussi apprendre qu’au sein de grandes organisations, il est parfois plus efficace de laisser certains problèmes se dérouler un peu et d’éviter de réagir de manière trop impulsive
Quand tout le monde conçoit en supposant des conditions normales et un fonctionnement parfait, il est crucial d’avoir quelqu’un qui cherche comment casser la conception, le service, l’infrastructure ou l’application
Un collègue de l’IT aurait pu toucher un peu plus de 2 000 euros en remplaçant des certificats commerciaux par Let’s Encrypt et en supprimant l’exigence EV, mais au final il n’a rien reçu. Ce genre de choses relevait de son « travail normal »
Pendant ce temps, les équipes qui produisaient des services réellement fonctionnels voyaient leur budget gelé et perdaient même du personnel
Quand un autre service a un incident, notre équipe peut montrer, via la liste des travaux terminés, pourquoi nous n’avons pas eu le même problème. Le travail avait déjà été fait, simplement à un meilleur moment, celui qui permettait d’éviter une interruption
Ce genre de chose arrive souvent. J’aime particulièrement le fait qu’une solution élégante paraît généralement simple une fois qu’on la regarde après coup
On réfléchit longtemps, on trouve finalement une solution astucieuse, on l’explique, et l’autre répond : « Oui, évidemment »
Pendant ce temps, la personne à côté, qui a rendu le problème inutilement complexe, se fait féliciter pour avoir produit quelque chose d’aussi difficile
Les grandes entreprises sont peut-être encore en retard et continuent d’admirer la complexité, mais pour ceux qui reçoivent des productions d’IA, directement ou indirectement, la complexité impressionne moins qu’avant
Dans le cas d’un sauvetage quasi miraculeux, on me raconte ensuite que « le neveu a résolu un petit souci immédiatement », comme si cela soulignait le fait que moi, je n’avais pas su le faire
Son responsable lui avait conseillé d’employer la manière compliquée, parce que c’est ce qui permet d’être publié. Non pas parce que c’est plus intelligent, mais parce qu’une solution doit paraître complexe pour être reconnue
Cela correspond exactement à cette réalité où l’on félicite le processus compliqué plutôt que la belle solution, et c’est probablement aussi comme cela que naît la bureaucratie
Ce code était oublié 15 minutes après sa mise en production et plus personne ne le relisait, alors même qu’il était utilisé pendant des années. C’est pour cela que je pense que l’IA pourrait supprimer des emplois bien plus vite que beaucoup ne l’imaginent
Le code propre, la séparation des responsabilités, la maintenabilité — toutes ces choses auxquelles nous consacrons le plus de temps — n’ont en réalité jamais été valorisées. Tant que c’est « suffisamment correct », le manager est satisfait, et si un problème survient, l’IA pourra toujours bricoler un patch spaghetti
J’ai connu un problème similaire dans un ancien poste. Je passais presque tout mon temps sur des tâches administratives en coulisses comme planifier les réunions et faire en sorte que chacun ait les informations nécessaires avant qu’elles aient lieu
Mais au moment de l’évaluation de performance, on m’a expliqué que la seule chose qui comptait, c’était que je n’avais pas terminé beaucoup de story points parce que j’étais occupé à empêcher le travail de s’effondrer
J’ai donc complètement arrêté les tâches administratives et je me suis concentré uniquement sur la clôture des story points, et une ou deux semaines plus tard, le manager a demandé à l’équipe : « Pourquoi toutes les réunions partent-elles en vrille ? Quand on entre en réunion, personne ne sait ce qui se passe. »
Après avoir abattu pendant presque deux ans une quantité énorme de travail réseau, matériel et IT pour se préparer à Y2K, j’ai commencé à me réorienter vers le marketing. Au final, presque toutes les entreprises ont considéré que ce temps et cet argent avaient été gaspillés puisque « rien ne s’était passé »
Une entreprise a même exigé un remboursement intégral ; j’ai répondu que je rembourserais si je pouvais annuler le travail effectué, et ils ont accepté. Le lendemain, tout leur système s’est effondré
Il était aussi difficile de prendre en charge le support réseau de l’entreprise de mon père, parce qu’il refusait catégoriquement de payer mes tarifs. Après que deux autres personnes n’eurent pas réussi à résoudre le problème, je l’ai réglé en 15 minutes, et il a alors eu encore moins envie de payer sous prétexte que cela n’avait pris que 15 minutes
La capacité à éviter que les choses cassent n’était pas reconnue ; seule comptait la capacité à réparer après la casse. Le marketing était mieux payé, et je pouvais justifier mon salaire chaque jour avec des chiffres concrets. Ça me plaît bien moins, mais c’est davantage respecté que n’importe quel travail IT que j’ai fait
Ce qui est reconnu, ce sont des choses simples comme réparer une imprimante, corriger les problèmes informatiques A/B/C, ou un Sudoku Android sans pub fait pour des amis
Le travail essentiel pour lequel on est payé n’est pas reconnu. Dans beaucoup de secteurs, dès que l’argent entre en jeu, remplir son rôle contractuel devient considéré comme allant de soi, et la gratitude diminue
Les gens qui ne connaissent rien à la tech s’imaginent que les développeurs sont en télétravail et ne bossent que 30 minutes par jour, et l’IA a encore aggravé cette image
Ian Rush l’a très bien formulé : « L’attaquant, c’est le meilleur poste. Il peut rater cinq occasions, mais s’il marque le but de la victoire, c’est un héros. Le gardien peut faire un match brillant, s’il en laisse passer une seule, c’est le méchant. »
Partout où j’ai travaillé, on récompensait davantage les pompiers de service que les gens qui empêchaient l’incendie de se déclarer. Le pire, c’est que tout le monde, sauf ceux qui définissent les incitations, voit clairement ce calcul absurde
Il y a aussi l’autre versant : certaines personnes passent tout leur temps à s’inquiéter de choses qui n’arriveront jamais, donc il ne suffit pas non plus de récompenser simplement une posture défensive
C’est comme ça que les promotions se font au travail. On casse quelque chose, ça remonte en escalade, ça devient visible, un e-mail part à la direction. Ensuite, quand on le « répare », tout le monde vous remercie pour le bon travail
Une autre variante consiste à retarder longtemps ce qu’on était censé faire au départ afin d’augmenter sa visibilité. Les dirigeants ne voient pas le travail de ceux qui prennent leurs responsabilités et règlent les choses avant qu’elles ne deviennent un problème
En revanche, ils se souviennent du nom de la personne qui a cassé quelque chose puis a « sauvé » la journée
Pendant ce temps, il flatte les dirigeants et dit des choses comme « mieux vaut ne pas confier ça à doublerabbit » ou « il n’a pas l’air d’être un team player », alors que toute l’infrastructure était la mienne
Voilà pourquoi les gens me demandent pourquoi je déteste les êtres humains
C’est quelque chose qu’on apprend déjà en CP. Les enfants qui restent tranquilles en classe et font leurs devoirs ne prennent pas beaucoup du temps et des efforts de l’enseignant
Ce sont les élèves à problèmes, qui ne respectent pas les règles et ont besoin d’être félicités à chaque petit effort scolaire, qui monopolisent l’attention du professeur
Le temps que j’ai passé dans l’IT a oscillé entre deux extrêmes
« Tout fonctionne bien autour de nous. Pourquoi paie-t-on l’IT ? »
« Tout est en panne. Pourquoi paie-t-on l’IT ? »
Personnellement, je préfère le premier cas au second. J’avais l’habitude de dire : « Si je fais correctement mon travail, vous ne saurez même pas que je suis là. » Mais c’est justement pour ça que j’ai été licencié
Par karma, je reste en contact avec des gens de mon ancienne entreprise, et maintenant c’est un chaos total. C’est au moins une petite consolation
Une fois qu’on connaît le piège de la compétence, on le voit partout
Sterman, Repenning et d’autres collaborateurs ont écrit plusieurs autres articles après celui-ci ; ils sont tous intéressants, mais presque tous déprimants
C’est encore plus déprimant quand on sait que le MIT Sloan, où la dynamique des systèmes s’est d’abord imposée comme discipline, se trouve juste à côté de la Harvard Business School, où la dynamique des systèmes a d’abord été ignorée