Résumé : un éditeur de logiciel florissant, face à une décision :

  • céder rapidement et définitivement des parts de marchés à la concurrence en ratant la révolution technologique du jour,
  • ou bien investir dans un projet pharamineux de refonte de son produit star

Dans les couloirs de l’entreprise, on envisage ce problème à travers différent prismes.

Pour le Marketing, ce conflit est entièrement nouveau : ça fait déjà un moment qu’elle évoque la nécessité de réaménager le produit pour le mettre au goût du jour, et là, coup d’éclat : pour la première fois après un silence de 18 mois, le CTO lui oppose une fin de non-recevoir, sous la forme d’un audit aux conclusions lunaires, accompagnées d’un devis de refonte astronomique.

Pour la Tech, c’est juste un vieux débat qui refait surface. Les DEVs le disent depuis au moins 5 ans : la base de code est pourrie. Leurs demandes de budgets de refactoring ne sont jamais exaucées : il y a toujours quelque chose de plus urgent à faire, qui “produit de la valeur”. Ceux qui militaient pour que l’on monte en compétence sur les tests automatisés sont partis le faire ailleurs. Les tentatives d’amélioration des pratiques de code ont toutes échoué. Deux tech leads ont déjà démissionné.

Pour la Direction, il n’y a pas vraiment de conflit, même si on peut parler d’un “malaise”. Ce problème de “maintenabilité” et de “dette technique” n’est pas aussi aigu qu’on veut le faire paraître. Il y a beau temps que l’entreprise aurait mis la clé sous la porte si elle ne savait pas gérer ce genre de défi technique. C’est d’ailleurs dans son ADN, de construire des succès à partir de situations particulièrement bancales. Ou paradoxales, si vous voulez.

Pour la plupart des entrepreneurs qui innovent dans la Tech, la sagesse consiste à

  • créer rapidement un produit capable de rencontrer son public
  • améliorer la qualité une fois que le produit est viable et rentable

C’est ignorer qu’une équipe de DEV ne crée pas seulement un produit : elle crée également et de manière à la fois spontanée et continue un état de l’art associé à ce produit : l’ensemble des pratiques, modèles, principes, et processus qui sont le plus adaptés aux objectifs et aux contraintes liés au problème posé.

Pour améliorer son état de l’art, une équipe doit consacrer du temps, de l’énergie et de la motivation sur des sujets d’apprentissages qui sont connexes au produit. Lorsqu’elle ne le fait pas, son état de l’art se dégrade “naturellement”.

En matière de logiciel, ce qui “pourrit” immanquablement si l’on n’y fait rien ce n’est ni le code, ni le produit, c’est l’état de l’art. Les raisons sont diverses :

  • complexité inconnue de ce que nous entreprenons
  • tendance à faire des promesses intenables
  • changements délibérés ou subreptices des paramètres du problème posé

Conséquence : en logiciel, il n’est pas bon d’attendre pour améliorer son état de l’art.

C’est ce que qu’a fait cette entreprise (pourtant surchargée de travail).

Stay Tuned

conflict-not-taken-care-of

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