En matière de ROI, je ne me complique pas la vie : je pose l’hypothèse que nous allons réduire les coûts de maintenance dans une proportion égale à la réduction de la dette technique.

C’est une hypothèse que l’on peut trouver simpliste et donc discutable, mais notre ambition ne réside pas dans une précision absolue et exacte des chiffres que nous avançons – ce serait prétentieux et irréaliste – sinon à fournir au management des éléments qui facilitent sa prise de décision.
Et je pense que le management préfère une hypothèse de travail simple et claire, même si moins précise, plutôt qu’une formule complexe qui ne sera pas forcément plus réaliste.

Pour avoir effectué cet exercice de calcul et de présentation de ROI dans mon ancienne vie au sein d’éditeurs logiciels (d’analyse de code et de qualité des applications), je peux vous faire une confidence :

Le ROI est directement proportionnel à la complexité de sa formule :
plus le calcul du ROI sera compliqué, plus le retour sur investissement sera élevé.

Le ROI des éditeurs logiciels

Dans les faits, un vendeur de software tentera d’éviter ce calcul s’il le peut, mais c’est très variable selon les pays. C’est un exercice quasiment incontournable aux EU, où le CIO ou tout autre décideur peut se faire virer du jour au lendemain, et donc il est absolument indispensable de pouvoir justifier tout achat logiciel afin d’éviter toute cause de licenciement. Dans nos pays latins (je veux dire en France, en Espagne, en Italie, …), la dimension financière ne revêt pas la même importance lors d’un achat logiciel, et le processus de décision sera globalement plus simple. Le CIO va vérifier que :

• La valeur et les bénéfices attendus du software justifient un prix considéré comme raisonnable et non exhorbitant.
• Le coût de mise en œuvre et d’exploitation sera acceptable.
• Il dispose d’un budget pour cet investissement.

Mais dans l’hypothèse où le CIO demande une estimation de ROI, vous pouvez être certains que la formule de calcul sera compliquée. Pourquoi ?
Parce que le logiciel que l’on tente de vous vendre aura une formule également compliquée pour calculer la dette technique, avec pour seul objectif d’élever celle-ci de manière à effrayer le CIO ou tout autre décideur.

Evidemment, plus la dette technique sera élevée, plus le retour sur investissement sera important.
Ce qui amène d’ailleurs à une question intéressante, et jamais abordée à ma connaissance : la dette technique imputable aux vendeurs de software.

Combien de temps perdez-vous dans la gestion des bugs rencontrés dans ces softwares, et le retard des projets bloqués ou freinés par ces bugs ? Combien dépensez-vous en upgrades obligatoires, pour ne pas dire forcés ? Si vous installez chaque nouvelle version ou chaque patch, cela représente un coût d’upgrade régulier. Mais si vous tentez d’y échapper en ‘sautant’ de temps en temps une version nouvelle, vous pouvez être certain que le prochain upgrade que vous tenterez sera plus compliqué, nécessitant même parfois de passer par une ou plusieurs versions intermédiaires, ce qui sera encore plus coûteux.

Combien dépensez vous en upgrade de votre environnement (hardware, OS, version de base de données, etc.) ou parce la nouvelle version n’est plus compatible avec telle ou telle version d’Unix, de Windows, de JDK, etc. ? Quel est le coût pour vous lorsque le vendeur décide de stopper la maintenance sur ce software ?

Ce ne sont pas seulement les applications que vous gérez qui viennent avec une dette technique, mais également le software dans lequel vous investissez. Est-ce que les vendeurs de software incorporent cette dette technique dans leur formule de ROI ?

Le ROI de notre refactoring

Mais revenons-en à notre formule de calcul. Je souhaite que celle-ci reste simple et, dans le cas où je rencontrerais des objections, alors j’ajouterai certains éléments dont je laisserai l’appréciation aux décideurs. Je préfère procéder ainsi plutôt que d’incorporer ces éléments dans une formule complexe, et qui ne sera pas forcément plus précise car tout écart dans l’estimation de chacun de ces éléments se traduira par une déviation dans l’estimation finale du ROI.

Notre dette technique totale est de 1 283 jours. Un effort de 291 jours pour ramener cette dette technique à un rating SQALE de niveau ‘A’ aura pour effet réduire celle-ci à 992 jours, soit une diminution de cette dette technique de 22.7%.

A raison de 18.5 jours par mois ou 225 jours par an par personne, et une équipe de 5 personnes, la charge globale annuelle pour cette équipe est de 225 jours x 5 personnes = 1 125 jours/homme.

Un effort de refactoring de 291 jours sur une année représente un coût de 291 jours / 1 125 jours/homme, soit 25.9% du coût de cette équipe sur 12 mois, et donc du coût de maintenance annuelle, soit légèrement plus que notre gain de maintenabilité égal à 22.7%.

Disons que globalement, le retour sur notre investissement de refactoring se produit au bout d’un petit peu plus d’1 an, sur la base de notre hypothèse de réduction des coûts de maintenance dans une proportion équivalente à la diminution de la dette technique.

Evidemment, cette hypothèse reste relative: si je divise par deux la dette technique ou si je réduis celle-ci à néant, je ne vais pas diviser par deux le budget de maintenance ou réduire celui-ci à zéro. Mais elle reste crédible pour les proportions (moins de 25%) que nous avons calculées.
Et même si ce calcul n’est pas forcément très exact, ce dont a besoin un CIO est un ordre de grandeur (6 mois, 10 mois, 1 an, 18 mois, etc.). Si le chiffre dépasse les limites du raisonnable, un projet de refactoring ne sera pas examiné plus avant. S’il est acceptable, vous pouvez lui vendre les bénéfices qu’il pourra en obtenir.

Vendre le ROI

Lorsque je discute avec des développeurs sur des notions telle que la dette technique et comment l’utiliser afin de convaincre le management qu’un refactoring est nécessaire, la plupart montre un découragement et une démotivation extrême.

« Mon boss n’est pas intéressé quand je lui parle de corriger les défauts existants, l’impact sur le moral de l’équipe est terrible. »

« Le management raisonne uniquement à court terme : si cela prend une heure pour implémenter une nouvelle fonctionnalité, c’est un bénéfice immédiat. Si tu dis que cela va prendre une journée parce que tu veux en profiter pour améliorer le code, il commence à te regarder de manière suspicieuse. Comme si j’étais une diva qui veut se faire plaisir. »

Les techniciens, et les développeurs d’une manière générale, ont du mal à trouver une justification qui leur permette de vendre l’idée d’un refactoring ponctuel ou au fil de l’eau, parce que la qualité logicielle n’est pas un but en soi pour des managers.

Imaginons que vous restaurez une vieille voiture pour quelqu’un qui espère la revendre un bon prix, une fois vos réparations effectuées. Si vous proposez de mettre de nouvelles jantes plus chères et des nouveaux pneux plus larges, bien sûr qu’il va croire que vous voulez vous faire plaisir en customisant son véhicule. Sauf si vous lui démontrez qu’il peut en tirer un bénéfice.

L’objectif principal du management : la business value d’un investissement. Comment leur vendre le ROI d’un projet de refactoring ? Réponse : par une évaluation correcte des impacts sur le business.

Notre plan : supprimer les défauts critiques (et Blockers), ramener la dette technique à un niveau acceptable et veiller à ce qu’elle n’augmente pas.

Ce plan d’actions porte quasi exclusivement sur une réduction des défauts qui impactent d’abord la Reliability, donc la robustesse de l’application pour une meilleure satisfaction des utilisateurs, et non pas des défauts en matière de Maintainability dont on pourrait espérer une réduction des coûts de maintenance. Cependant, moins de risques de bugs signifie également moins de coûts de corrections de bugs, et un gain encore plus important en maintenance. On sait également que plus un défaut est constaté tard lors du cycle de développement applicatif (en production par exemple), plus il coûtera cher.

S’il vous en coûte simplement 2 heures pour corriger un défaut, et que vous économisez ainsi 2 ou 3 jours de détection et de correction d’un bug, non seulement votre ROI devient beaucoup plus intéressant d’un point de vue financier, mais d’un point de vue qualitatif, vous améliorez grandement la satisfaction des utilisateurs et l’image de votre département. Et cela n’a pas de prix.

Les autres points que l’on peut mettre en avant, mais sans forcément les chiffrer afin de ne pas tomber dans le travers d’une formule compliquée :

• Une QA plus efficace : chaque fois qu’un bug est constaté en QA, le code revient chez le développeur qui doit le corriger, puis retourne en QA pour de nouveaux tests. Moins vous avez de défauts, moins vous avez d’allers-retours, plus la phase de tests sera rapide. Donc coûts moindres, respect des budgets et des plannings. Et un planning tenu signifie un utilisateur heureux !
• Business value : un bug en production peut avoir pour conséquence une moindre performance, voire l’interruption du système, donc des opérations plus longues et une charge de travail plus importante pour les utilisateurs, donc des utilisateurs – voire des clients – mécontents. Tout cela peut impacter les ventes, ainsi bien sûr que l’efficacité des départements marketing, commerciaux, logistiques, etc.
• Business value : moins vous dépensez en maintenance, plus vous pouvez investir dans de nouvelles applications et supporter de nouveaux business et la croissance de l’entreprise sur de nouveaux marchés.
• Une meilleure productivité des développeurs : certaines violations aux bonnes pratiques de programmation impactent les temps de développement. Par exemple, un code dupliqué signifie une moindre réutilisabilité, donc plus de temps passé à développer du code … qui existe déjà.
• Meilleur contrôle des outsourcers : si vous faites un audit tous les 6 mois, votre outsourcer ne se souciera de la qualité de vos applications et de la dérive de la dette technique qu’une fois tous les 6 mois. Lorsqu’il sera trop tard. Si vous mettez en place un outil comme SonarQube avec le plugin SQALE, vous pouvez effectuer ces contrôles automatiquement chaque semaine. C’est ce qu’on appelle l’effet radar : s’il sait qu’il peut être ‘flashé’ à tout instant, votre outsourcer sera beaucoup plus prudent.

Ce sont différents points qui sont compréhensibles intuitivement par le management, pour la valeur que cela représente pour l’entreprise, le business, et le département IT. Après, si l’on veut réellement constituer un ROI précis qui prenne en compte ces différents bénéfices, il faut alors soit effectuer des hypothèses (nombre de bugs trouvés en production, en QA, etc.), soit se baser sur des chiffres fournis par des instituts de recherche. Le résultat ne sera pas forcément plus exact ou précis que notre simple estimation basée sur la réduction de la dette technique.

Nous reparlerons probablement de ROI lorsque nous étudierons notre dernier scénario : le ré-engineering de notre application Legacy. Prochainement.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.