L’antisèche c’est notre série d’articles qui synthétise des grandes thématiques produit pour vous éviter d’être à sec en entretiens, réunions, soirées mondaines et rendez-vous galants !
Aujourd’hui on aborde le thème de la « dette technique ».
Qu’est ce que c’est ?
La dette technique est un concept théorisé en 1992 par Ward Cunnigham, un informaticien américain également connu pour avoir inventé le concept de wiki et pour avoir contribué à la formalisation de la méthode Agile.
Il s’agit d’une métaphore. Un particulier n’ayant pas suffisamment de cash pour acheter un bien qu’il désire a deux solutions : il attend d’accumuler suffisamment d’argent pour cet achat ou il contracte un prêt bancaire. S’endetter lui sert de raccourci et lui permet de gagner du temps pour acheter ce qu’il désire, mais ça lui revient plus cher qu’un achat en cash à cause des intérêts du prêt qu’il devra rembourser en plus du prix du bien.
Dans le monde du logiciel, la dette technique est la résultante d’un compromis entre :
- Le présent avec des développements rapides et imparfaits (quick and dirty en anglais) pour gagner du temps et réduire les coûts à court terme
- Le futur avec des efforts en temps et en argent supplémentaires à long terme pour corriger, mettre à jour, remplacer ces développements imparfaits et gagner en qualité.
Deux lois à ce sujet sont particulièrement intéressantes à mentionner. Elles proviennent du livre “Programs, life cycles and laws of software evolution” de Lehman et pourraient être traduites par :
- « Changement continu » : un système doit être continuellement adapté, ou il devient progressivement moins satisfaisant.
- « Complexité croissante » : à mesure qu’un système évolue, sa complexité augmente, à moins que des travaux ne soient réalisés pour la maintenir ou la réduire.
La dette technique peut se manifester notamment dans :
- Le code (ex : code dupliqué, règles de gestion alambiquées, variables codées en dur, variables nommées inharmonieusement)
- L’infrastructure (ex : infrastructure obsolète)
- L’architecture (ex : conception monolithique, manque de modularité)
- Les tests (ex : faible couverture de tests, manque de tests automatisés)
- La documentation (ex : documentation incomplète)
Cette dette, intentionnelle ou non, peut être entre autres causée par des problèmes de :
- Ressources en temps / argent (ex : deadline serrée pour lancer un produit sur un nouveau marché, développeurs pas suffisamment formés ou pas assez nombreux)
- Process / conventions (ex : absence de process de développement, manque de standards de code, absence de refactorisation / amélioration continue du code existant, mauvaise communication / collaboration entre les équipes)
- Besoins instables / incompris (ex : des besoins mouvants du marché / des clients, une stratégie / vision produit mal communiquée ou qui change trop fréquemment, mauvaise compréhension du besoin)
- Technologies obsolescentes (ex : langages, frameworks, bibliothèques obsolètes)
En quoi est-ce utile ?
Certes contracter de la dette technique a des avantages sur le court terme surtout :
- Pour gagner du temps
- Pour réduire les coûts de développement
Mais sur le long terme, il vous faut, en tant que PM avec votre équipe, la gérer pour éviter des retours de flamme tels que :
- Une dégradation de la qualité du code (ex : anomalies / problèmes de sécurité plus fréquents…)
- Une baisse de la satisfaction des clients (ex : produit plus lent, indisponible, défaillant…)
- Une baisse de la productivité et du moral des développeurs qui sont confrontés à la dette technique en première ligne (ex : les développeurs passent trop de temps à déchiffrer le code existant, ne prennent pas plaisir à travailler sur des vieilles technos…), ce qui peut accroître le turnover
- Une aversion des développeurs pour innover et modifier du code (on parle notamment de legacy code) de peur de le rendre dysfonctionnel
Comment procéder ?
Voici des mesures concrètes que vous pouvez en tant que PM appliquer avec votre équipe pour ne pas crouler sous le poids de la dette technique :
- Prendre son temps dans la mesure du possible lors de la conception de fonctionnalités, ne pas foncer tête baissée et éviter de s’endetter inutilement
- Identifier et mesurer cette dette technique avec :
- Des outils d’analyse statique de code (ex : SonarQube, Code Climate, Code Scene), des outils de mesure de couverture de tests…
- Des métriques de complexité de code (ex : nombre de lignes de code), des métriques de qualité du code (ex : nombre de code smells, fréquence / criticité des anomalies), des métriques de tests (ex : couverture de tests, taux de défaillance des tests)…
- Matérialiser dans le backlog les différents items de dette technique au même titre que les user stories plus fonctionnelles
- Prioriser les items de dette technique dans la roadmap produit. Les morceaux de code à désendetter en priorité sont ceux étant fréquemment mis à jour par les développeurs (en regardant les statistiques de mises à jour de code, code churn en anglais) et ceux étant particulièrement complexes : il n’est sûrement pas utile de désendetter du code qui n’a pas été souvent mis à jour dans le passé, tout comme il est préférable de faire une tonte différenciée et tondre uniquement des zones de passage.
- Provisionner une partie de la capacité à fournir des développeurs (ex : 20%) pour vidanger progressivement des items de dette technique
- Mettre en place une culture de refactorisation continue pour améliorer le code petit à petit en incluant dans les definitions of done des items concernant la dette technique. L’idée est de faire de ce que l’on appelle de la maintenance opportuniste : dès lors que l’on travaille sur un morceau de code, il est intéressant de saisir l’opportunité de remettre d’aplomb ce morceau de code dans son ensemble lorsque la plaie est à vif, plutôt que de refaire une intervention sur ce même morceau de code plus tard, une fois la plaie cicatrisée. C’est l’image dérivée du scoutisme : “Leave the code cleaner than you found it”
- Mettre en place le peer programming, des code reviews pour harmoniser les pratiques de développement et améliorer la qualité du code
- Favoriser la formation, le partage de connaissance et de bonnes pratiques
- Communiquer régulièrement avec les personnes les plus exposées à cette dette technique, i.e. avec vos amis développeurs, ainsi qu’aux autres interlocuteurs moins techniques de votre organisation pour lesquels cette dette technique n’est pas (aussi) visible.
Quelques exemples
Vous pouvez, en tant que PM, vous trouver confronté à la dette technique dans plusieurs situations, en voici quelques-unes, soyez prêts :
- Vous avez affaire à une fonctionnalité qui a été implémentée il y a quelque temps, qui est utile aux yeux des clients, mais qui fait une drôle de tête en coulisses. Vous avez 2 possibilités, sachant que l’une n’est pas meilleure que l’autre et que cela dépend du contexte :
- Rénover progressivement la fonctionnalité existante
- Recréer une fonctionnalité flambant neuve et décommissionner l’ancienne
- Vous venez d’arriver dans une nouvelle entreprise en tant que PM et vous avez des difficultés à comprendre les règles de gestions tortueuses de votre produit. Malheureusement, votre prédécesseur vous a légué une documentation médiocre et vous devez rattraper celle-ci tant bien que mal avec vos amis développeurs et recetteurs pour enfin comprendre les méandres de votre produit. Pensez avec compassion à vos successeurs et travaillez sur la documentation pour qu’elle soit la plus claire et complète possible
- Vous avez une roadmap produit chargée de nouvelles fonctionnalités pour adresser les besoins galopants d’un nouveau marché et vous avez des difficultés à vendre en interne l’importance d’investir du temps pour désendetter votre produit et de déprioriser certaines nouvelles fonctionnalités. Comme souvent, il vous faut, en tant que PM, “savoir passer la chèvre et le chou”
Une mise en situation
Lancez ce vaste sujet de conversation de la dette technique avec vos collègues qui seront heureux de vous voir intéressé par ce sujet. Posez le diagnostic et repérez ensemble les pathologies, notamment dans :
- Le code
- L’infrastructure
- L’architecture
- Les tests
- La documentation
Allez-y progressivement, il ne s’agit pas de nettoyer les écuries d’Augias en un jour !
Pour aller plus loin
La gestion de la dette technique ne doit pas reposer uniquement sur les épaules des développeurs. Par ailleurs, l’afforestation est importante, la protection des forêts existantes l’est tout autant. De même, le métier de PM ne se résume pas à la création de nouvelles fonctionnalités, vous devez aussi gérer les fonctionnalités existantes. Nous espérons que cette antisèche vous donne envie d’explorer davantage sur le sujet de la dette technique.
Voici quelques pistes pour aller plus loin :
How to manage technical debt – Video (EN)
Prioritizing technical debt as if time & money matters – Adam Tornhill – Video (EN)
Technical Neglect – Kevlin Henney – NDC London 2024 – Video (EN)
KPIs for Product Managers: product technical debt – Article (EN)
How to deal with Technical Debt in Scrum – Article (EN)
On Technical Debt And Code Smells: Surprising insights from scientific studies – Article (EN)
Technical debt 101: A Product Manager’s guide to managing tech debt
A vous de jouer !
