L’IT est un vaste domaine avec ses différentes spécialités parmi lesquelles nous trouverons par exemple les infrastructures, la gestion des données, la sécurité, l’UI et l’UX et naturellement la production logicielle.

S’il y a bien une constante dans la production logicielle, c’est son faible niveau de qualité. Prenez 10 développeurs au hasard dans votre entreprise ou celle de votre prestataire, il est très probable que vous n’en trouviez qu’un seul qui osera prétendre que les défauts de qualité ne sont pas une fatalité. Et s’il le fait, il vous demandera de ne surtout pas faire état de ses déclarations devant ses collègues et manageurs.

Il y a donc d’un côté des acteurs de la chaîne de valeurs qui sont persuadés que la non-qualité, on ne peut pas l’éviter, et à l’autre bout, des utilisateurs de systèmes d’information qui essaient de naviguer entre les bugs et interruptions de service.

A la faveur d’une nouvelle crise de nerf, un cadre de l’entreprise finit par taper du poing sur la table et décrète que la non-qualité, à tout le moins celle vue par les utilisateurs, doit disparaître. Comme les mots ont un sens, l’organisation va donc déployer son énergie à atteindre cet objectif.

L’arrivée du responsable qualité

Puisqu’on ne peut s’empêcher de produire de la non-qualité et que l’utilisateur ne doit pas la voir, un acteur va voir ses responsabilités, mais pas forcément ses moyens, croître rapidement au sein de l’organisation : le responsable qualité. En soi, si des bugs arrivent sous le nez de l’utilisateur, ce n’est pas parce qu’ils ont été produits en amont, mais bien parce qu’il a échoué à les capter. Dans les œufs au bacon, chacun sait qu’il vaut mieux être la poule que le cochon. Dans notre cas de figure, le responsable de la qualité est clairement celui qui fournit le bacon ! Au bout de quelques mois et des semaines de 60 heures, l’étape « qualité » s’est considérablement étoffée de tests unitaires, de tests d’intégration, de tests de performance, de tests de non-régression, de tests business, de tests key users, etc… Les seules limites sont l’imagination et la disponibilité des acteurs impliqués dans cette grande opération « coup de propre ».

Enfin, tout cela porte ses fruits, et il est tout à fait classique de voir le flux de bugs visibles des utilisateurs divisé par 4 ! Le stock de bugs en attente d’être corrigés est lui-même ramené à zéro en moins de 6 mois. Certains sont parfois surpris du résultat, mais il est somme toute assez logique : l’organisation fait ce qu’on lui demande pour peu qu’on prenne soin de mesurer régulièrement que la trajectoire est bien celle attendue et qu’on répète l’objectif tout aussi régulièrement.

Les clients sont contents. Le cadre à l’origine de ce changement est satisfait et il le dit aux équipes. Pourtant, les équipes ont du mal à goûter aux fruits sucrés de ce succès. Et pour cause, la quantité de fonctionnalités à livrer n’a pas baissé, en revanche la charge de travail pour livrer, « bon du premier coup aux utilisateurs » a considérablement augmenté.

L’insupportable alourdissement de la charge de travail des équipes de développement et de tests

Que s’est-il passé ? Prenons à titre d’exemple un flux classique de production logicielle.

Tout d’abord, sans surprise, on observe que lorsqu’on cherche la non-qualité, on la trouve !

En termes de nombre de bugs trouvés, il n’y a pas de changements significatifs. En revanche, ce qui a changé, c’est que dès lors qu’il n’est pas question de renoncer à livrer, à l’heure, une fonctionnalité promise, chaque bug fait l’objet d’une correction immédiate. Parfois, le bug fait l’objet de plusieurs corrections inopérantes successives. On trouve là l’origine de l’insupportable alourdissement de la charge de travail des équipes de développement et de tests. On a bien changé le résultat du point de vue de l’utilisateur de l’application IT, sans rien changer aux méthodes de production logicielle. Sans rien faire de plus, il n’y a de choix qu’entre trois voies :

• Augmenter la taille des équipes et la charge de management et de services connexes ;
• Laisser se dégrader la qualité et revenir en quelques mois à la situation de départ ;
• Constater la baisse de productivité de l’équipe et adapter à la baisse la quantité de fonctionnalités livrées aux utilisateurs.

En faisant preuve d’un peu de recul sur la situation, si l’on tient seulement compte de ce qui est livré sans bug avant et après qu’on se soit intéressé à la non-qualité, il est probable que la productivité réelle de l’équipe soit restée inchangée à ce stade.

Mais alors, que faire ?

Une mesure du temps passé par l’équipe sur le codage initial et sur les corrections ultérieures donne rapidement une vision très claire de la nature et de l’importance du problème de productivité . Prenons par exemple l’équipes des développeurs.

En observant ce graphique, on constate deux choses :

• Le temps alloué aux corrections de bugs ou de non-conformités est 3 fois celui alloué au codage initial.
• Il existe une somme d’activités accessoires équivalent à 3 fois le temps dédié au codage.

Nous nous concentrerons sur le temps passé sur les corrections. En effet, en le divisant par 3, et en le dédiant au codage de nouvelles fonctionnalités, nous pourrions améliorer la productivité de 200 %. A « performance » de non-qualité équivalente, la division par 3 du temps passé sur les tâches « autres » n’améliorerait la productivité « que » de 50 %.

Arrêtons de produire des bugs

Comment ne plus faire de retouches sur les fonctionnalités codées ? La réponse coule de source : arrêtons de produire des bugs. Qui produit des bugs ? Autre évidence : les développeurs. Pourquoi codent-ils des bugs ? Dans un premier temps, ce n’est pas la bonne question. En effet, avant le pourquoi, il y a d’abord le « quoi ». La collecte des informations sur la nature de ce qui est corrigé est un préalable nécessaire pour prendre du recul. Néanmoins, le côté post-mortem de cette collecte a tendance à rebuter les développeurs. Intégrer la collecte de ce qui a été corrigé au moment de la correction passe mieux auprès de personnes surchargées. Cela aboutit à un Pareto qui permet de comprendre que la non-qualité, comme la qualité, sont des œuvres collectives.

En effet, les développeurs codent rarement mal dans le sens d’un programme qui exploserait spontanément à son lancement. Coder est une chose pour laquelle la progression des personnes est rapide. En revanche, comprendre ce qu’on nous demande de coder, être capable d’évaluer si nous disposons de tous les éléments pour coder la bonne chose, avoir les informations et les moyens techniques de savoir si nous avons codé la bonne chose, sont des questions qui demandent plus de maturité, tant à l’échelle des personnes que de l’organisation.

L’utilisation d’outils de résolution de problèmes comme le PDCA ou le QRQC permet d’identifier rapidement que certes, à l’endroit ou émerge la valeur – au moment du codage -, quelque chose se passe, mais on découvre tout aussi rapidement que de nombreuses défaillances existent et peuvent être résolues bien en amont des développements. Ce sont les standards de production de tous les entrants qu’il faudra alors définir et faire évoluer au rythme des découvertes.

Dès lors que la non-qualité est traitée à l’endroit où elle est produite, les résultats ne se font pas attendre : la bosse se décale vers le début du processus.

Ce glissement en amont permet plusieurs choses :

• Les équipes de développement se libèrent du temps pour le codage de nouvelle valeur.
• Les équipes d’analystes limitent la charge de travail apportée par le surplus de tests à réaliser à chaque correction. Cela tombe bien car ce sont souvent ces équipes qui écrivent les spécifications.
• La collaboration à couteaux tirés laisse place peu à peu à la coopération. Cela a une incidence directe sur la qualité de vie au travail.
• Les manageurs peuvent se libérer du temps pour les activités d’une hauteur stratégique nettement plus élevée que de devoir jouer aux pompiers diplomatiques avec les utilisateurs.
• La confiance des utilisateurs est en hausse.
• La productivité est en hausse et la production accélère, ce qui rend la DSI plus agile et plus à même de rendre les services attendus par le reste de l’entreprise.

Ne l’oubliez pas, pour réussir, il faut déplacer la bosse de la non-qualité toujours plus loin vers la gauche. Naturellement, il vaut mieux le faire avec conviction, persévérance et bienveillance !