Débutant

Une fable de qualité ?

mechanicIl est souvent difficile de faire comprendre à une équipe de développement pourquoi elle doit produire un code de qualité.
Pire, il est encore plus compliqué d’expliquer ce qu’englobe le terme qualité, car la définition varie souvent d’une personne à l’autre.
Par conséquent, sans prétendre égaler le célèbre poète La Fontaine, je vous propose une petite analogie qui devrait vous aider à inclure dans votre définition une part souvent oubliée, et pourtant essentielle, de la “qualité”.
En toute humilité, je l’appellerai “La Fable du Concessionnaire et du Garagiste”.

Maître Corbeau…

dismantled-carImaginons un concessionnaire d’une grande marque automobile. Il reçoit beaucoup de clients (potentiels) et échange beaucoup avec eux, à tel point qu’il est à peu près capable de savoir quelle est la voiture de rêve des clients (potentiels) de sa marque. J’oserai même aller jusqu’à dire qu’il a une très bonne idée de leurs besoins (oui, vous me voyez venir mais le cœur du sujet n’est pas tout à fait là).

En employé modèle, il remonte ces informations au centre d’ingénierie du constructeur. Il envoie une liste ordonnée des fonctionnalités et autres options que la voiture parfaite devrait avoir selon ses clients. Il fixe même le prix maximum du véhicule idéal d’après eux. Et surtout, il demande aux ingénieurs d’aller vite, il ne voudrait pas que ses clients aillent voir chez les concurrents. Il faut battre le fer tant qu’il est chaud, même si on ne travaille pas pour une marque sportive au cheval cabré !

Les ingénieurs respectent scrupuleusement cette demande. Toutes les fonctionnalités sont intégrées au véhicule, il sort des chaînes de montage très rapidement et son prix ne dépasse pas la barre psychologique imposée par les clients. Le succès est au rendez-vous, les acheteurs sont ravis, la voiture a tout ce qu’ils espéraient !

Un an plus tard, c’est l’heure de la première révision de routine. Jusque-là, les véhicules n’ont eu que très peu de problèmes, voire aucun. Et qui mieux que…. [insérer votre marque ici] pour réparer votre [votre marque] ? Du coup, les clients viennent majoritairement chez les garagistes affiliés au même groupe que le concessionnaire. Et là, surprise ! La vidange + la révision des un an dépassent les 1000€.

“Vous comprenez, pour atteindre le bouchon de vidange, il faut démonter les blocs optiques, déposer le pare-choc, enlever le radiateur, et débrancher la clim’… ”

Le garagiste, autant que ses clients, est effaré, voire dépité, devant ce manque de bon sens des ingénieurs. Pourtant, ces derniers se vantent tellement souvent de faire “de la qualité”…

Le garagiste appelle le centre technique de la marque pour exprimer son incompréhension (voire un peu plus). On lui répond que, pourtant, le taux de retours est extrêmement faible ; donc que les ingénieurs ont bien fait de la qualité.

La morale de cette histoire…

Raccrochons un petit peu les wagons (je n’ai pas trouvé d’expression avec des voitures, dommage) avec le développement logiciel.
L’équipe de développement est facilement assimilable à l’équipe d’ingénieur ayant conçu la “voiture de rêve”. Que ce soit dans un état d’esprit agile, mettant en avant les besoins des utilisateurs, ou tout simplement “parce que le client est roi”, elle a ajouté un maximum de fonctionnalités à son application. Qu’elle l’ait fait exprès ou pas, l’application n’a pas eu de problème une fois en production. Et l’équipe se dit qu’elle a fait de la qualité. C’est vrai ! Enfin…. presque !

Une bonne partie de la qualité correspond effectivement à la robustesse de l’application. C’est déjà une excellente chose que d’avoir de tels attributs pour son code et son application. Cependant, une autre part de la « qualité », non négligeable elle non plus, réside ailleurs. Si vous posez la question à vos ingénieurs, ils vont très souvent vous suggérer que l’autre partie pourrait résider dans l’adoption de technologies de pointe et/ou ayant des performances importantes. C’est plutôt faux, ou au moins pas toujours vrai. En revanche, ce qui est sûr, c’est que la maintenabilité, la facilité d’entretien, de prise en main, de lisibilité et d’évolution font partie de ce qu’on DEVRAIT mettre sous le terme “qualité”. Il y a de multiples articles et vidéos qui détaillent ce qui constitue la maintenabilité. Ici, nous nous contentons de mettre en évidence à quel point elle est importante et prépondérante pour faire une application “de qualité”.

Si votre équipe n’est pas sensible à ça (“c’est pas grave si la maintenance est compliquée, l’important c’est de satisfaire le client / après nous, le déluge”), il suffit de leur donner la perspective suivante : souvent, comme pour les garagistes, le client actuel, les utilisateurs actuels vont faire appel aux mêmes ingénieurs pour la maintenance que ceux auxquels ils ont recouru pour la conception d’origine. Et dans ce cas, ces ingénieurs (devenus garagistes, finalement) sont aussi des utilisateurs. Pas des utilisateurs du produit fini “application” mais utilisateurs du produit “code à maintenir et à faire évoluer”. Et comme ils ont à cœur de satisfaire les utilisateurs, ils seront ravis de s’être mis dans les meilleures conditions en ayant écrit un code facilement maintenable.

concept-carCela ne veut pas dire que vous ne devez pas travailler en parallèle sur des concept cars aux technologies de pointe, pas forcément industrialisables tout de suite, mais permettant à vos ingénieurs de recueillir les impressions du public aux fonctionnalités les plus avant-gardistes et osées.
Dans un (éventuel) prochain article, nous filerons cette analogie entre Proof of Concept et Concept Car. Nous pousserons peut-être même jusqu’à la notion de MVP(e), Minimum Viable Product (experiment).

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT

Nombre de vue : 590

COMMENTAIRES 1 commentaire

  1. […] Source : SOAT Blog » Une fable de qualité ? […]

AJOUTER UN COMMENTAIRE