Pourquoi votre « simple » modification logicielle prend 8 heures au lieu de 30 minutes

Vous avez demandé ce qui semble être une modification simple. Peut-être mettre à jour l’heure d’une notification, modifier un filtre de rapport ou ajouter un nouveau champ à un formulaire.

Dans votre tête, c’est une affaire de 30 minutes. Une heure, si l’on est généreux. Puis je vous propose une estimation de 6 à 8 heures, et vous vous dites : « Mais qu’est-ce que c’est que ça ? »

Honnêtement ? Parfois, j’aimerais que ce soit aussi simple que ça en a l’air vu de l’extérieur.

Laissez-moi vous expliquer ce qui se passe. C’est plus compliqué qu’il n’y paraît.

Pourquoi un « petit » changement n’est pas si petit

Ce que vous voyez en surface ne représente que 10 % de ce qui se passe en coulisses.

Imaginons que vous souhaitiez modifier la date d’envoi d’un e-mail de rappel de tâche. « Il suffit de passer d’aujourd’hui à demain »,

Bien sûr, cela ne représente qu’une ligne de code. Mais

• Quel système envoie cet e-mail ?

• Y a-t-il d’autres endroits où la « date d’échéance » est définie différemment ?

• Qu’en est-il des tâches récurrentes par rapport aux tâches ponctuelles ?

• Faut-il mettre à jour l’interface utilisateur en conséquence ?

• Cela va-t-il perturber les e-mails d’escalade vers les responsables ?

• Qu’en est-il des notifications de l’application mobile ?

Cette modification d’une ligne touche six parties différentes du système.

Si nous ne les vérifions pas toutes, votre équipe opérationnelle sera mécontente lorsque des problèmes surgiront.

Que se passe-t-il ?

Voici ce qui se passe lorsque nous recevons votre demande « simple » :

‍Heure 1 : Déterminer où diable se trouve cette logique. Même dans WeWeb et Retool, nous devons trouver où se trouve la logique. Est-elle dans le workflow ? Dans un déclencheur ? Elle pourrait être cachée dans une intégration héritée datant du début de notre collaboration. Cela représente 30 minutes perdues à chercher, en supposant que nous nous souvenions bien du système.

Heures 2-3 : Recenser tous les endroits où cette modification pourrait causer des dysfonctionnements. Nous voulons éviter de casser autre chose en corrigeant votre demande initiale.

Heures 4-5 : Effectuer la modification et la tester. Je veux dire, vraiment le tester, pas juste cliquer un peu pendant 2 minutes. Nous devons nous assurer que nous n’avons rien cassé d’autre. Nous ne pouvons pas simplement déployer une modification et espérer que tout ira bien.

Nous devons le tester sur un serveur de préproduction. La notification se déclenche-t-elle correctement ? Atteint-elle les bonnes personnes ? S’il s’agit d’un outil interne pour votre équipe, une vérification rapide suffit (environ 20 minutes). Mais s’il s’agit d’un outil destiné aux clients ? Une seule erreur et vos clients se retrouvent inondés de messages indésirables.

Heures 6 à 8 : Nettoyons ce que nous avons découvert par hasard. Puisque nous y sommes déjà, autant corriger les trois autres éléments rafistolés à la va-vite. Ensuite, nous déployons le tout. Même avec le low-code, ce n’est pas instantané. Comptez encore 15 à 30 minutes.

Pourquoi cela semble-t-il pire que ça ne devrait l’être ?

Une grande partie de cette complexité est inutile. Elle existe parce que :

• Les systèmes sont construits rapidement sous la pression

• Les « solutions de fortune » s’accumulent au fil du temps

• Personne n’a le temps de remettre de l’ordre dans les fondations

• Nous passons notre temps à éteindre des incendies au lieu de les prévenir

Rénover une maison pendant que des gens y vivent est un défi. On ne peut pas simplement abattre des murs.

Et maintenant ?

Nous pourrions apporter cette modification d’une ligne et considérer que c’est terminé en 2 heures au lieu de 8. Mais alors, la prochaine demande similaire prendra également 8 heures. Et celle d’après aussi.

Même les modifications les plus simples deviennent difficiles lorsque le système est trop compliqué.

Nous devons régler les problèmes, pas appliquer une solution temporaire.

Oui, cela coûte plus cher au départ. Mais c’est la différence entre :

• Passer 8 heures à chaque fois qu’un petit changement est nécessaire

• Passer 1 à 2 heures pour le même changement une fois que nous avons fait le ménage

Ce n’est pas un travail très attrayant. Il n’y a pas de nouvelles fonctionnalités à mettre en avant. Mais c’est la différence entre un système qui travaille pour vous et un système qui travaille contre vous.

En résumé

Cette modification « simple » a pris 8 heures parce que le système s’est développé au fil du temps. Il est complexe d’une manière qui n’est pas évidente de l’extérieur.

Je ne gonfle pas les estimations. Je suis honnête sur ce qu’il faut pour faire le travail.

La question principale n’est pas « Pourquoi cela prend-il autant de temps ? », mais « Comment pouvons-nous accélérer le processus la prochaine fois ? »