La qualité n'est pas une valeur en soi

Il y a quelque temps je trouvais que la qualité était bien. Tout simplement bien, bien pour tout le monde et dans la plupart de contextes. Je ne le pense plus! Enfin j'ai nuancé un peu mon approche à la qualité. Et même je commence à être un peu agacé quand j'entends mes collègues dire qu'il faut faire plus de qualité (point), qu'on nous laisse pas le temps de faire assez de qualité. Ou bien quand on me demande si je pense qu'il faut du 100% de couverture de test ou s'il faut s'arrêter à X%.

Ce genre de dialogue est aussi vide de sens qu'on l'entend très souvent! Aujourd'hui je réponds toujours avec des questions, quelque soit mon interlocuteur, "Que cherches tu à obtenir? Pourquoi?" afin d'engager un dialogue qui mettra en lumière des problèmes ou des risques sous-jacents au sentiment de nécessité d'améliorer la qualité.

L'autre jour un ami développeur se plaignait que son manager et son commercial se fichait de la qualité. Ok pour le commercial mais au moins son manager avait été développeur il devrait savoir ce que la non qualité emmène comme problème et coût! Mais de toutes façons leurs clients allaient jamais pouvoir être persuadés d'acheter la qualité. Et alors? C'est souvent comme ça et c'est à peu près normal!

Qui est-ce qui peut le mieux expliquer et comprendre les bienfaits de la qualité? Et bien c'est mon ami (plus largement personnel technique). Lui seul les comprend bien et est donc le mieux placé pour expliquer avec précision ces bienfaits, ou plus précisément de décliner une approche qualité en avantage concurrentiel, opportunité de marché ou assurance. Ok facile, il n'a qu'à dire : "En misant sur la qualité on aura pas de problèmes et on ira plus vite, aura moins de bugs etc". Sauf que ça ne convaincra personne, tout le monde l'a déjà entendu et les personnes qui restent ont besoin de preuves plus concrètes, plus contextualisées.

Echec de convaincre, indicateur de maitrise à parfaire
Si on ne peut être plus précis c'est un signe qu'on n'a pas soi-même bien compris comment cela fonctionne ou quelle est la nature de comment cela va nous aider. Rien de pire pour démarrer un changement - de connaitre le moyen mais pas ce qu'on cherche à obtenir. Par contre on peut très bien se donner du temps à explorer une technique afin de mieux cibler comment il peut nous aider dans notre contexte. Nous sommes en perpétuel apprentissage sur les méthodes que nous utilisons, ainsi que le contexte dans lequel nos interlocuteurs se trouvent. Prenons l'opportunité que présentent ces échecs de "vente" comme indicateurs de ce que nous avons besoin de creuser.

D'un autre côté il n'y nul besoin d'apporter toute la solution soi-même. Il n'y a rien de plus naturel que d'explorer une idée avec son manager / commercial / marketeur. "J'ai lu ceci et experimenté telle et telle approche, c'est sensé quasiment supprimer les erreurs de spec. Imaginons que nous ayons ça, qu'est-ce que ça nous permettrait de faire?"

Le contexte est roi
Il faut aussi se rappeler que la meilleur chose qu'on doit espérer découle de la situation. Si notre client ne peut pas déployer l'application plus souvent que tous les 6 mois alors nous ne pouvons pas espérer l'intéresser avec la possibilité de livrer tous les jours (en terme de couverture de non-regression). Si notre client est un startup nous ne pouvons pas espérer l'intéresser avec une approche ZéroBugs. Il faut plutôt chercher ce qui peut être décliné en avantage clair et alléchant pour lui, le reste ne fera que polluer le dialogue et créer de la frustration. C'est dans cette déclinaison contextuelle que nous apportons une très grande valeur avec notre compétence technique.

Petite décharge, je ne dis pas qu'il faut appliquer partiellement le TDD, le BDD, Scrum, devops ... Non ce serait une erreur au début (n'oublions pas Shu-Ha-Ri). Ce que je dis est de chercher un pourquoi de plus en plus précis.

Condamnés à vendre?
Alors nous (personnel technique) sommes condamnés à vendre en permanence? Le métier qu'on voulait pas faire! Certain d'entre nous trouve même que le métier de commercial est malhonnête. Certes il y a des commerciaux malhonnêtes mais ça ne veut pas dire que la vente est malhonnête. Même nous passons beaucoup de temps dans la vie à vendre nos idées, si nous ne le faisions pas nous serions frustrés et même ce serait de priver notre entourage de notre contribution à l'intelligence collective! Vendre ses idées est sensiblement la même chose que de vendre, commercialement, une nouvelle solution.

Alors nous sommes pas commerciaux et nous n'aimons peut-être pas ça, mais nous avons un choix entre

1. Continuer à ne pas vendre (ou du moins à mal vendre) nos idées et d'en assumer la frustration
2. Ou à s'efforcer à comprendre les enjeux de nos interlocuteurs et ainsi exploiter notre compétence technique au mieux pour le bien de notre entourage.

Conclusion
La qualité ne se discute pas en quantité. Il n'est pas intéressant de discuter de quelle technique est la meilleure pour atteindre une bonne qualité avant d'avoir identifié les problèmes et opportunités. Il est beaucoup plus probable que tout le monde trouve un terrain d'entente si on adresse d'abord le pourquoi. Sans oublier que le pourquoi peut simplement être de mieux connaitre une méthode afin de savoir s'il est pertinent dans notre contexte.

Personnellement je ne dis plus "La qualité est bien/sacré". J'essaye de

• Décliner les techniques de qualité en avantage/assurance tangible pour la personne en face. Notamment en cherchant les problèmes actuels.
• Apprendre des éléments de vente et de comment convaincre (il ne s'agit pas de de meilleurs arguments)
• Ne plus faire du zèle par rapport au contexte. Parfois il vaut mieux tenter de changer le contexte.
• Utiliser mes échecs comme indicateur sur ce que je dois approfondir en techniques de qualité ou en compréhension de contexte.

C'est beaucoup plus dur, mais beaucoup plus intéressant et satisfaisant.

Et vous qu'est-ce que ces mots vous inspire? Merci d'avance pour vos retours.