— Regarde ce qu’ils nous ont encore fait ces idiots de développeurs… — Informe toi avant de juger. J’étais sur ce projet : on ne s’est pas fait faute de prévenir le Métier qu’installer un simple PoC en production était une très mauvaise idée, en vain.

— Mais il n’y avait pas de Managers sur ce projet ? — Bien sûr que si. — Et ils ont signé en bas de cette feuille de route ? — Exactement, et en toute connaissance de cause ! Les utilisateurs référents étaient également d’accord : on sera sur une version beta, et c’est l’occasion de l’essayer en avance de phase. — Mais alors, qu’est-ce qui a 💩é ? — Le responsable du produit a quitté la boite. Il était en conflit avec la DG. La DG croit au projet, mais veut marquer une pause. L’industrialisation n’aura lieu qu’en 2025. — À quoi ça tient !

Créer du logiciel, c’est traduire des idées. Si le logiciel une fois en production procure à ses utilisateurs une expérience médiocre, c’est que la traduction, quelque part, a manqué ses objectifs. Ou bien que les objectifs ont changé entre temps. Ou bien encore que ses utilisateurs en attendaient autre chose. Qui sait ? Lorsque vous examinez le code d’un logiciel en production, vous n’avez sous les yeux qu’une réponse partielle à l’enigme que pose la réalité de ce système.

Il ne s’agit pas là de dédouaner les acteurs du projet de leurs responsabilités, mais de souligner à quel point le travail qu’ils accomplissent dépend de la cohérence d’ensemble du projet.

Dans tout projet de développement (et de maintenance) logiciel, 3 acteurs interviennent, dont les objectifs sont complémentaires mais distincts :

  • Le Métier vise une solution qui réalise de la valeur
  • La Technique veut maximiser l’apprentissage
  • Le Management vise à maintenir dans le temps les conditions de réalisation de la solution

Tout ce qui part en production est le fruit de l’action cohérente de ces 3 acteurs. Par conséquent lorsque vous vous posez des questions telles que…

  • comment un code aussi peu soigné a t’il pu finir en production ?
  • qu’ont fait exactement les personnes chargées de valider la solution ?
  • qu’est-ce qui explique qu’on ait poussé aussi loin l’approche initiale sans jamais la réviser ?

…chaque tentative de blâmer l’un des acteurs vous éloigne un peu plus d’une réponse adéquate au problème.

Pour traiter correctement le problème de la Dette Technique il faut le poser correctement :

  • établissez ensemble un portrait (ou un paysage) de l’état de l’art du projet
  • décortiquez ensemble les anomalies et incohérences que présente cet état de l’art en regard des objectifs et contraintes du projet
  • recadrez ensemble ces objectifs et contraintes, qui ont pu évidemment changer au cours du temps

Notez l’insistance sur le terme “ensemble”. Dans tout projet logiciel important, travailler ensemble est la principale — et parfois la seule — difficulté.

publié sur Linked In le 29/12/2023