En 25 ans de carrière, j'ai vu peu de changements d'organisation.
En revanche, j'ai beaucoup vu d'ajouts.
Lorsqu'une opportunité ou un problème survient, on ajoute une action, une procédure, un contrôle, un responsable.
On ajoute un poste, un processus, des réunions.
On charge un peu plus l'agenda, pour démontrer que l'on se préoccupe effectivement de cette nouveauté.
Dans nos logiciels, c'est la même chose. C'est facile d'ajouter de nouveaux utilisateurs. Et pas si compliqué d'ajouter de nouvelles fonctionnalités.
En cas de problème, on ajoute encore : un pare-feu, de la mémoire, de nouveaux serveurs plus puissants, de la bande passante.
Avec cet empilement, on aboutit à des organisations complexes appuyées sur des logiciels dont le volume de code ne cesse de croître.
Souvent, le chiffre d'affaire augmente aussi. Alors ça légitime ces ajouts (c'est grâce à eux que ça augmente, peut-être).
Mais certaines entreprises ne sont plus de cette phase initiale de croissance. Elles cherchent à faire "mieux" plutôt que "plus". Leurs logiciels deviennent des boulets.
Parfois, on parvient à remplacer un système obsolète par un système plus récent, au prix d'une promesse fréquente : ne pas changer les organisations. Il n'y a plus la même chose à l'écran, mais ce sont les mêmes processus et les même responsabilités.
Pourtant, depuis que j'ai basculé du côté de ceux qui font les logiciels, j'observe que des entreprises adoptent un rapport plus mature au logiciel.
Coder le changement
J'ai rencontré plusieurs responsables de projets ou d'unités qui conçoivent le logiciel comme un moyen pour faire évoluer une organisation (l'autre étant de bouger les places dans les bureaux, mais c'est moins efficace en télétravail...).
Voilà le principe :
- On mesure les performances de son organisation,
- En analysant les résultats, on identifie des moyens de faire mieux SANS ajouter quelque chose,
- On code ces changements dans le logiciel,
- On explique aux personnes concernées ce qui change dans l'organisation, en illustrant le propos par le logiciel modifié,
- On déploie la nouvelle version.
J'aime beaucoup cette approche du logiciel qui dépoussière une organisation, au lieu de la figer.
Et ce n'est pas une idée neuve.
Evidemment qu'on veut utiliser la tech pour gagner du temps, mieux communiquer, augmenter la qualité des produits et des services, mieux comprendre les attentes des clients, ...
Mais ce n'est pas toujours faisable avec son logiciel.
Parfois, ce n'est pas l'IT la solution. C'est devenu le problème.
Il y a mille et une métriques pour quantifier la qualité d'un logiciel.
Peine perdue.
Il n'y en a qu'une seule :
Le meilleur code est celui qui est facile à modifier par d'autres développeurs.
Pour se faire une idée de la qualité de votre code, montrez-le à un nouveau développeur et demandez-lui de changer une fonctionnalité liée à une évolution d'organisation.
Par exemple, un processus d'approbation documentaire.
Avez-vous remarqué qu'il était souvent calqué sur l'organisation en place du temps ou l'on faisait voyager le document papier de services en services ?
Le rédacteur le signe, puis le transmet à un contrôleur, qui le transmet à un contrôle qualité, qui le transmet enfin à un approbateur, qui le transmet à un secrétariat, qui le diffuse aux destinataires.
Stop, c'est décidé, on se modernise. On remplace le papier par une GED (Gestion Electronique de Documents).
Que code-t-on ?
Un workflow !
Le rédacteur clique sur un bouton "rédaction terminée", ce qui notifie un contrôleur qui clique sur un bouton "contrôle OK", etc ....
Alors bien entendu, on n'a pas gagné grand chose avec la dématérialisation. Mais au moins, on ne perd plus de document. Et on économise du papier (humm, pas sûr.. J'ai souvent vu des impressions papiers lancées à chaque étape !)
Quelques mois plus tard, un petit malin suggère de faire le processus en parallèle plutôt qu'en série : dès la fin de la rédaction, tous les acteurs de la chaîne de validation peuvent lire le document, faire leurs remarques ou le valider sans attendre l'étape précédente.
Soumettez cette modification (simple) à un nouveau développeur qui vient de reprendre le code de votre GED.
Observez son visage, le ton de sa réponse.
Bravo, vous avez une excellente mesure de qualité du code.
Références :
- Ne devenez pas un architecte IT, dont la citation "change is slow, growth is fast(-ish)" a inspiré cet article : https://ea.rna.nl/2021/07/31/dont-become-an-enterprise-it-architect/
