Management

Peut-on mesurer la productivité des développeurs (sans effet pervers) ?

---

Pour McKinsey, il est urgent de mieux mesurer la productivité des équipes de développement. Et le cabinet de dévoiler sa propre méthodologie... s'attirant une volée de bois vert de la part d'experts en ingénierie logicielle.

PublicitéImpossible à quantifier ? La productivité des développeurs peut-elle être monitorée avec précision et optimisée au fil du temps ? Et ce, sans induire d'effets pervers ? Le sujet, loin d'être réellement nouveau (la méthodologie du Point de fonction remonte à 1979), fait un retour au premier plan, depuis que McKinsey s'intéresse au sujet. Dans un billet de blog, le cabinet américain estime que le consensus actuel, reposant sur le constat qu'une mesure de la performance de bout en bout des développeurs n'est pas possible, n'est plus tenable, à l'heure où le développement s'immisce dans le coeur de métier de nombreuses organisations.

« D'autres fonctions peuvent être évaluées raisonnablement bien, certaines même avec une seule mesure, alors que dans le développement de logiciels, le lien entre les ressources mises en oeuvre et les résultats obtenus est beaucoup moins clair », déplorent les analystes de McKinsey, qui reconnaissent toutefois que le développement de logiciels est un travail hautement collaboratif, complexe et créatif qui nécessite plusieurs mesures à différents niveaux (systèmes, équipes et individus). Sans oublier que les outils d'IA générative, comme ChatGPT ou Copilot X, viennent bousculer les pratiques, améliorant la productivité sur certaines tâches (le même McKinsey a publié une étude sur le sujet, montrant notamment des gains très significatifs dans la documentation et l'écriture du code).

Créer une vue d'ensemble de la productivité

Évidemment, si les consultants de McKinsey prennent la plume, c'est qu'ils ont une méthodologie à proposer. Une « approche nouvelle » déjà déployée dans près de 20 entreprises de la tech, de la finance et de la pharmacie, assurent-ils. « Les premiers résultats sont prometteurs », indique le cabinet, qui met notamment en avant une réduction de 20 à 30% des défauts signalés par les clients de ces organisations.

La méthodologie construite par McKinsey se veut complémentaire de deux autres approches, celle de Google (Dora) et celle de GitHub et Microsoft Research (Space). Pour les consultants, la première permet d'avoir une bonne vision des résultats obtenus par les équipes de développement, tandis que la seconde éclaire l'efficacité d'une organisation. « En plus de ces mesures déjà puissantes, notre approche cherche à identifier ce qui peut être fait pour améliorer la manière dont les produits sont délivrés et la valeur de ces améliorations, sans qu'il soit nécessaire d'avoir recours à des instrumentations lourdes, écrivent les consultants. En complétant les mesures Dora et Space avec des mesures axées sur les opportunités, il est possible de créer une vue d'ensemble de la productivité des développeurs de logiciels. »

PublicitéRépartition des compétences 'en diamant'

McKinsey propose en particulier trois mesures supplémentaires. D'abord, la mesure du temps 'inner loop' par rapport au temps 'outer loop', soit le temps passé à créer le produit logiciel comparé à celui passé à mettre le code en production (intégration, tests d'intégration, gestion des versions, mise en production). Les consultants indiquent que les entreprises de la tech visent ainsi un ratio de 70/30 sur ce partage du temps. Ensuite, McKinsey conseille de se pencher sur le Developer Velocity Index, qui compare le socle technologique, les pratiques de travail et la structure organisationnelle d'une entreprise à des benchmarks permettant de se comparer à d'autres organisations. « Cette comparaison permet de mettre en évidence des domaines spécifiques d'opportunités, que ce soit en matière de gestion du backlog, de tests, de sécurité ou de conformité », écrit McKinsey. Enfin, ces derniers proposent deux métriques davantage liées aux individus : l'analyse de contribution - qui mesure l'apport de chacun à l'avancée du backlog - et le score de capacité des compétences. « Dans l'idéal, les organisations devraient aspirer à une répartition en "diamant" des compétences, la majorité des développeurs se situant au milieu de la fourchette », indique le cabinet.

Cet ensemble d'indicateurs doit aider les directions générales à sortir de l'effet boîte noire qui entoure souvent les équipes de développement logiciel. Même si les consultants se disent conscients des dérives possibles, comme la mauvaise utilisation des indicateurs. Mais, pour McKinsey, cet effet pervers se rencontre avant tout dans des organisations privilégiant des KPI trop simplistes, comme le nombre de lignes de code produites ou le nombre de commits. Pour la société américaine, les mesures de productivité se heurtent aussi aux difficultés liées à l'évolution des mentalités. « Pour tirer véritablement profit des mesures de productivité, les responsables et les développeurs doivent dépasser l'idée selon laquelle les dirigeants ne peuvent pas comprendre les subtilités de l'ingénierie logicielle, ou que celle-ci est trop complexe pour être mesurée », écrivent les consultants. Autrement dit, il est grand temps que les mesures issues de la finance se déploient dans cet univers.

« Mesurer, c'est changer les comportements »

Sans surprise, cette irruption du cabinet de conseil dans le domaine de l'ingénierie informatique a été accueillie plus que fraîchement par les experts du secteur. Kent Beck, ingénieur logiciel et créateur de la méthodologie agile Extreme Programming, parle d'une analyse « absurde et naïve » qui ignore les dynamiques des équipes d'ingénierie logicielle performantes. Et de mentionner son expérience chez Facebook où il a travaillé pendant 7 ans et qui a mis en place « le type d'approches que recommande McKinsey ». Pour un bilan désastreux, selon lui. « Parce que les gens jouent maintenant avec le système, observe-t-il. Nous avons commencé à mesurer et à encourager - avec de l'argent et des statuts - les évolutions des mesures ! Mais ces mesures conduisent à des changements de comportement. »

Avec Gegerly Orosz, un ingénieur de 15 ans d'expérience dans le développement et auteur de la lettre spécialisée The Pragmatic Engineer, Kent Beck a écrit deux articles pour pointer les limites de l'approche McKinsey, ainsi que les objectifs du cabinet d'études. Pour les deux auteurs, l'article de ce dernier a été écrit pour « une raison : Les PDG et les directeurs financiers sont de plus en plus frustrés de voir les directeurs techniques lever les bras au ciel en disant que l'ingénierie logicielle est trop complexe pour être évaluée, alors que les équipes de vente sont suivies via des mesures individuelles et des quotas à atteindre, tout comme les équipes de recrutement. Les responsables de l'ingénierie ne peuvent pas éviter la question de savoir comment mesurer la productivité des développeurs aujourd'hui. S'ils essaient de le faire, ils risquent de voir le PDG ou le directeur financier se tourner vers McKinsey, qui apportera son cadre personnalisé, le déploiera - même si le CTO proteste - et commencera à établir des rapports sur les indicateurs conçus par McKinsey ». Autrement dit, le cabinet s'adresse à ses clients habituels, sans trop se soucier des conséquences réelles.

McKinsey se focalise sur l'effort produit et le delivery

Car, pour Gegerly Orosz et Kent Beck, le modèle proposé par le célèbre cabinet « fera certainement plus de mal que de bien » aux organisations qui l'adoptent et à leur culture de l'ingénierie. Pour démontrer les limites de l'approche suggérée, les deux ingénieurs distinguent bien sûr l'effort produit par les équipes de développement (planification, codage...), la production de celles-ci (les fonctionnalités essentiellement), les résultats obtenus (le changement de comportement des utilisateurs ou clients à la suite du déploiement des nouvelles fonctionnalités) et, enfin, la valeur créée (qu'ils nomment l'impact).

Or, précisément, les indicateurs que propose McKinsey se concentrent sur l'effort produit et la production, dénoncent les deux ingénieurs. « Les seules personnes qui s'intéressent à ces indicateurs sont celles qui les collectent, raillent Gegerly Orosz et Kent Beck. Les clients s'en moquent. Les dirigeants ne s'en soucient pas. Les investisseurs pas davantage. Deuxièmement, et c'est le plus important, la collecte et l'évaluation de ces KPI entravent les mesures dont les personnes en aval se soucient réellement, comme la rentabilité. Pourquoi McKinsey ajoute-t-il des indicateurs pour mesurer l'effort ? L'une des raisons est qu'il s'agit de la chose la plus facile à mesurer ! Mais cette approche ignore une vérité essentielle : l'acte même de mesurer change la façon dont les développeurs travaillent, car ils essaient alors de "jouer" avec le système. »

Démonstration par l'absurde

Et de recommander aux DSI et dirigeants d'entreprise de se focaliser sur des indicateurs centrés sur les résultats (ce que les fonctionnalités changent dans le comportement des utilisateurs) et l'impact (la valeur créée). Comme le proposent d'ailleurs les méthodologies Dora et Space que McKinsey entend compléter. Même si ce type de KPI peut également induire des effets pervers, comme ils le soulignent eux-mêmes, recommandant aux CTO de rester attentifs aux changements de comportement des équipes de développement. Pour les deux ingénieurs, récompenser l'impact permet toutefois d'inciter les ingénieurs logiciels à comprendre les métiers de l'entreprise et à l'aider à atteindre ses objectifs. « La livraison d'une version réduisant les coûts de 2 M$ par an par le biais d'une simple modification de configuration a-t-elle moins de valeur que la livraison d'une version nécessitant 5 mois d'ingénierie pour les abaisser de 500 000 dollars ? », illustrent Gegerly Orosz et Kent Beck dans une forme de démonstration par l'absurde. Et de pied de nez à McKinsey.

Article rédigé par

Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter

Partager cet article