Le pire programmeur que je connaisse
(dannorth.net)- Une équipe de conseil chez Big Bank a essayé de mesurer la productivité individuelle au nombre de stories terminées / points de story, et Tim Mackinnon obtenait régulièrement un score de 0 sur cet indicateur
- S’il avait 0 point, ce n’était pas parce qu’il ne travaillait pas, mais parce qu’il ne prenait pas de stories à son nom et passait la majeure partie de ses journées en pair programming
- Avec les développeurs moins expérimentés, au lieu de donner directement la réponse, il favorisait l’apprentissage par des questions socratiques ; avec les seniors, il cherchait avec eux de meilleures solutions à partir de points de vue différents
- L’équipe travaillait de façon plus efficace, plus productive et mieux alignée quand Tim était là, et le manager a fini par abandonner discrètement les indicateurs de productivité individuelle tout en gardant Tim
- Comme une mesure isolée de la contribution individuelle peut ramener à zéro des apports comme ceux de Tim, la productivité doit être évaluée à travers l’impact business et le flux au niveau de l’équipe
Le « programmeur à 0 point » créé par les métriques individuelles
- Une équipe de Big Bank a mis en place des indicateurs de performance individuels pour l’évaluation des performances et le développement des développeurs
- Le manager voulait éviter des métriques faciles à manipuler, comme le nombre de lignes de code ou de bugs, et a donc choisi de mesurer le nombre de stories ou de points de story terminés, au motif qu’ils représentaient la valeur business
- Comme, dans un outil proche de Jira, chaque personne associait son nom à une story, il était facile de construire des métriques de productivité par individu
- Le score de Tim Mackinnon n’était pas simplement faible : il était littéralement de 0 chaque semaine et à chaque itération
- Le manager estimait qu’il fallait retirer Tim de l’équipe et le remplacer par quelqu’un qui « livre » réellement des stories, mais le lead de l’équipe a refusé
Ce que Tim livrait réellement
- Tim ne prenait pas de stories à son nom ; à la place, il travaillait chaque jour en pairing avec différents membres de l’équipe
- Quand il travaillait avec des développeurs moins expérimentés, il les laissait conduire eux-mêmes et les guidait doucement vers la solution
- Il n’imposait pas de réponse et ne forçait pas la direction à prendre
- Il créait des moments d’apprentissage avec des questions du type « what if », « how else » et des Socratic questions
- Avec les développeurs seniors, il travaillait d’une manière proche de la co-création ou du sparring, en appliquant des visions du monde différentes à un même problème pour produire des résultats difficiles à imaginer seul
- Tim, plutôt que de livrer directement du logiciel, faisait grandir l’équipe qui livre le logiciel
- L’ensemble de l’équipe gagnait en efficacité et en productivité
- Elle travaillait de façon plus alignée et plus tolérante
- L’expérience de travail devenait aussi plus agréable
- Quand le manager venait observer l’équipe, Tim était toujours en train de faire « le travail de quelqu’un d’autre » avec cette personne, et le résultat était une meilleure qualité ainsi qu’un délai plus court pour livrer de la valeur
- Finalement, l’équipe a gardé Tim et a choisi la responsabilité collective de l’équipe à la place des métriques de productivité individuelle
- Elle suivait et célébrait l’impact business livré à l’organisation en tant qu’unité de haute performance
Où faut-il regarder pour mesurer la productivité ?
- Mesurer la productivité reste nécessaire, et pour assurer une vraie responsabilité, l’idéal est de viser un impact business mesurable
- argent économisé
- argent généré
- argent protégé
- S’il est difficile de mesurer directement l’impact business, on peut utiliser des indicateurs business indirects
- Dans un système adaptatif complexe, l’idée même de vouloir isoler et mesurer la contribution d’un individu est remise en cause
- Les métriques DORA ne mesurent pas la contribution d’un piston individuel, mais la manière dont fonctionne le système de travail
- On peut aussi les voir comme des indicateurs de culture de Westrum
- On peut également les voir comme des indicateurs de la manière dont les changements techniques circulent jusqu’en production
- Des métriques individuelles peuvent réduire à 0 la contribution réelle de personnes comme Tim ; il est donc plus pertinent d’observer la performance au niveau de l’équipe et le flux à l’échelle du système
1 commentaires
Avis de Hacker News
Il y a une vingtaine d’années, je travaillais dans une entreprise de logiciels de taille moyenne qui vendait une application de bureau pour Mac et Windows. L’équipe avait surtout de l’expérience sur Mac et découvrait à peine Windows, donc la version Windows avait beaucoup de problèmes.
À l’époque, j’étais connu comme spécialiste Windows, et j’ai été recruté pour améliorer cette version et aider l’équipe à se familiariser avec la programmation Windows.
Je passais surtout le début de mes journées à faire des « visites » dans les bureaux des autres développeurs : pair programming, enquête sur des bugs, discussions sur les bonnes pratiques de l’API Windows. Plus tard, un collègue m’a demandé « comment je pouvais avoir autant de temps à y consacrer ».
Quelques mois plus tard, lors de mon évaluation, on m’a dit que « ma productivité n’était pas à la hauteur des attentes, surtout compte tenu du fait que celle du reste de l’équipe avait récemment augmenté ». Je pensais pourtant que c’était précisément pour cela qu’on m’avait embauché.
Le partage de connaissances est le plus grand bénéfice qu’on puisse apporter à d’autres développeurs, mais ceux qui choisissent cette voie sont beaucoup trop peu récompensés.
Sans ce genre de développeurs, le monde du logiciel ne serait même pas proche de ce qu’il est aujourd’hui, et même s’ils ne reçoivent pas de remerciements directs, ils ont indéniablement de la valeur.
Toutes les réparations avaient la même priorité, mais pas la même difficulté. Comme j’avais passé un mois à apprendre et que personne d’autre ne s’en chargeait, je me suis occupé de la réparation des stations de base : cela prenait plus de temps, mais c’était bien plus important pour l’exploitation.
À la réunion de fin de mois, on a affiché un camembert du taux d’utilisation, et j’avais l’air bien moins performant que les seniors expérimentés.
C’est là que j’ai compris pourquoi les seniors choisissaient surtout les tâches rapides et faciles, et que j’ai découvert l’existence de la politique interne. Avec le recul, avoir eu un mauvais manager aussi tôt dans ma carrière a plutôt été une chance.
Mon nouveau manager a reconnu que, lors de ma première évaluation, il avait initialement préparé un plan d’amélioration des performances, mais qu’il l’avait jeté après notre passage en open space, en voyant les gens faire la queue pour me demander de l’aide et constater que je ne renvoyais personne.
Perdre mon bureau en box m’a un peu agacé, mais cette expérience m’a donné une vision positive de l’open space.
Bien sûr, aujourd’hui je ne travaille plus dans aucun bureau, et je n’ai pas l’intention d’accepter à nouveau un poste qui ne soit pas en télétravail.
Ce n’est qu’une fois une réputation établie qu’on peut changer quelque chose ; avant cela, c’est difficile.
Trop de personnes optimisent pour « l’équipe » et finissent licenciées ou écartées des promotions à cause d’une perception négative par la hiérarchie. À l’inverse, quelqu’un qui s’est forgé une bonne réputation sur les critères actuellement valorisés par l’entreprise peut souvent voir ses mauvais comportements tolérés pendant assez longtemps.
Est-ce qu’il est parti immédiatement vers un meilleur endroit ? A-t-il commencé à moins partager son temps pour coller aux indicateurs de performance de l’entreprise ? Ou bien a-t-il convaincu quelqu’un d’assez haut placé dans l’organigramme qu’il avait bel et bien été recruté pour ce rôle ?
Ça me rappelle une anecdote sur les Bell Labs.
Quelqu’un avait calculé quels employés étaient les plus productifs selon un critère comme le nombre de brevets, et avait découvert que beaucoup d’entre eux déjeunaient avec la même personne.
Cette personne n’était pas particulièrement productive individuellement, mais elle posait toujours des questions profondes et pertinentes, qui rendaient ses collègues mesurablement plus productifs.
Les avocats du service brevets des Bell Labs cherchaient un principe organisationnel expliquant pourquoi certaines personnes étaient plus productives, et le seul point commun était que les employés ayant beaucoup de brevets prenaient souvent le déjeuner ou le petit-déjeuner avec l’ingénieur électricien Harry Nyquist.
Nyquist ne leur donnait pas d’idées précises ; il faisait parler les gens, les poussait à réfléchir et, surtout, posait de bonnes questions.
Les groupes humains sont des structures délicates ; une bonne ambiance d’équipe et de bonnes questions peuvent améliorer les choses de façon invisible.
Sinon, il est difficile d’être rémunéré équitablement.
Moi, je ne le crois pas.
Dans une entreprise où j’ai travaillé pendant plusieurs années, si on ne produisait pas 10 points par semaine, on se retrouvait en plan d’amélioration des performances, qu’on soit junior ou senior
Je suis passé par plusieurs équipes, et on pouvait savoir tout de suite comment une équipe mesurait les points rien qu’en regardant le niveau de stress des développeurs
Les équipes qui essayaient de mesurer les points de bonne foi étaient stressées, la plupart montraient des signes de burn-out, et elles travaillaient 60 heures par semaine
À l’inverse, les équipes qui traitaient le système comme un jeu et comprenaient que c’était une mission impossible mettaient le plus de points possible sur les tickets, ou les découpaient en petits tickets pour continuer à accumuler des points, et elles étaient heureuses, sans stress
Dans ce genre d’environnement, jouer selon les règles était une stratégie de pigeon, et quand j’ai fini par démissionner, les 7 ingénieurs seniors de l’entreprise m’ont tous suivi dans les 4 mois
L’objectif est de diviser les grosses stories pleines d’incertitudes et de risques en stories atteignables régulièrement et sans stress
Je ne dis pas que ce lieu de travail avait l’air enviable, mais les développeurs qui ont, selon toi, joué avec le système semblent globalement s’être comportés comme Scrum cherche à l’encourager
En revanche, imposer un minimum de points par semaine et inciter ainsi à gonfler les points, c’est du management épouvantable
Parce qu’elle a tiré davantage de travail des mêmes personnes que si elle n’avait pas mis de pression
Un ancien manager disait ouvertement qu’il « recrutait des gens pour les cramer » afin de finir les projets, et prévoyait qu’il suffisait qu’ils soient utiles pendant 6 mois
S’ils supportaient le stress et la faible rémunération et restaient, c’était du bonus pour l’entreprise ; moi non plus, je n’ai pas tenu longtemps
Si on n’avait pas tout terminé cette semaine-là, on marquait le ticket comme terminé, puis on ouvrait le travail restant sous forme de bug
« Lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure »
À certains endroits, savoir ce qu’un manager peut attendre compte plus que la productivité pure vers un objectif
Ceux qui estimaient les choses de bonne foi pensaient peut-être que la direction agissait elle aussi de bonne foi, mais beaucoup de projets sont construits sur des vœux pieux, ou avec des délais artificiellement courts pour « motiver » les gens
Ce stress n’a peut-être créé aucune valeur, en dehors de la satisfaction émotionnelle du manager
Quand les performances d’un ingénieur logiciel sont évaluées par des non-techniciens, les résultats peuvent être spectaculaires
Mon ami « Tommy » était un excellent spécialiste réseau en IT, et quelques semaines après avoir rejoint une entreprise d’énergie publique, il a dû reconstruire entièrement le réseau avec du matériel moderne, y compris dans tous les bâtiments du siège
L’entreprise voulait confier ça à un prestataire externe, mais quand Tommy a vu le coût prévu par le service financier, il a été stupéfait et a dit qu’il pouvait le faire lui-même avec seulement le matériel physique — routeurs, switches, câbles — et deux personnes chargées du câblage
En quelques semaines, il a terminé le travail pour moins d’un dixième du budget initial, mais tout ce qu’il a reçu, c’est un « merci, bon travail » oral de son supérieur
C’est vraiment amer d’être technicien IT à une époque où les supérieurs, trop vieux jeu, ne comprennent pas la vraie valeur
Ensuite, Tommy aurait pu intervenir comme contractant et recevoir une rémunération supplémentaire
Un développeur vraiment brillant avec qui j’ai travaillé écrivait à la fois du très bon code et du code horrible qu’il fallait jeter immédiatement, et les deux faisaient de lui quelqu’un avec qui il était agréable de travailler
La valeur du bon code n’a pas besoin d’être expliquée, et il est possible que son code tourne encore aujourd’hui
Mais il excellait aussi en situation d’urgence
Quand un client était complètement à l’arrêt et que c’était peut-être de notre faute, il arrivait aussitôt, comprenait rapidement le problème, puis écrivait et installait à toute vitesse du code spaghetti dégueulasse qui remettait le client en marche
C’était du code douloureux à regarder, impossible à commiter ou à refactorer, mais il permettait d’éviter la crise immédiate le temps que quelqu’un corrige correctement le problème plus tard
J’admirais même davantage cette seconde capacité, surtout parce que c’était une compétence rare ; en plus, c’était tout simplement quelqu’un de bien, que tout le monde appréciait
Mais je vais vite, et mon code bizarre a plusieurs fois sauvé la mise en résolvant une urgence ou en permettant de remporter un appel d’offres
La communication est difficile avec les développeurs « perfectionnistes » : pour eux, si le code n’est pas suffisamment conçu, le fait qu’il faille aller vite semble ne pas avoir de valeur
Bien sûr, ils pensent probablement l’inverse de moi
Aujourd’hui, nous avons mis en place des réunions hebdomadaires pour atténuer le problème, et ça marche plutôt bien
Le plus difficile est de décider quel type d’approche convient quand ce n’est pas une urgence, mais que le planning est serré et que les spécifications sont floues ; au moins, la décision est prise collectivement
Ce n’est pas impossible à apprendre seul, mais mémoriser les problèmes courants et leurs solutions au point de pouvoir les taper mécaniquement, c’est quelque chose qui me serait vraiment pénible
Tant que vous ne possédez pas l’entreprise, vous serez toujours évalué sur la valeur perçue
Si votre employeur ne voit pas visuellement votre valeur, vous avez peu de chances de tenir à cet endroit
Un système de performance entièrement méritocratique serait idéal, mais si votre embauche ou votre évaluation dépend de quelqu’un d’autre, votre réussite dépend à 100 % de la façon dont cette personne vous perçoit
Cette perception naît de l’apparence extérieure, que cela ait ou non une valeur réelle pour l’entreprise
Ici, il n’est pas question de compétence en programmation ni de valeur réelle, mais d’emploi et d’évaluation ; il existe aussi beaucoup de gens très productifs qui savent bien gérer leur réputation
Personnellement, j’aimerais que les seniors de l’équipe accomplissent réellement les tâches vraiment difficiles
Aider les juniors à travailler, c’est bien, mais les tâches difficiles et complexes qu’un junior, faute de connaissances, d’expérience et de compétences relationnelles, ne peut pas réaliser nécessitent encore des personnes expérimentées
Aucun pair programming ne peut remplacer complètement cela
Il faut éviter une situation où des fonctionnalités de faible valeur sont très bien implémentées, mais où les tâches à fort impact et haute priorité ne se terminent pas parce que les personnes les plus expérimentées aident les moins expérimentées à faire des choses comme écrire des tests unitaires
Le fait qu’un junior en soit chargé ne signifie pas que le problème est par défaut facile ; sinon, comment ferait-on progresser les ingénieurs ?
Tous les seniors ne doivent pas passer leur temps à mentorer des juniors et à collaborer avec eux, mais avoir quelques personnes comme ça dans une équipe joue un rôle de multiplicateur de force et profite à toute l’équipe
Même si l’entreprise ne le savait pas au moment du recrutement, s’il avait trouvé un créneau utile, elle aurait dû en faire un rôle officiel
C’était un coach ; si on l’avait recruté pour ce rôle, très bien, mais s’ils avaient voulu un coach, ils en auraient probablement embauché un séparément
Il arrive que des fonctionnalités difficiles ne puissent pas être terminées par des juniors même avec un temps infini, parce qu’ils n’ont pas encore les compétences, et que ces compétences prennent des années à acquérir
L’aide ponctuelle d’un senior est nécessaire, mais si cela empêche le senior de produire quoi que ce soit, l’intérêt pour l’entreprise est faible
Il suffit de confier les fonctionnalités difficiles à quelqu’un d’assez senior et, si l’on veut faire monter un junior en compétence, de partager avec lui les parties plus simples de ce travail et de demander au senior d’expliquer ce qu’il fait
L’attitude de Tim, qui aide tout le monde, est admirable, mais il est aussi étrange que les autres programmeurs aient besoin de tant d’aide que Tim n’ait absolument plus le temps de produire quoi que ce soit lui-même
Le problème n’est pas Tim, mais un management qui considère acceptable une situation où des spécialistes ont constamment besoin d’aide et où un Tim quasi bénévole est toujours disponible pour les aider
Si l’un des seniors l’avait correctement conçue au départ, un junior aurait dû pouvoir la modifier
Si, même après avoir été conçue par ce senior, elle reste difficile et complexe à cause de sa structure, on peut se demander pourquoi on l’appelle senior
Cela dit, le travail de tous les seniors ne peut pas se résumer à aider les juniors
De nos jours, il est difficile de devenir ce genre de personne
Tout est centré sur les résultats visibles, si bien que ce type de profil devient facilement une cible de licenciement, et je l’ai vécu directement
Les team players, mentors et architectes logiciels sont de plus en plus écartés, tandis que les codeurs qui produisent beaucoup de code prennent leur place
Même si la dette technique fait baisser avec le temps la capacité à livrer des fonctionnalités et à maintenir le système, les managers apprécient les développeurs qui écrivent régulièrement plus de 5 000 lignes par semaine, indépendamment du nombre de fonctionnalités réellement livrées ou de bugs
En tant que team lead et ingénieur ayant géré des projets complexes, quelqu’un qui écrit plus de 2 000 lignes de code par semaine me fait peur
Cela fait plus de 100 000 lignes de code par an, et il faut tenir compte de la complexité inutile
Il est probablement possible d’implémenter la même fonctionnalité en 10 000 lignes, avec moins de bugs et en deux fois moins de temps, mais cela ne ferait que 380 lignes par semaine, et le manager n’aimerait pas ça
J’ai tendance à penser qu’un développeur qui produit des milliers de lignes ne réfléchit pas assez en profondeur à l’orientation long terme du projet, et que la majeure partie de ce code ressemble à du code jetable
Google a, dans une certaine mesure, institutionnalisé cela avec le rôle de Tech Lead, et l’on attend de cet ingénieur qu’il agisse davantage comme multiplicateur de force et mentor que comme contributeur individuel
Cela ne fonctionne pas toujours comme prévu, peut-être même rarement, et le TL peut se retrouver absorbé par la coordination des personnes, la planification et de petites controverses, au point de ne plus travailler comme ingénieur
Mais l’intention du rôle est bonne
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
L’idée de tout mesurer et d’agir en fonction des chiffres qu’on peut obtenir existe depuis le XIXe siècle
Depuis cette époque, les managers répètent les mêmes pratiques, et les résultats sont ressortis de manière assez stable selon le même schéma
Le propriétaire d’une entreprise où je suis resté brièvement voulait réécrire le service web de zéro tous les six mois afin de suivre les derniers frameworks web et les tendances du moment
Un héros à 5 000 lignes par semaine aurait été embauché sur-le-champ
Sur des projets de maintenance, il m’arrive de passer une semaine sans écrire une seule ligne, ou au contraire de passer toute la semaine à réduire le nombre de lignes de code
Excellent
En aviron, il existe un entraînement appelé seat racing, qui consiste à faire entrer et sortir des personnes de différentes combinaisons de huit places afin de trouver la plus rapide
La puissance individuelle est aussi un indicateur, mais ce qui détermine qui monte dans le bateau de compétition, c’est la vitesse de l’équipe
Au final, il est rare que la combinaison la plus rapide soit simplement composée des huit personnes les plus fortes, et il y a souvent une ou deux personnes « magiques » qui, sans forcément paraître meilleures sur le papier, rendent n’importe quel bateau plus rapide
Elles améliorent subtilement l’équilibre, le rythme et la puissance des autres
Certains coachs n’acceptent pas volontiers cela et y résistent, ce qui réduit au bout du compte le nombre de victoires
C’est très similaire aux équipes logicielles, et ce qui compte au final, ce sont la combinaison et les résultats
Lorsqu’on me demande de coacher du « leadership technique », je dis toujours de prêter une attention particulière aux employés facilitateurs
Leur aide rend les autres employés plus productifs et plus efficaces, et certaines personnes tirent une plus grande satisfaction professionnelle à aider les autres à faire un excellent travail qu’à accomplir elles-mêmes des choses extraordinaires et à en récolter tout le mérite
Ces personnes obtiennent souvent de faibles scores, mais si on les perd, la productivité de l’équipe diminue nettement
J’essaie donc de fournir des outils pour distinguer les personnes qui ne sont pas réellement productives de celles dont la productivité se manifeste à travers la réussite des autres
Il n’est jamais bon de ne mesurer qu’un seul indicateur et de piloter en fonction de celui-ci
Parce que les personnes qui manipulent l’indicateur « gagnent », et que ce comportement finit par mener à des promotions
Je l’ai aussi dit à la direction de Google, mais Laszlo a répondu : « C’est le système que nous avons ; il n’est pas parfait, mais c’est avec lui que nous allons avancer. À vous de choisir si vous voulez travailler dans ce cadre ou non »
Cette seule réunion suffisait à comprendre si la haute direction cherchait réellement à créer un meilleur environnement d’ingénierie ou non
Beaucoup de nouveaux managers, en particulier ceux qui étaient auparavant des ingénieurs contributeurs individuels, pensent que garder les « meilleurs » membres et se séparer des « mauvais » améliorera à la fois le moral de l’équipe et sa production
Mais leur définition des « meilleurs » repose non pas sur des critères de gestion des personnes, mais sur les critères selon lesquels ils faisaient bien leur ancien travail
Ils ont donc tendance à favoriser les personnes ayant des compétences et des habitudes similaires aux leurs, et à sous-estimer celles qui ont des compétences et des habitudes différentes
Le moment où ils en prennent conscience et ouvrent grand les yeux est toujours intéressant
La politique de taux d’intérêt zéro a multiplié les rôles de type senior director qui gèrent des tableaux Jira et des listes de tâches, tout en laissant trop peu de personnes capables de faire le vrai travail
Je ne m’oppose pas à l’idée qu’il puisse exister des personnes qui facilitent la productivité des autres, mais au bout du compte, pour que quelque chose soit terminé, il faut ces « autres personnes »
Sinon, l’organisation se nécrose