Nous connaissons tous le concept de « One Team ». Nous avons peut-être vécu ce moment où le produit, l’engineering et les opérations étaient unis vers un objectif commun. C’est énergisant jusqu’à ce que nous soyons confrontés à des actions divergentes.

Imaginez découvrir un ingénieur de développement qui préfère optimiser son code plutôt que de livrer les priorités définies aux utilisateurs. De son point de vue, il a raison : « Pour moi (seulement), c’était important ».

Réussir la mise en œuvre d’une qualité en équipe résulte de la combinaison d’éléments clés. Dans cet article, nous identifions les difficultés d’une démarche « Une qualité, une équipe » partageant les orientations de mise en œuvre pour chaque point :

• Une Qualité non comprise doit être alignée de manière collaborative
• Une Qualité vue comme « encore une priorité » doit être intégrée
• Une Qualité qui n’est pas une priorité personnelle doit en devenir une
• Une Qualité en silo doit être diffusée de manière organisationnelle

Rejoignez la QE Unit pour faire partie de la communauté Quality Engineering pour accéder à des contenus communautaires réguliers et exclusifs.

Une qualité non comprise doit être alignée de manière collaborative

La collaboration des membres de l’équipe commence par une compréhension partagée de leurs rôles vers un objectif commun. Ce n’est pas anodin pour une Qualité rarement associée aux problématiques utilisateurs et métiers, restant le plus souvent à l’intérieur d’un silo technique. 

Dans le monde du logiciel, la Qualité a tendance à être associée principalement aux tests. Cette vision partielle de la dimension globale de la qualité matérialise sa subjectivité chez les acteurs. Une compréhension partagée de la Qualité passe donc par l’écoute, l’empathie et une vision commune construite par la collaboration. Nous couvrons un exemple dans cette table ronde de la Qualité sans test.

Ce travail d’alignement est le préalable d’une démarche « One Quality One Team ». L’équipe doit comprendre que, comme dans un match de football ou un orchestre, les joueurs doivent contribuer différemment pour produire un résultat de qualité. C’est la même chose avec le logiciel ; Un seul défenseur de la QA ne peut pas atteindre la qualité. C’est le résultat d’une collaboration réussie.

Une qualité intégrée est difficile à atteindre lorsqu’elle est perdue au sein d’autres priorités.

Une qualité considérée comme « une autre priorité » doit être intégrée

Le développement de logiciels est un défi, en particulier lors du démarrage d’un nouveau produit ou d’une release sous pression. Les délais doivent être respectés à tout prix avec la pression des parties prenantes, où la Qualité sera abordée « dans un second temps ».

La qualité considérée comme une exigence à part entière est un problème. Cela ne tient pas compte de la nécessité de fournir la valeur minimale aux utilisateurs, pensant que nous pouvons la récupérer plus tard. En faisant un parallèle avec la nourriture, mangeriez-vous du pain non cuit parce que c’était « plus rapide et moins cher » ? Il s’agit du niveau de logiciel que certaines organisations fournissent à leurs utilisateurs. Dans ce contexte, la capacité à négocier la qualité fera la différence.

« L’amertume de la mauvaise qualité persiste longtemps après l’oubli des prix bas. »

Benjamin Franklin

Le deuxième aspect d’une Qualité de second rang suppose que l’on puisse la récupérer plus tard. On peut par exemple récupérer des tests automatisés par la suite, au prix d’éventuels problèmes de releases et d’un coût d’exécution manuelle. On peut changer l’architecture au prix de sa refonte et de son coût d’opportunité. Toutes ces retouches sont finalement coûteuses. Par contre, on peut difficilement récupérer des utilisateurs insatisfaits. 

À sa base, une Qualité non-considérée est conduite par des individus.

Une Qualité qui n’est pas une priorité personnelle doit en devenir une

Les humains sont guidés par leurs propres intérêts, un mécanisme de survie hérité de nos ancêtres. Les acteurs impliqués dans le logiciel appliquent le même raisonnement en se demandant « Qu’est-ce que j’y gagne ? ». Les acteurs ont donc besoin de voir de la valeur de travailler les attributs de qualité.

Le point précédent de collaboration et de conception organisationnelle influence le besoin de qualité d’un point de vue individuel. Un directeur marketing liant la qualité à un NPS amélioré et aux performances commerciales est plus susceptible de considérer la qualité comme une priorité. Pour atteindre le « One Quality One Team », le même niveau d’influence est requis pour atteindre le Tipping Point de la Qualité.

L’aspect multidimensionnel de la Qualité est la deuxième difficulté de faire de la Qualité une priorité personnelle pour les parties prenantes. Cela rend plus difficile d’avoir une vue d’ensemble, d’atteindre un véritable équilibre et une meilleure priorisation. Un SRE pensera facilement aux exigences de performances ou de fiabilité mais moins à la facilité d’utilisation par exemple. Si le responsable Qualité peut avoir la vision d’ensemble, il doit réussir à l’aligner au sein de l’organisation.

La combinaison des différents points de vue et expertises fera la différence.

Une qualité en silo doit être répartie de manière organisationnelle

Notre besoin de survie crée la tendance à rester dans notre écosystème connu et à l’optimiser sans nécessairement considérer la situation dans son ensemble. Par exemple, nous nous concentrons principalement sur notre cercle familial, notre maison et notre quartier. Une contre-force est donc requise.

La qualité vient avec son image historique de contrôle qualité et d’assurance qualité où les produits sont sortis de la chaîne de fabrication pour être vérifiés par une autre équipe. Bien que cette approche puisse être utile dans une certaine mesure pour le logiciel, elle n’est certainement pas suffisante pour répondre à l’approche « Une équipe, une qualité». Un seul silo Qualité n’est pas la réponse. Une articulation différente est nécessaire.

La responsabilité Qualité doit être conçue au sein de l’organisation, généralement à 3 niveaux. Le premier est de niveau « VP » ou « Chief », pour avoir le sponsorship et la responsabilité jusqu’au niveau du conseil d’administration. Le second est celui d’« Enabler » ou de « Servant Leader », ayant des personnes capables d’aider les équipes opérationnelles dans leurs responsabilités de qualité. Le dernier est de responsabiliser l’équipe sur son niveau de qualité, en s’appuyant sur les deux autres niveaux de support.

Atteindre une Qualité partagée dans une équipe est donc un sujet plus vaste.     

Une équipe, une qualité, avec le Quality Engineering

Nous avons couvert les points durs du paradigme « Une équipe, une qualité» : une compréhension partagée, un alignement global (individu, équipe et organisation) et une conception organisationnelle. Le Quality Engineering peut nous aider.

Le Quality Engineering contraint chaque activité du cycle de vie du logiciel à offrir en permanence de la valeur à ses utilisateurs. Dans notre cas, le management joue un rôle clé dans l’alignement et l’animation des acteurs par la collaboration.

Nous pouvons nous appuyer sur le framework MAMOS en se concentrant sur les deux aspects du Management et de l’Organisation. « One Quality One Team » résulte d’un effort réussi de gestion du changement, permettant aux acteurs d’intégrer la qualité au bon niveau.

Finalement, « One Quality One Team » rime bien avec Quality Engineering.