Comment se préparer à, et survivre à, des décisions de livraison/non-livraison

La réalité frappe

On peut, parfois de façon fructueuse, aborder les questions fondamentales du processus QA, des outils, de l’état d’esprit, de l’éthique professionnelle et de l’expertise. Ce qui est formidable. Ces sujets constituent un exercice mental nécessaire pour tout véritable professionnel QA ou toute personne en formation. Ils font également de très bonnes conférences TED, ce qui joue en leur faveur. Car on peut publier ces vidéos sur les réseaux sociaux jusqu’à la fin des temps.

Mais parfois, il faut aussi aborder les dures réalités du quotidien en QA, même si se confronter à ces réalités relève d’un pragmatisme pur, qui ne nécessite aucun saut quantique dans la compréhension des processus, ni de penser "en dehors des sentiers battus". 

Mais c’est justement le contraire : Plonger dans la boue et le tumulte de ce qui s’accumule précisément dans cette fameuse boîte ne peut pas être évité par la seule force de l’imagination. Parce que ce n’est pas une boîte, pour commencer. C’est une arène impitoyable.

C’est donc de cela que traite cet article. Il n’a rien de nouveau ni de « révolutionnaire » à proposer, mais il partage des réflexions et des conseils très pratiques, tirés de mes propres expériences, parfois éprouvantes, de leader QA sur plusieurs décennies, ainsi que des leçons que j’en ai tirées. C’est ma propre « réalité exécutive QA », en quelque sorte. Des leçons que, bien sûr, vous êtes libre d’ignorer, de contredire ou de tourner en dérision si vous le souhaitez.

Quiconque a occupé un poste de direction QA pendant un certain temps sait qu’un aspect central — et traumatique — de cette expérience est la fameuse réunion « on livre ou pas ». Et d’y survivre. 

Car c’est là que tout se joue, et que QA est interrogé comme un suspect dans une affaire de meurtre, tous les autres « parties prenantes » prenant le rôle de détectives (un euphémisme s’il en est). Et, comme tous les détectives, tout ce qu’ils attendent de vous, c’est que vous finissiez par signer les aveux.

Mais il n’est pas obligatoire que cela se passe ainsi. Tout ce dont vous avez besoin, c’est d’un alibi en béton. J’écris cet article pour vous en donner un.

L’heure de l’histoire

La plus grande erreur que font les responsables QA en abordant une réunion « on livre ou pas » est le manque de préparation. Ou plutôt, l’absence de préparation efficace. 

La plupart des responsables ou managers QA arrivent « préparés » à cette réunion, principalement, voire exclusivement, avec des métriques de bugs : nombre d’incidents ouverts, nombre d’incidents ouverts de catégorie A, nombre d’incidents ouverts de catégorie B, etc. Parfois, si le reste de l’équipe a de la chance, le responsable QA pourra donner une vue plus ou moins vague de la couverture de tests atteinte par QA à ce moment-là. Mais en général, les données utilisées ne sont qu’un inventaire des tests et scripts exécutés. Ce qui n’est en rien une mesure réelle de la couverture de test. Ce ne sont que des métriques d’effort, pas de véritables métriques de qualité.

L’erreur dans cette stratégie va au-delà de l’utilisation de métriques ambiguës ou dénuées de sens pour tenter de construire (d’une façon ou d’une autre ?) un argument en faveur ou contre le lancement. L’erreur est bien plus fondamentale.

Car la stratégie décisionnelle QA décrite ci-dessus repose sur une évidence de confusion des catégories. Dans ce scénario, la direction QA suppose que le but de la réunion « on livre/on ne livre pas » est de présenter des données pour que d’autres puissent en prendre connaissance et décider eux-mêmes. Rien n’est plus éloigné de la réalité, ni plus dommageable pour l’autorité de la QA.

Ce que les autres membres de l’équipe produit attendent de la direction QA lors de cette réunion, ce ne sont pas plus de données. Ils attendent un verdict clair et autoritaire sur la question de savoir s’il faut lancer le produit ou non. Maintenant. Aujourd’hui. 

Bien sûr, les données sur les tests et les défauts seront nécessaires pour justifier et obtenir l’adhésion à l’avis d’expert de QA, quel qu’il soit. Mais c’est bien un verdict autoritaire que QA doit apporter. 

Sinon, QA abandonne sa responsabilité unique et son autorité au sein de l’organisation de livraison produit. C’est par essence de l’évitement et une attitude passive-agressive. Ce qui ne fait rien pour renforcer la position de QA dans cette même organisation. 

À terme, cela mène inexorablement à la disparition de toute chance pour QA de devenir un acteur à part entière du processus de développement. Une situation dont QA se plaint sans fin alors que, bien souvent, elle participe, pour cette raison même, à sa propre mise à l’écart.

Cela signifie que la direction QA doit arriver à la réunion « on livre ou pas » avec un récit clair et convaincant menant à une recommandation sans ambiguïté. Autrement dit, vous devez arriver à cette réunion prêt, et volontaire, à signer, en lettres de sang numérique, la recommandation que vous défendez. Pas de réponses évasives. Pas de boucliers brandis derrière une plausible dénégation. 

Car si vous ne le faites pas, vous et votre équipe perdrez toute crédibilité au sein de l’organisation. Pire encore, vous vous exposerez à être tenus pour seuls responsables si d’autres prennent cette décision à votre place et qu’un désastre qualité se produit sur le terrain. Ce qui, soyons honnêtes, est exactement ce que souhaitent les autres pôles. Ils veulent vous rendre responsable de tout et utiliser vos hésitations sur la qualité du produit comme une preuve à charge.

Un facteur clé qui alimente cette attitude passive-agressive dans la décision « on livre/on ne livre pas » est la conviction — souvent utilisée à dessein — que « de toute façon, peu importe ce que je dis, ils lanceront quand même ». Cet état d’esprit, cette stratégie consistant à s’adonner à l’impuissance, est précisément ce qui perpétue la faiblesse organisationnelle de QA. Parlez d’une prophétie autoréalisatrice ! 

Au-delà de ces considérations politiques ou psychologiques autodestructrices, cette stratégie repose sur une incompréhension fondamentale de ce qu’on attend de QA à cette réunion. En réalité, il n’est pas question d’exiger une décision irrévocable sur la livraison ou non, même si la décision qu’on vous demande de prendre publiquement semble formellement en avoir l’allure. 

Et oui, il faut tout de même rendre un verdict autoritaire. Mais pour cela, il faut comprendre la question à laquelle il s’agit véritablement et nécessairement de répondre.

La question à laquelle la direction de l’assurance qualité (QA) doit réellement répondre est la suivante : Quels sont les risques — leur probabilité d’occurrence et leur gravité sur le terrain — si la mise en production a lieu aujourd’hui ? Plutôt que, disons, le mois prochain ? En d’autres termes, on vous demande de fournir une évaluation des risques afin de permettre à la direction de prendre des risques de manière rationnelle à ce moment précis. 

Cela signifie que votre réponse définitive lors de la réunion « Go/No Go » est avant tout une réponse à propos du risque. Et non pas sur le fait d’appuyer ou non sur le bouton qui envoie une fusée dans l’espace.

Cela implique donc que l’histoire de la qualité que vous présentez lors de cette réunion doit être basée sur des scénarios. Autrement dit, elle ne se résumera pas à un simple oui ou non, peu importe à quel point les autres aimeraient cela afin de se décharger de toute responsabilité dans la décision (ce qui, en réalité, n’arrive jamais, n’est-ce pas ?). Pour schématiser, votre présentation devrait comporter deux parties :

• D’abord, un état des lieux autorisé, *vraiment* fondé sur les données, sur la qualité actuelle du produit. Avec des métriques précises à l’appui. Spoiler : Vous aurez besoin de plus que des métriques de bogues pour cela.
• Ensuite, une évaluation objective de la qualité potentielle qui serait laissée de côté si la décision est de livrer le produit maintenant. Est-elle suffisamment importante pour justifier d’ajouter du temps au calendrier de mise en production afin de « rembourser » cette dette qualité ? Si oui, quels sont les compromis temps/qualité recommandés par la QA ? Et quelles parties spécifiques des fonctionnalités du produit devraient être ciblées durant cette prolongation, et comment saura-t-on que la qualité potentielle a été atteinte ?

Cela n’est pas, en fait, une façon de contourner la question posée. C’est une façon d’y répondre dans le contexte complet de tous les paramètres, variables et coûts associés à cette décision — aujourd’hui, la semaine prochaine ou le mois suivant. 

Car — et voilà une vérité que vous devez ancrer dans votre conscience QA — votre véritable public lors de cette réunion n’est pas les autres responsables de service. C’est la haute direction. Qu’elle soit physiquement présente à la réunion ou non. Ce que vous direz leur sera communiqué sans tarder. Faites-moi confiance.

Et cela ne peut que jouer en votre faveur. Ce que les PDG et directeurs généraux apprécient par dessus tout, c’est de se voir présenter des options concrètes, appuyées par des faits et des données tangibles. Ce qu’ils détestent par dessus tout, c’est que l’on leur dise simplement : « Euh, nous ne sommes pas prêts à livrer. Et nous ne pouvons pas vraiment vous dire pourquoi. Mais nous pourrons peut-être vous le dire dans quatre mois. » C’est la raison pour laquelle les PDG partent à la chasse aux nouvelles acquisitions — afin de réunir une toute nouvelle équipe de livraison de produits. 

La plainte récurrente des équipes de livraison, c’est que la direction fixe arbitrairement, par décret, une date de mise en production à laquelle elle refuse de déroger. Vous pouvez vous demander pourquoi ils persistent à agir ainsi. 

C’est parce qu’ils n’obtiennent jamais de réponse claire sur l’état de la qualité du produit, ni sur la date à laquelle le produit pourra effectivement être livré si la date initiale n’est pas tenable. Ils s’en fixent donc une eux-mêmes. Parce que l’équipe produit ne leur a donné aucune alternative digne de ce nom.

Vous devez donc arriver à la réunion « Go/No Go » avec une histoire convaincante, complète, illustrée par des faits et des scénarios, menant à une série de recommandations crédibles, qui elles-mêmes peuvent intégrer des options pertinentes autour des compromis coûts/bénéfices liés à la qualité à propos du lancement — ou non. Marmonner quelques minutes sur des métriques de bogues, puis abandonner la décision aux autres, ce n’est pas ça, l’histoire à raconter.

Évidemment, pour pouvoir faire cela, votre méthodologie QA, votre formation et vos indicateurs de performance devront être irréprochables. J’ai rédigé des articles détaillés sur ces sujets ailleurs (par exemple sur LinkedIn), mais, étant d’ordre théorique, ils sont en dehors du cadre pragmatique de cet article.

Une Fin Heureuse

Ce que j’ai exposé ci-dessus peut sembler intimidant, et peut-être un peu contradictoire — en apparence. Je conclurai donc cet article par mon expérience d’une réunion « Go/No Go » qui fut un vrai succès. Qui s’est déroulée un peu différemment de ce que je viens de décrire, et aussi différemment de ce que j’attendais.

Mon équipe testait un tout nouveau produit. Non seulement nouveau, mais visant un marché dans lequel l’entreprise n’avait aucune expérience. C’était donc un marathon de dangers cachés, d’inconnues et de mauvaises surprises dès le départ.

Le moment de la réunion « Go/No Go » arriva. Dès le début de ma mission de directeur QA, j’avais instauré un cadre strict concernant la définition des métriques de qualité, avec notamment des métriques de couverture de tests fondées sur les exigences, et non sur tel module ou tel script de test. Nous disposions aussi non seulement de métriques de bogues, mais aussi de tendances de bogues, et de métriques sur la vélocité des changements de code, pour renforcer notre exposé. 

Et tous ces indicateurs étaient sans contestation positifs. Tous les feux étaient au vert. Pour une fois, nul besoin d’imaginer de scénarios conditionnels. Je n’ai vu aucune raison, exceptionnellement, de ne pas déclarer haut et fort : « On livre ! », sans réserve. 

Pourtant, techniquement, ce n’était pas mon rôle de le faire. Car le projet avait été mené par l’un de mes managers QA, et c’était donc à cette personne qu’il revenait de donner un verdict définitif. Ce manager a résumé les indicateurs avec justesse et a reconnu que tout était positif. 

Puis, à ma grande surprise, il a hésité à se prononcer sur la livraison ou non. Étonnement, car, bien sûr, nous avions discuté de la position de la QA avant la réunion. (Note importante : Ne surprenez jamais votre supérieur en réunion. Jamais.)

J’ai demandé au manager : « Que te faudrait-il pour être à l’aise de recommander de livrer ? Si ce n’est pas aujourd’hui, alors quand ? »

Encore une fois à ma grande surprise, le manager n’a pas pu — ou n’a pas voulu — répondre à ma question. Il m’est apparu clairement que ce manager ne voulait tout simplement pas assumer la responsabilité de prendre cette décision, de signer sur la ligne prévue. Ce que j’ai trouvé plus que décevant. 

C’était également une insulte pour le responsable de l’ingénierie sur le projet, qui avait été d’un soutien sans faille envers l’effort de QA et avait conçu un produit de première classe. Il ne méritait pas d’être pris au dépourvu de cette façon. Et moi non plus.

Alors j’ai pris la parole et j’ai dit : « Je n’ai vu, ni entendu, aucune bonne raison de ne pas lancer ce produit AUJOURD’HUI. Tel est le verdict de la QA, et moi, en tant que Directeur QA, j’assume pleinement la responsabilité de cette décision. »

J’ai cru que le responsable ingénierie allait m’embrasser. Mais après cette réunion, la QA a reçu un immense respect et une reconnaissance sans précédent de la part de l’ingénierie, de la gestion de projet et de la gestion produit. 

Parce que la clé pour être pris au sérieux dans notre domaine est d’assumer publiquement ses responsabilités. Ce que j’ai fait en toute confiance à ce moment-là, car notre récit avait été préparé depuis le tout début. Et il avait été écrit avec une fin heureuse en tête.

Le produit, une fois lancé, a démontré une excellente qualité sur le terrain, et a été un grand succès. Retarder sa sortie dans le seul but d’éviter la responsabilité de prendre la décision de livrer ou non n’aurait abouti qu’à une augmentation minime de la qualité du produit au prix d’un coût déraisonnable en argent et en temps de mise sur le marché. 

Comment nous avons réussi, c’est une histoire pour une autre fois.

Comme toujours, bonne chance dans vos efforts QA.

Podcast associé : TRAVAIL D’ÉQUIPE, IA ET CONTENANTISATION (AVEC MICHAEL RITCHSON DE LA NASA)