Selon votre organisation, en tant que Product Manager, vous pouvez être assis juste à côté de votre équipe de développement, dans une autre pièce, ou même dans un autre bâtiment.

J’ai vécu chacune de ces situations.

Il est essentiel pour un Product Manager d’être proche de ses utilisateurs, de les comprendre, de comprendre leurs problèmes, leur façon de penser et ce qu’ils attendent. Mais il est encore plus essentiel d’être proche de l’équipe de développement et de la comprendre, au quotidien.

Après quelques années à faire ça, il y a bien sûr des avantages et des inconvénients. Un inconvénient : vous devrez parfois vous isoler pour vous concentrer sur votre propre travail, autant pour ne pas perturber les développeurs avec des appels téléphoniques bruyants.

Un avantage : vous commencerez à comprendre leur étrange langage et vocabulaire, et par exemple ce qu’ils entendent exactement par Dette Technique. Et que ce n’est pas seulement un b… un jargon pour vous expliquer pourquoi une fonctionnalité n’a pas été livrée à temps.

Qu’est-ce qu’une dette technique ?

Wikipedia dit :

La dette technique (également connue comme dette de conception ou dette de code) est une métaphore récente désignant les conséquences éventuelles de tout système de conception, d’architecture logicielle ou de développement logiciel au sein d’une base de code. La dette peut être conçue comme le travail qui doit être fait avant qu’une tâche particulière puisse être considérée comme terminée ou correcte. Si la dette n’est pas remboursée, elle continuera à accumuler des intérêts, rendant les modifications ultérieures plus difficiles. Une dette technique non traitée augmente l’entropie logicielle.

Bien.

Pour aller plus loin, la dette technique peut être quantifiée comme une métrique estimant le temps qu’une personne mettrait à résoudre tous les défauts du produit, pour obtenir un produit parfait, sans problèmes.

Certains outils, comme les analyseurs de code statiques ou dynamiques, peuvent vous donner une indication de cette métrique selon un ensemble prédéfini de règles et de bonnes pratiques (ce qui signifie bien sûr que l’estimation est liée à la couverture de cet ensemble).

Pourquoi vous devriez vous en soucier, en tant que Product Manager ?

Santé du produit

Eh bien, tout d’abord, c’est une métrique donnant une indication essentielle sur la santé de votre produit, comme la température le ferait pour le corps humain.

Quelques notions sont nécessaires pour utiliser cette métrique efficacement :

1. Il n’y a aucun moyen qu’un projet parvienne à atteindre une dette technique à 0 :
   • À moins que la majorité des ressources de développement ne soit concentrée sur la résolution des problèmes plutôt que sur le développement de nouvelles fonctionnalités
   • À moins qu’aucun nouveau développement de fonctionnalité ne soit jamais exempt de violations ou de problèmes
2. Comparer une estimation de la dette technique entre deux produits est délicat
   • Elle est liée à la taille de la base de code
   • Elle est liée aux choix d’architecture et de technologie, et peut donc avoir un niveau de pertinence différent des bonnes pratiques dont découle l’estimation
3. La métrique de dette technique doit être surveillée sur une période, seule son évolution est pertinente. Quand la dette technique augmente ou diminue, demandez-vous pourquoi.
   • De nouveaux membres de l’équipe ont-ils travaillé sur le projet ? Vous pourriez envisager de leur offrir une formation supplémentaire et/ou des informations contextuelles sur le projet.
   • Que contenaient les nouvelles releases ? Y avait-il de grandes nouvelles fonctionnalités ou essentiellement du débug ?
   • Si la dette technique augmente depuis quelques releases, vos objectifs business sont-ils en équilibre avec vos ressources techniques ?

Ne pas contrôler cette métrique vous fera de toute façon réaliser son importance à un moment ou à un autre, quand la vélocité de votre équipe chutera.

Forte dette technique, roadmap bloquée

J’ai déjà entendu des gens comparer la dette technique au jeu de Jenga. Vous avez ces blocs de bois pour construire une tour, et une fois que vous les avez tous utilisés, vous les retirez et les équilibrez au sommet, rendant la tour plus haute mais plus instable.

Je n’ai jamais eu un produit qui soit “tombé par terre”, même si j’aime cette métaphore. Bien sûr, le service peut tomber, des bugs désagréables peuvent désactiver des fonctionnalités importantes. Un patch ici, un point de suture là, et vous remettez les choses en marche, parce que le business l’exige. Mais les situations que j’ai vécues n’étaient pas beaucoup plus belles.

Les produits avec une dette technique non contrôlée sont pénibles dès que vous voulez ajouter ou modifier la moindre fonctionnalité. Vos développeurs, aussi bons soient-ils, auront du mal à considérer vos user stories comme “terminées”. Simplement parce qu’il sera très complexe d’ajouter/réutiliser le code, mais aussi parce qu’ils ne voudront peut-être pas laisser de la saleté derrière eux. Et vous vous retrouvez ainsi dans la spirale effrayante du refactoring continu.

Vous vouliez juste ajouter un nouveau formulaire sur une page ? Eh bien, vous aurez le choix entre le faire à l’ancienne façon sale, ou demander à vos développeurs de remanier tous les autres formulaires similaires avant d’obtenir le nouveau. Et non, le faire plus proprement juste pour ce nouveau-là ne devrait pas être envisagé, car c’est en fin de compte la meilleure façon de faire exploser votre dette technique. Avoir différentes façons de faire la même chose dans une base de code, c’est le mal.

Attention au Franken-produit

Bon, une dette technique croissante ne signifie pas nécessairement que vous atteindrez ce stade horrifiant. Mais le fantôme rôde quand même, si vous ne vous en inquiétez pas assez tôt.

Il est assez évident que l’adoption par vos clients sera assez faible une fois que vous y serez et qu’ils pourront le voir ou l’expérimenter.

Il y a maintenant un autre effet secondaire avec lequel vous devrez composer. En plus du fait que vos développeurs auront du mal à travailler avec cette base de code, cela aura également un impact sur leur enthousiasme. Quand on aime la belle technologie, on n’a pas envie de coudre du Franken-code toutes les cinq minutes. Vous pourriez argumenter : “Bah, c’est leur boulot !” Mais apprécieriez-vous vraiment de devoir vous battre avec un produit mal conçu (surtout si la conception initiale n’est pas la vôtre) et d’essayer de construire par-dessus ?

Sauvez votre dette, sauvez vos développeurs.

Que faire ?

1. Parlez-en avec votre équipe de développement !
2. Suivez-la dès la toute première ligne de code écrite pour rendre votre produit réel. Si vous ne savez pas par où commencer pour obtenir cette métrique, revenez au point 1.
3. Si vous travaillez avec Scrum, prévoyez toujours un peu de marge pour contrôler la dette technique. N’essayez pas de remplir toute la vélocité du sprint avec de nouvelles fonctionnalités. En fait, votre vélocité devrait à un moment s’adapter au fait que les développeurs feront toujours un certain travail sur la dette.
4. Si la dette de votre produit est déjà élevée, parlez-en avec les parties prenantes business
   • Pour le bien du produit, ça peut valoir la peine d’avoir une roadmap plus légère et de se concentrer davantage sur la réduction de la dette
   • Vous pourriez envisager de supprimer purement certaines fonctionnalités (pas de code = pas de dette ?). Mais vérifiez d’abord leur taux d’utilisation et si elles ne sont pas critiques business/marketing.
   • Eh bien, ça n’est que rarement envisagé vu le coût de l’investissement : repartir de zéro ?

Image de une par Jose Hernandez