Le demi-cercle (épisode 7 -- Crise / Opportunité )

Managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other. I call such situations messes. Problems are extracted from messes by analysis. Managers do not solve problems, they manage messes. Russell Ackoff

Une fenêtre s'ouvre en bas à droite : Maria: passe me voir quand tu peux 15 mn aujourd'hui stp.

Tu sauves ton travail. Tu réponds : j'arrive. Tu prends de quoi écrire.

Maria t'invite à prendre place à la petite table ronde qui encombre le peu d'espace dont elle dispose dans ce bureau, ferme la porte et s'assoit en face de toi.

- Pendant que vous étiez en réunion hier, trois nouveaux tickets sont tombés. Tu les as vus ? - Oui. Ça vient de la dernière livraison, celle qu'on a faite vendredi. - 4236 : "Lorsque je soumets le formulaire, j'obtiens un message d'erreur en rouge, champ obligatoire. Tous mes champs sont renseignés. Impossible de valider le formulaire". - On a regardé. Je peux t'expliquer mais ça risque de prendre du temps. - 4237 : "Le volet Contrats ne s'ouvre pas systématiquement après validation du volet Adresse en mode mise à jour". - Là je sèche. Il est possible que la cinématique ne soit pas claire. - 4238 : "Le rapport de vente contient des blancs à la place des montants totaux; ce problème a été signalé, et corrigé dans la version précédente, mais il apparaît à nouveau dans cette version".

Tu restes coi. Maria reprend: - Ces tickets, ça met le projet un peu plus en retard. Qu'est-ce que je dis au prochain Copil ? - Tu pourrais leur dire qu'on a un problème structurel avec cette partie du code de l'application et qu'il va falloir investir un peu de temps dans la qualité avant de revenir à une situation normale… - Ce n'est pas ce qu'ils souhaitent entendre.

Respiration. Tu serais tenté de répondre, mais tu sens que la discussion est déjà assez compliquée comme ça. Inutile d'y ajouter des interlocuteurs absents ou des réponses imaginaires.

Maria reprend et te dit droit dans les yeux : - Je t'ai engagé pour résoudre les problèmes, pas pour en créer des nouveaux. Je croyais que ton approche des problèmes allait nous sortir du pétrin, pas nous y enfoncer un peu plus.

Respiration. Voilà une conversation intéressante à débugger. Avec patience et méticulosité. Rappelle toi. Patience et méticulosité.

- Mon approche, c'est d'éviter autant que possible de créer de nouveaux défauts quand je mets à jour le code, mais ça ne veut pas dire que je maîtrise la totalité du code. - Je vois ça.

Respiration. Ce qui rendrait cette conversation plus efficace, c'est que tu ne te sentes pas tant menacé. Au contraire, confiant dans la possibilité d'extraire ce bug, de le reproduire, de le diagnostiquer, et de le corriger une fois pour toute.

Si elle pouvait savoir à quel point ça n'a rien à voir avec qui agit sur le code, ou bien quel principe de résolution de problème est à l’œuvre. Cette base de code, c'est un labyrinthe aléatoire, un fatras plongé dans l'obscurité. Certaines parties sont inondées. Chaque tentative de sauvetage provoque de nouveaux éboulements. Il n'y a rien à faire, que de ramasser des débris ça et là, et les déplacer un peu plus loin.

Tu dis : - Ce n'est pas tellement une question de qui modifie le code, ou quelle approche adopter. C'est plus une question de marge de manœuvres. - Qu'est-ce que tu veux dire par là ? - Prends le réchauffement climatique, par exemple. - Pas sûre que ce soit un bon exemple. - OK. Ces trois nouveaux tickets: j'entends bien que tu aimerais qu'on te débarasse de ces problèmes. Si seulement on pouvait faire disparaître ces problèmes. - C'est ce que je te demande de faire. - Ces tickets, ce ne sont pas des problèmes à résoudre, ce sont des symptômes. - Et alors ? - Ce que tu me demandes, c'est de supprimer plus efficacement les symptômes. Mais faire ça ne changera rien aux causes profondes. - C'est quoi, les causes profondes ? - Est-ce que tu vois un inconvénient à ce je fasse une autre analogie ? - Non. - Bon. Représente-toi un type qui a de gros problèmes de santé. Il est en surpoids. Son coeur est fatigué. Il a eu une attaque. Son médecin fait le bilan avec lui. Il explique à son patient que durant ces vingt dernières années, celui-ci n'a pas eu un mode de vie très sain: nourriture trop riche, bien trop peu d'exercice, et surtout, un paquet de cigarette par jour ! - OK… - Le médecin prescrit : on arrête de fumer. On bouge un peu. Pas trop, il ne faut pas rêver. Une alimentation saine. Alcool hors de question. Et la personne lui répond : oui docteur, mais pas tout de suite. J'ai juste besoin que vous me remettiez en forme parce que ce soir c'est l'anniversaire de la boîte et il se prépare une fiesta d'enfer. - C'est ridicule. - Ce que je veux dire, c'est que le problème de cette application ne va pas se résoudre en quelques bugfixes. Le temps pour remédier à ce problème est en proportion du temps que le problème a pris pour se mettre en place, à savoir plusieurs années. - Ça, ça reste à prouver!

Tu ne sais pas exactement si Maria ressent plus de la colère, de l'impatience ou de l'anxiété. Mais tu ne trouves pas le courage de le lui demander.

Tu reprends : - On parle de deux cent cinquante mille lignes de code. - Ça doit pourtant être possible de produire du code qui ne contient pas de défauts ! Est-ce qu'au moins tu expliques à tes coéquipiers ce qu'il faut faire ? - Si pour résoudre un problème il suffisait d'expliquer comment faire, le monde serait très différent. - Epargne-moi la philosophie. Je te parle de bugs en production, constatés par des clients référents ! Il y a forcément quelque chose à faire.

Respiration. C'est comme si tu venais d'inviter ta responsable à faire une incursion dans les dédales obscurs du code. Comme les autres, elle se cogne brutalement dans les obstacles invisibles, mais elle fait de cette expérience une interprétation très différente. Elle se figurait un espace simple, fonctionnel, à l'architecture bien pensée. Elle raisonne en termes de plans, de projets, de résultats. Elle ne s'attendait pas à trouver tant d'étages en ruines, pas de lumière, pas d'ascenseur, pas d'escalier, rien à quoi s'accrocher.

Tu reprends : - Ça peut être utile qu'on décortique ensemble la 4236, si tu as un peu de temps. - J'ai exactement huit minutes.

Tu ouvres ton cahier et tu esquisse un formulaire. - On a reproduit le bug, et on a fait une rétro-analyse. Quand l'utilisateur saisit le formulaire, une des options, lorsqu'elle est cochée, fait apparaître deux nouveaux champs. S'ils sont présents à l'écran, ces champs sont obligatoires. L'utilisateur commence à saisir l'un des deux champs, puis change à nouveau l'option. Les deux champs disparaissent. L'utilisateur valide le formulaire, ce qui déclenche le contrôle des champs saisis. Le contrôle voit qu'un des deux champs est saisi et en déduit que l'autre champ devrait être également saisi. "Champ obligatoire" apparaît en haut de la page. Si le champ en question était visible, il apparaîtrait aussi en rouge. L'utilisateur se retrouve devant l'obligation de saisir un champ qu'il ne voit pas. - C'est idiot ! Comment est-on arrivé à une telle situation ? - Dans la version précédente, on n'avait pas une option à cocher, mais trois champs, disons  A, B et C pour faire court. B et C apparaissaient selon que A était renseigné ou non. Pour le contrôle, la règle était : Lorsque le champ A est renseigné, les champs B et C doivent être également renseignés. On a remplacé le champ A par une option à cocher. On a ensuite modifié le contrôle : la règle est devenue : lorsque le champ B est renseigné, le champ C doit être renseigné également. Mais du coup l’option à cocher n’est plus utilisée dans le contrôle, ce qui explique que le contrôle puisse empêcher la validation à tort. - Je vois. C'est une erreur de logique. - Exactement. - Qu'est-ce qui t'a empêché de relever cette erreur de logique ? - Nous avons retesté l'ensemble du formulaire, dans les deux cas : option cochée, décochée. Mais pas dans le cas ou l'option à été cochée, un champ sur deux renseigné, puis l'option décochée. On ne peut pas tout tester… - J'entends bien qu'on ne peut pas tout tester. Tu ne comprends pas ma question : qu'est-ce qui t'a empêché de relever cette erreur de logique avant les tests ?

Tu reste coi. Est-il possible que Maria se figure que tu relis le code de toutes les mises à jour avant que la version repasse en tests de recette ?

- On n'a pas exactement le temps de relire tout le code, Maria. Ce n'est pas la stratégie de la boîte. - C'est trop facile de mettre ça sur le compte de la stratégie !

Maria semble furieuse à présent. C'est comme si tu venais de lui dire : cette baraque aveugle, en ruine, où tu trébuches tous les deux pas, ce n'est pas qu'une question d'exécution. Ça faisait peut être partie du plan. "On va construire ça là, et puis on mettra un deuxième étage au dessus. Pour les piliers centraux on verra plus tard, pour l'instant il n'y a pas le budget. Vite."

Respiration. Ça ne sert à rien de railler, ni de batailler.

- Rectification. Au temps pour moi. Je ne parle pas de la stratégie, je parle du process. - Qu'est-ce qui ne va pas dans notre process ? - Dans notre process il n'y aucune place — mais alors, aucune — pour la prévention. - La prévention ? - Tu me demandes si je n'aurais pas pu relever cette erreur avant les tests. Ma réponse est : non. - Je vois. - Pour reprendre une analogie médicale, c'est comme si on était là dans un hôpital, à se demander pourquoi tant de personnes deviennent malades, et à tenter de les soigner, un patient après l'autre, tout en étant complètement ignorant des règles de bases de la médecine comme la présence autour de nous des microbes, et la pratique qui consiste à se laver les mains. - Eh bien je compte sur toi pour changer ça. - Avec quel budget ? - Je n'ai pas de budget. Il faut que j'en demande un. J'ai besoin d'une estimation avec des prévisions de résultats. Sur trois mois.

Encore une fois tu restes coi. Tu es encore au milieu des débris sans lumière. Ta responsable est déjà sur le prochain palier. Qu'est-ce que tu attends ?

- Banco. Je veux explorer cette technique mob programming… - Plus d'exploration. Tu me trouves une solution. - Je suis pas sûr d'avoir une solution à ce stade… - Tu me trouves une solution que je puisse vendre en Copil. - Je vais voir ce que je peux faire.

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch 6 -- Conseils à emporter