Gérer sa dette technique – Partie 2 : la négociation

Précédemment

« Dans l'épisode précédent » : vous aviez besoin d’un crédit pour développer votre activité. Vous avez donc contacté votre banquier pour contracter une dette (technique) !

Après de longs échanges, vous avez obtenu un accord de principe. Vous avez identifié plus précisément vos besoins, et détaillé votre patrimoine existant.

Mais il reste encore à négocier les modalités du contrat…

Dans le précédent article, à de nombreuses reprises, j’avais insisté sur le fait de noter les éléments de dette technique. Mais comment le faire correctement ? Quels outils et indicateurs utiliser ?

Crédits : Carlos Muza (Unsplash)

Établir l’échéancier de sa dette technique

Pour une dette financière classique, l’échéancier est généralement simple. Tous les mois, il faut rembourser une mensualité de la somme empruntée, ainsi que les intérêts.

Cependant, dans le cas d’une dette technique, c’est complètement différent.

Pour commencer, on ne peut pas toujours couper en mensualités la somme empruntée. C’est parfois du tout ou rien.

Ensuite, pour les intérêts c’est encore pire… On ne sait pas quand, ni avec quelle intensité ils vont arriver. Si on le savait d’avance, on aurait fait un autre choix ; et bye bye notre trilogie sur la dette technique 😢

Donc on est tous condamnés à coder dans d’atroces souffrances ? Heureusement, non ! Et c’est tout l’objet de cet article. Ouf.

Les informations à noter

Tout d’abord, pour chaque élément de dette technique, il est important d’avoir certaines informations à disposition.

Le coût de réparation estimé

Le coût de réparation estimé est un chiffrage grossier représentant le temps estimé pour corriger. Il peut être exprimé en points avec la suite de Fibonacci (1, 2, 3, 5, 8, 13, …), ou alors en taille de t-shirt (XS, S, M, L, XL). Il s’agit de se faire une idée rapide de la taille du problème.

Le risque à ne pas corriger

Si aucune correction n’est effectuée, quelle sera la gravité des impacts ? Négligeable, faible, modérée, grave ou critique ? Cette information permet de relativiser, et de comparer les éléments entre eux.

Les modules impactés

Connaître les modules impactés constitue une autre information qui permet de relativiser le risque. S’il s’agit d’un module secondaire de l’application, alors le risque global est peut-être à minimiser. En revanche, si l’impact concerne toute l’application, ça peut être plus gênant.

La fréquence ou probabilité de survenue du risque

L’élément le plus difficile à estimer est de savoir avec quelle probabilité le risque va se réaliser. Il faut accepter qu’il s’agit simplement d’une estimation, et l’actualiser selon les événements. Pour les valeurs à associer, je suggère d’utiliser des indicateurs de temps : le risque a-t-il plus de chances de survenir dans la semaine, le mois, le trimestre, le semestre, l’année, … ?

Avoir un tableau de la dette technique

Identifier et caractériser ces informations n’est qu’une première étape. Il faut ensuite les regrouper sur un même support. Il est important de ne pas les disperser pour pouvoir comparer les éléments entre eux, et garder une vue d’ensemble.

Crédits : Will H. McMahan (Unsplash)

Intégré au système actuel

Une première idée peut être d’intégrer ces éléments dans le système de suivi des tâches existant.

L’avantage c’est que cela évite d’avoir à créer un nouveau support, l’équipe sait déjà où chercher.

L’inconvénient, c’est que la dette technique risque d’être noyée dans le flux existant ; et de toujours être reportée à « après les tâches importantes / urgentes ».

Rappel : la dette technique, c’est important !

Intégré dans un nouveau système

On peut alors imaginer créer un système indépendant, et donc traiter la dette technique comme un problème à part entière. Et c’est ce qu’elle mérite en réalité. C’est un travail de fond qui doit devenir habituel, voire même un automatisme. Comme lacer ses chaussures.

Cependant, cela nécessite de mettre en place un nouveau système. Bonjour les réunions à rallonge pour mettre les équipes d’accord sur la forme ; puis les formations pour expliquer son fonctionnement.

Et comme ce système sera décorrélé du tableau « À faire – En cours – Fait », il risque de ne pas être mis à jour correctement.

Mais il y a encore une autre possibilité…

Le tableau physique

Et oui ! La méthode old school, avec nos chers post-its.

On peut même pousser le vice à coller ces post-it sur une fenêtre du bureau : quand la lumière du soleil ne passe plus, c’est qu’il est temps d’agir !

Plus sérieusement, l’avantage de cette méthode c’est qu’on rend la dette technique réelle. On l’affiche aux yeux de toute l’équipe, et cela évite qu’elle passe en second plan lors des session de planning. Même les non développeurs peuvent ainsi en avoir conscience.

Mais il y a malheureusement aussi des inconvénients à cette approche. Déjà les post-it peuvent se décoller et se perdre. Aussi, cela peut être compliqué à gérer pour des équipes qui ne se trouvent pas toujours dans le même bureau.

Le tableau idéal

Bref, comme souvent, il n’y a pas de solution miracle qui s’applique à tout le monde.

Ce sont des propositions qui peuvent servir de base à vos réflexions sur le sujet. À chaque équipe de trouver la méthode qui lui convient le plus.

D’ailleurs, n’hésitez pas à partager en commentaires le fonctionnement de votre équipe, ça serait super intéressant !

« Y a plus qu’à ! »

Voilà, vous avez enfin terminé les négociations avec le banquier, et vous avez clarifié les modalités.

Félicitations, votre prêt est accepté !

Maintenant, il s’agit de le rembourser…

Crédits : Christian Dubovan (Unsplash)

Étiqueté dette technique