Le problème de la performance
Optimiser le travail pour la visibilité plutôt que pour la valeur est partout — et cela détruit les organisations d'ingénierie de l'intérieur.
Qu'est-ce que le théâtre de la productivité?
Le théâtre de la productivité est la performance du travail optimisée pour la visibilité plutôt que pour la valeur. C'est le développeur qui garde son IDE ouvert toute la soirée pour que son statut reste vert.
C'est le commit divisé en douze fragments pour que le graphique d'activité paraisse impressionnant.
C'est la PR précipitée en révision pour qu'elle compte dans la vélocité de ce sprint.
C'est la réunion planifiée pour démontrer la « collaboration » plutôt que pour accomplir quoi que ce soit.
C'est la mêlée quotidienne qui dure 30 minutes pour que tout le monde puisse prouver qu'il est occupé.
Chaque organisation d'ingénierie a son théâtre de la productivité. La plupart ne réalisent pas combien cela leur coûte.
Combien coûte le théâtre de la productivité?
Le théâtre de la productivité coûte aux organisations d'ingénierie de quatre façons : capacité cognitive détournée vers la gestion des apparences, érosion de la confiance, accumulation accélérée de dette technique et perte des développeurs que vous voulez le plus garder. Des recherches publiées chiffrent plusieurs de ces coûts.
Coût nº 1 : Fatigue décisionnelle
Le théâtre de la productivité exige des micro-décisions constantes : Comment devrais-je paraître productif en ce moment?
Devrais-je diviser ce commit? Une PR plus petite aurait-elle meilleure apparence? Devrais-je rester en ligne plus tard? Assister à cette réunion démontrerait-il mon engagement? Ces décisions drainent les mêmes ressources cognitives que le travail réel1.
Un développeur qui dépense de l'énergie mentale sur la visibilité a moins d'énergie mentale pour la résolution de problèmes. La meilleure ingénierie se produit dans des états de concentration profonde — que le théâtre de la productivité détruit systématiquement.
Le coût : capacité cognitive détournée de la résolution de problèmes vers la gestion des apparences, chaque heure de chaque jour.
Coût nº 2 : Érosion de la confiance
Les équipes qui manipulent les métriques ensemble développent un dysfonctionnement particulier : elles cessent de se faire confiance.
Quand vous savez que vos coéquipiers gonflent leurs chiffres, vous remettez en question si quoi que ce soit qu'ils rapportent est réel. Quand vous gonflez vos propres chiffres, vous projetez ce comportement sur les autres.
Le résultat est une équipe où personne ne fait confiance aux données, personne ne fait confiance à ses pairs et personne ne fait confiance à ce que son travail réel sera reconnu. La collaboration se dégrade parce que la coordination exige la confiance.
Le coût : le projet Aristotle de Google a trouvé que la sécurité psychologique, que la manipulation des métriques corrode, est le prédicteur le plus fort de l'efficacité d'équipe2.
Coût nº 3 : Accumulation de dette technique
Le code livré pour les métriques de vélocité a une apparence différente du code livré pour la qualité.
Quand les développeurs optimisent pour « commits ce sprint » ou « histoires fermées », ils prennent des décisions différentes :
- Sauter le refactoring qui faciliterait le prochain changement
- Coder en dur au lieu d'abstraire
- Copier-coller au lieu de généraliser
- Livrer sans tests quand le temps manque
Chacune de ces décisions crée de la dette technique. Le sprint a bonne apparence. La base de code pourrit.
Le coût : l'étude Developer Coefficient de Stripe a trouvé que les développeurs passent déjà environ 42 % de leur semaine sur le travail de maintenance : débogage, refactoring et gestion du mauvais code3. La pression de vélocité augmente cette part, et la dette s'accumule.
Coût nº 4 : Exode de talents
Les meilleurs développeurs, ceux que vous voulez le plus retenir, ont des options. Ils peuvent travailler presque n'importe où.
Et ils ne toléreront pas le théâtre de la productivité. Ils veulent faire un travail significatif, être évalués sur les résultats et dépenser leur énergie sur des problèmes, pas sur les apparences. Quand ils rencontrent une culture de théâtre, ils partent.
Vous vous retrouvez avec des développeurs qui tolèrent le dysfonctionnement — soit parce qu'ils n'ont pas d'options, soit parce qu'ils ont appris à jouer le jeu. Ni l'un ni l'autre n'est ce que vous voulez.
Le coût : remplacer un développeur senior coûte 6 à 9 mois de son salaire en recrutement, intégration et perte de productivité4. Les meilleurs développeurs partent en premier.
À quoi ressemble la transition
Quand une équipe abandonne explicitement les métriques de productivité et passe à la mesure basée sur les résultats, l'arc est prévisible :
La baisse initiale
Dans les 2 à 4 premiers sprints, la « production mesurable » chute. La vélocité baisse. Les commits diminuent. Les PR ralentissent.
Cela effraie les leaders qui s'attendent à une amélioration immédiate. Mais c'est attendu : l'équipe ne performe plus de travail pour les métriques. Les chiffres gonflés se dégonflent vers la réalité.
La récupération de qualité
Vers les sprints 4 à 8, les indicateurs de qualité s'améliorent. Les taux d'échappement de bogues chutent. Le retravail diminue. Le temps de cycle (livraison réelle, pas livraison métrique) se stabilise.
L'équipe fait maintenant du travail qui tient. Elle ne livre pas vite et ne corrige pas plus tard — elle livre correctement.
La réalité de la vélocité
Vers les sprints 8 à 12, une nouvelle base de référence émerge. Souvent, la livraison réelle est similaire ou meilleure que l'ancienne période « productive » — mais maintenant c'est réel. Les fonctionnalités restent livrées. Les bogues ne s'accumulent pas. Le rythme de l'équipe est durable.
Le changement de culture
C'est le changement durable. L'équipe cesse de parler de métriques et commence à parler de résultats. La mêlée quotidienne devient « Qu'avons-nous livré? » et non « Sur quoi avons-nous travaillé? » Les rétrospectives se concentrent sur l'amélioration, pas sur les apparences.
Le défi du leadership
La baisse initiale exige du courage de la part du leadership. Quand vos tableaux de bord ont l'air pires avant d'avoir l'air meilleurs, vous avez besoin de la conviction que vous mesurez les mauvaises choses. C'est pourquoi la transition échoue souvent — les leaders paniquent à la baisse et reviennent aux métriques de productivité.
La psychologie du théâtre
Comprendre pourquoi le théâtre de la productivité persiste nous aide à le démanteler.
Biais de visibilité
Les humains sont programmés pour remarquer l'activité visible. Un développeur qui paraît occupé semble plus précieux qu'un qui paraît inactif — même si le développeur inactif réfléchit à un problème difficile.
Les leaders tombent dans ce biais : ils promeuvent, louent et récompensent le travail visible. Le travail invisible (réflexion, apprentissage, prévention de problèmes) passe inaperçu.
Comportement de protection
Dans des environnements incertains, la visibilité est une auto-protection. Si des mises à pied arrivent, qui est coupé? La personne qui « n'a pas fait grand-chose le sprint dernier » ou la personne avec un graphique d'activité impressionnant?
Le théâtre de la productivité est souvent un comportement de survie. Les développeurs performent non pas parce qu'ils sont malhonnêtes, mais parce qu'ils protègent rationnellement leurs carrières.
Gestion par les chiffres
Gérer des humains est difficile. Les chiffres donnent l'impression que c'est gérable. « La vélocité de l'équipe a augmenté de 15 % » est concret, défendable, présentable au conseil.
Les leaders sous pression pour démontrer des résultats s'accrochent aux chiffres — même des chiffres qui mesurent les mauvaises choses.
La spirale de Goodhart
Une fois que les métriques de productivité existent, elles sont difficiles à retirer. Les gens ont construit des processus autour d'elles. Des tableaux de bord ont été créés. Les évaluations de performance y font référence.
Les retirer donne l'impression de retirer la responsabilité — même si elles n'ont jamais mesuré quoi que ce soit de significatif.
Un guide pour l'élimination
Si vous êtes prêt à éliminer le théâtre de la productivité, voici comment procéder :
Étape 1 : Nommez-le
La première étape consiste à reconnaître ce qui se passe. Lors d'une rétro ou d'une réunion d'équipe, nommez le comportement :
« Nous avons remarqué que certaines de nos métriques pourraient encourager la performance plutôt que les résultats. Des choses comme diviser les commits, précipiter les PR ou rester en ligne pour l'apparence plutôt que pour la productivité. Parlons-en. »
C'est psychologiquement difficile mais nécessaire. Vous donnez la permission de discuter de ce que tout le monde sait mais que personne ne dit.
Étape 2 : Auditez vos incitatifs
Cartographiez les comportements que vos métriques actuelles encouragent :
| Métrique actuelle | Comportement visé | Comportement réel |
|---|---|---|
| Story points complétés | Livrer des fonctionnalités | Gonfler les estimations, précipiter le travail |
| Commits par sprint | Rester actif | Diviser les changements, commits inutiles |
| Nombre de PR | Livrer de façon incrémentale | PR minuscules qui fragmentent le travail |
| Heures enregistrées | Travailler fort | Rester en ligne, paraître occupé |
Pour chaque métrique, demandez-vous : « Le comportement réel est-il celui que nous voulons ? » Si ce n'est pas le cas, la métrique cause du théâtre. La plupart de ces modes d'échec ont des noms ; nous les avons catalogués dans Les sept péchés capitaux des métriques d'ingénierie.
Étape 3 : Retirez les métriques toxiques
Vous n'avez pas besoin d'un remplacement avant de retirer une mauvaise métrique. Arrêtez simplement de la mesurer.
La crainte est : « Si nous ne mesurons pas les commits, comment saurons-nous si les gens travaillent ? » La réponse est : vous le saurez en voyant si le travail est livré et tient la route. Ça a toujours été la vraie mesure — les métriques d'activité ne vous ont jamais rien dit dont vous aviez réellement besoin.
Étape 4 : Introduisez des métriques de résultats
Remplacez les métriques d'activité par des métriques de résultats :
| Retirez ceci | Introduisez ceci |
|---|---|
| Story points complétés | Fonctionnalités atteignant les utilisateurs |
| Commits par sprint | Temps de cycle (idée à production) |
| Nombre de PR | Taux d'échec des changements |
| Heures enregistrées | Sondage d'expérience développeur |
Les métriques de résultats sont plus difficiles à manipuler parce qu'elles mesurent ce qui compte vraiment. Deux d'entre elles (temps de cycle et taux d'échec des changements) sont des métriques DORA que vous pouvez extraire des intégrations que vous utilisez déjà au lieu de construire une nouvelle instrumentation.
Étape 5 : Communiquez le changement
Vos parties prenantes (cadres, gestionnaires de produit, autres équipes) s'attendent à des « tableaux de bord de productivité ». Vous devrez expliquer le changement :
« Nous passons des métriques d'activité aux métriques de résultats. Au lieu de mesurer combien nous avons fait, nous mesurons ce que nous avons livré. Voici pourquoi : nos anciennes métriques étaient manipulables, ne corrélaient pas avec la valeur d'affaires et encourageaient des comportements contre-productifs. »
Certaines parties prenantes résisteront. Préparez-vous à : « Mais comment saurons-nous si l'équipe est productive ? » Votre réponse : « En voyant si nous livrons des logiciels de valeur. Voici comment nous mesurons cela maintenant. »
Étape 6 : Survivez à la baisse
La partie la plus difficile est les premiers sprints où les chiffres semblent pires. Préparez-vous et préparez vos parties prenantes :
« Nous nous attendons à ce que la production mesurable baisse initialement alors que nous cessons de performer pour les métriques. Ce n'est pas une baisse de productivité — c'est la fin de l'inflation. Surveillez les métriques de résultats ; elles raconteront la vraie histoire. »
Si vous paniquez et revenez en arrière, vous avez validé que le théâtre était nécessaire. Tenez bon.
À quoi ressemble le succès
Les équipes qui éliminent avec succès le théâtre de la productivité partagent des caractéristiques communes :
Focus sur les résultats
Les conversations passent de « Qu'as-tu fait ? » à « Qu'avons-nous livré ? » Les mises à jour de statut deviennent : « La fonctionnalité de recherche est en production et les utilisateurs l'adoptent » plutôt que « J'ai fermé 12 tickets. »
Prévisions honnêtes
Les estimations deviennent réalistes quand il n'y a pas d'incitatif à gonfler la vélocité. Les équipes s'engagent à ce qu'elles peuvent réellement livrer, pas à ce qui fait bien paraître le plan.
Rythme durable
Sans pression pour paraître productifs, les développeurs travaillent quand ils sont productifs et se reposent quand ils ne le sont pas. Le résultat est un rythme durable qui maintient la qualité dans le temps.
Rétablissement de la confiance
Quand les métriques ne sont pas manipulées, la confiance se reconstruit. Les équipes commencent à croire leurs propres données. La collaboration s'améliore parce que la coordination fonctionne quand l'information est honnête.
Amélioration de la rétention
Les développeurs solides qui sont partis ou envisageaient de partir remarquent le changement. L'équipe devient un endroit où le bon travail est valorisé — ce qui attire et retient les talents.
L'impératif du leadership
Éliminer le théâtre de la productivité exige du courage de la part du leadership.
Vous devrez :
- Admettre que vos métriques actuelles pourraient causer du tort
- Résister à la baisse initiale sans revenir en arrière
- Expliquer le changement à des parties prenantes sceptiques
- Faire confiance à votre équipe pour livrer sans surveillance
Mais le gain est substantiel : une équipe qui s'améliore réellement plutôt que de sembler s'améliorer. Une vraie productivité au lieu d'un théâtre de la productivité. Du travail qui compte plutôt que du travail qui se compte.
Chaque sprint que vous passez sur le théâtre est un sprint que vous auriez pu passer sur les résultats. Le coût s'accumule. Les talents partent. La base de code pourrit.
Le meilleur moment pour arrêter était quand vous avez commencé. Le deuxième meilleur moment est maintenant.
Mesurer l'efficacité des développeurs, pas seulement la productivité
Six dimensions d'efficacité. Tendances au fil du temps. Insights qui aident ton équipe à voir ce qui fonctionne.
Sources
Footnotes
-
Baumeister, R. (2011). Willpower: Rediscovering the Greatest Human Strength — Recherche sur la fatigue décisionnelle. ↩
-
Google (2015). Project Aristotle — Recherche sur l'efficacité d'équipe montrant la confiance comme prédicteur principal. ↩
-
Stripe/Harris Poll (2018). The Developer Coefficient — Étude d'impact de la dette technique. ↩
-
SHRM (2022). Human Capital Benchmarking Report — Analyse du coût de remplacement des développeurs. ↩
Continuer la lecture
- Les 6 dimensions de l'efficacité des développeurs : un cadre pour mesurer ce qui compte vraimentPourquoi nous avons choisi ces dimensions spécifiques, ce que chacune révèle sur la performance réelle en ingénierie, et comment la mesure des résultats transforme les équipes. · 13 min de lecture
- Votre méthode a déjà des rétrospectives. Elle les appelle des rapports de leçons apprises.On vous a dit que Simyl Flow est pour les équipes agiles. C'est pour les équipes avec des dates et des tickets. Si vous gérez des phases et des jalons, votre méthode contient déjà chaque cérémonie du produit — vous les exécutez simplement manuellement, dans des documents que personne ne rouvre. · 10 min de lecture
- Encadrer les développeurs sans devenir Big BrotherLes gestionnaires en ingénierie doivent aider leurs équipes à progresser. Mais le suivi individuel crée une culture de surveillance. Voici la troisième voie. · 13 min de lecture