Simyl
simylflow
·Par Simyl Team·12 min de lecture

Le véritable coût du théâtre de la productivité

La performance du travail optimisée pour la visibilité plutôt que la valeur détruit les équipes d'ingénierie. Voici le prix caché.

Partage
Table des matières

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 actuelleComportement viséComportement réel
Story points complétésLivrer des fonctionnalitésGonfler les estimations, précipiter le travail
Commits par sprintRester actifDiviser les changements, commits inutiles
Nombre de PRLivrer de façon incrémentalePR minuscules qui fragmentent le travail
Heures enregistréesTravailler fortRester 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 ceciIntroduisez ceci
Story points complétésFonctionnalités atteignant les utilisateurs
Commits par sprintTemps de cycle (idée à production)
Nombre de PRTaux d'échec des changements
Heures enregistréesSondage 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.

Partage

Sources

Footnotes

  1. Baumeister, R. (2011). Willpower: Rediscovering the Greatest Human Strength — Recherche sur la fatigue décisionnelle.

  2. Google (2015). Project Aristotle — Recherche sur l'efficacité d'équipe montrant la confiance comme prédicteur principal.

  3. Stripe/Harris Poll (2018). The Developer Coefficient — Étude d'impact de la dette technique.

  4. SHRM (2022). Human Capital Benchmarking Report — Analyse du coût de remplacement des développeurs.

Continuer la lecture