Dette Technique et Management
Dans votre agenda, la semaine est déjà pleine à craquer. La prochaine version de l’application ne sera pas livrée à la date annoncée. Deux de vos Tech Leads quittent l’entreprise : qui pour les remplacer ? Le dernier passage en prod a bien failli mal tourner. Certains choix techniques s’avèrent inadéquats : on commence même à parler de refonte…
La feuille de route sur laquelle tout le monde semblait s’être accordé il y a 6 mois est remise en question bien plus profondément et plus rapidement que ce que vous ne redoutiez.
Côté Tech, on invoque la “dette technique”, transformant au besoin cette simple métaphore en un modèle de coût. Les développeurs auraient sacrifié la qualité du code et les bonnes pratiques afin de pouvoir tenir les jalons d’un calendrier métier pourtant établi d’après leur chiffrages…
Estimation initiale erronée ? Erreur de “casting” ? Entropie inhérente à la technologie ? Qu’est-ce que cette “dette” ? Faut il la rembourser maintenant ? Désendetter plus tard ? Emprunter plus ?
Analogie financière mise à part, ce que les développeurs appellent “dette technique”, c’est simplement une incohérence entre l’état de l’art du projet et ses objectifs et contraintes.
Votre état de l’art : l’ensemble des pratiques, modèles, processus, techniques que vous mettez en œuvre afin de réaliser votre projet spécifique, est un guide opérationel dont certaines parties sont dûment documentées et d’autres implicites. C’est un “livre de recette” évolutif, qui peut s’améliorer au gré des apprentissages, ou bien se détériorer au fil des crises sur le projet.
Décrivez-moi un projet “endetté”, et je vous montrerai un état de l’art en désaccord avec les objectifs et contraintes de ce projet.
Ce peut être un désaccord…
-
délibéré et temporaire, comme lorsqu’on assemble à la hâte une solution “quick & dirty” en vue d’une démo qui approche…
-
subreptice et progressif, comme lorsque les standards de développement sont délaissés peu à peu…
-
soudain, comme lorsqu’il est décidé d’exploiter le “proof of concept” plutôt que la solution industrielle initialement envisagée…
-
structurel, comme lorsqu’une architecture “scalable” est appliquée là ou il n’y aura nul besoin de passer à l’échelle…
La clé d’un développement réussi consiste à évaluer régulièrement et avec rigueur le degré de cohérence entre votre état de l’art et vos objectifs et contraintes.
À quelle fréquence votre équipe vérifie-t’elle cet équilibre fragile ? Le fait-elle avec toutes les informations à disposition ?
J’aide les équipes à résoudre ensemble les problèmes complexes liés à leur état de l’art. J’ai une grande expérience de ces problèmes, et de nombreux outils. Appelez moi !