Muda (I)

le 01/12/2007 par Christophe Thibaut
Tags: Product & Design

Pour la plupart de mes collègues, M. K était juste un excentrique. C'était notamment ce que pensait Baptiste, mon ancien chef de projet. Voici comment il fit sa connaissance.

Baptiste avait recruté un nouveau développeur afin de démarrer une refonte avec de meilleures chances de tenir les délais, et il le tenait en grande estime:

- Il faudrait que tu voies ce développeur à l'oeuvre, il est génial. Il est entré dans le code existant sans aucun problème. Il a un écran sur lequel il lit ce code, et simultanément sur un autre écran, il produit la v2. - Impressionnant. Et ça marche ?
- Du feu de Dieu. Et il connaît l'outil de développement bien mieux que les gars que j'ai envoyé en formation cet été.

Quelques semaines plus tard, je croisais Baptiste dans l'ascenseur:
- Alors ce projet ? Et ton développeur, toujours aussi génial ?
- Génial, mais peut être un peu tête en l'air. Disons qu'il reste quelques bugs dans le programme. La recette a démarré lundi, et ça se passe plutôt mal.
- A ce point là ?
- Le Maître d'Ouvrage l'a dans le collimateur --c'est Jean-Pierre, tu connais le personnage. Hier en comité il déclaré: "On perd du temps, là". Le pire, c'est que mon développeur l'a pris de haut, figure-toi.
- C'est à dire ?
- Il lui a répondu, comme ça: "Je peux ne pas corriger les problèmes, si vous voulez !". J'hésitais à le faire venir en comité, mais là, je suis fixé, c'est la dernière fois.
- Qu'est-ce qu'a répondu JiPé ?
- Il a respiré un grand coup. Puis il a dit que non, qu'il fallait les corriger, que c'était inévitable.
- OK.
- Puis il a ajouté: "Mais on est mis devant le fait accompli. Notre client paye pour des fonctionnalités, pas pour des corrections de bugs!"
- Je vois. Qu'est-ce que tu vas faire ?
- Bonne question. Je suis déjà en dépassement de budget. Et on ne peut pas laisser le programme en l'état.

C'est alors que je m'entendis proposer à Baptiste :
- Qu'est-ce que tu dirais de demander son avis à M. K ?
Nous déjeunâmes avec M. K le surlendemain. Lorsque Baptiste exposa la situation, M. K écouta avec attention, puis il demanda :
- Et donc, qu'est-ce que vous comptez faire ?
Cette question troubla quelque peu Baptiste, qui s'attendait plutôt à recevoir des conseils. Il répondit :
- Je ne sais pas; qu'en pensez-vous ?
- Votre client a raison de ne pas vouloir payer pour la correction des défauts. Les défauts sont du gaspillage, du temps perdu. Le client n'a pas à les supporter financièrement.
- Sauf s'ils proviennent du client lui-même.
- Est-ce le cas ?
- Euh non. Je ne pense pas...

M. K réfléchit un instant puis demanda :
- Et depuis quand avez-vous ce problème ?
- Lequel ?
- Le problème du code, qu'il faut déboguer et corriger...
- Depuis le début de la semaine : la recette a commencé lundi.
- Vous voulez dire que la semaine dernière ce code marchait encore correctement ?
- Non. Je n'en sais rien. Vous savez, c'est une fois qu'il est livré en recette que l'on voit si le code fonctionne parfaitement.
- Je vois.

M. K resta un moment sans rien dire, l'air soucieux. Je commençais à regretter mon initiative. En réfléchissant à ce que venait de dire Baptiste, il me vint une idée:
- Au fond le problème était là depuis plus longtemps, si on y réfléchit.

Baptiste se tourna vers moi:
- Qu'est-ce que tu veux dire ?
- Supposons que tu fasses un voyage particulièrement harassant. Au moment de boire un peu, tu constates que ta gourde est percée et qu'il te reste à peine une gorgée d'eau ! C'est un problème. Question: depuis quand as-tu le problème ?
- Depuis que la gourde est percée ?
- Voilà.

Un autre silence se fit. M. K m'engagea à poursuivre :
- C'est une comparaison intéressante.

Je rassemblais mon courage et tentais de m'expliquer:
- Baptiste: c'est aujourd'hui que ton développeur a besoin de temps supplémentaire, n'est-ce pas ?
- Oui.
- Les bugs apparaissent seulement cette semaine, mais ils sont déjà là depuis longtemps. C'est juste qu'ils étaient invisibles.
- Qu'est-ce que ça change ?
- Invisibles, mais peut être prévisibles. Après tout, personne ne peut travailler sans faire aucune erreur.
- Où veux-tu en venir ?
- Ce serait sans doute plus facile aujourd'hui pour vous, si vous aviez prévu que ces bugs se produiraient. Ca aurait permis de planifier leur correction, et d'éviter la crise en comité de projet. Qu'en penses-tu ?

A ce point de la discussion, Baptiste semblait au comble de l'agacement. Il s'écria :
- Tu en as de bonnes! On n'a pas la science infuse chez nous! On ne lit pas non plus dans le marc de café! Si je savais précisément quand les bugs arrivent dans le code, nous ne serions pas là à en discuter!

M. K sourit légèrement, et fit signe qu'il comprenait cette objection. Il reprit:
- Bien sûr, il est difficile de savoir avec précision si un défaut est présent dans le code et depuis quand exactement.
- Ah, fit Baptiste, tu vois bien, Chris!

Baptiste, apaisé, nous observait tour à tour. Au bout d'un moment, il déclara:
- En fait je ne cherche pas à prévoir du temps pour les défauts: je préfèrerais que ces défauts ne se produisent pas!

M. K reposa doucement ses couverts sur son plateau.
- Si c'est là votre but, dit-il, je crains que ni votre ami, ni moi, ne puissions vous aider.
- Pourquoi ça ?
- Vous dites ne pas savoir précisément quand surviennent les défauts.
- Oui.
- C'est votre Maître d'Ouvrage qui les identifie, à la fin du projet.
- Et donc ?
- Comment voulez-vous éviter un gaspillage que vous ne pouvez pas détecter à temps ?

(à suivre)