En présence d’un conflit, nous ne prenons que très rarement l’initiative de tenter de le résoudre. Nous commençons plus souvent par nous en détacher. Si nous attendons (un peu) est-ce que le conflit ne va pas disparaître lui-même ? Il y a beaucoup à redouter et à détester dans les conflits :

  • ils mobilisent de l’énergie, du temps, du courage et de la patience
  • ils déclenchent souvent des comportements d’aggression et de défense (et alors nous ne donnons plus le meilleur de nous-mêmes)
  • ils deviennent rapidement urgents, ce qui nous pousse à opter pour des solutions à la fois simples, radicales, et fausses

Exemple.

Une société édite depuis bientôt 15 ans un logiciel. Elle est en bonne santé financière, mais elle est menacée par l’apparition sur son marché de compétiteurs qui ont apparemment su tirer parti plus rapidement de nouvelles technologies et des nouveaux usages associés. Il faut réagir : reprendre le produit, en revoir la conception pour l’adapter, en faire quelque chose de neuf, de plus attractif aussi, tout en fidélisant la base actuelle de ses usagers.

Côté Tech, tout allait à peu près tranquillement, et soudain, Mission Impossible.

Bien sûr, changer ce logiciel, c’est ce qu’on fait continuellement depuis qu’il rapporte. Mais on le fait lentement, maladroitement si on veut, mais surtout on le fait à la marge : c’est à dire sans toucher au cœur conceptuel du système, mais en greffant à sa surface des petites fonctions spécifiques ainsi que des nouvelles entités ajoutées là sans réellement examiner la cohérence de l’ensemble. (Côté Tech, on parle de “verrues”).

Au fil des ans, on a “tordu” le système. Et c’est ce qu’il fallait faire : c’est ce qui a rendu possibles toutes ces conquêtes et a produit tous ces bénéfices, client après client.

Au dernier étage de l’entreprise, un vocable nouveau, remonté depuis les plateaux de DEV a fait son apparition dans les discussions qui animent la Direction : Dette Technique.

On pensait que le software est malléable. On le croirait volontiers quand la croissance de l’entreprise repose presque entièrement sur sa capacité à changer rapidement du code. On a parfois gagné des nouveaux comptes en quelques lignes bien placées ! En une après-midi !

Et puis soudain, le mouvement s’arrête. Ça bloque côté DEV. On consulte un cabinet de conseil. Son diagnostic en 1 diapo :

  • une architecture qui ne manque pas de qualités mais inadaptée
  • une dette technique évaluée à € 1 750 371
  • une couverture de tests < 15%

Verdict : il faudrait refondre, en “rebootant” la “factory” avec des pratiques “craft” qui rendront le nouveau système plus fiable, plus facile à maintenir, en un mot à la fois plus évolutif et pérenne. Il faut recruter des profils plus “cappés” pratiquant le TDD, DDD, etc. pendant que l’équipe “historique” maintient “l’existant”.

Traduction en euros : impossible. Investir pour améliorer notre position sur le marché, oui, couler la boîte, non.

conflict-manifest

Stay Tuned ! Publié sur Linked In le 13/09/2024