Le Quality Engineering va t-il survivre aux différents challenges rencontrés en transverse dans l’organisation ?
C’est une bonne question pour une pratique émergente, à la croisée de plusieurs disciplines, entre le Business et l’IT.
Une introduction au Quality Engineering est disponible dans cet article.
Afin d’y répondre, j’ai retenu 9 défis auxquels le Quality Engineering doit faire face pour maintenir son apport de valeur dans l’écosystème.
#1 Adresser les (véritables) problématiques
Mettons nous en situation.
En bon Quality Engineer vous êtes connectés au système de réclamation client, pas uniquement au ticketing de l’IT.
Plusieurs clients se plaignent d’une expérience d’achat et post-achat dégradés remontant des problématiques transverses dans l’organisation.
Par où commencer? Quelles données analyser, corréler, mettre en avant? Quels problèmes semblent sous-jacents?
L’augmentation de la complexité des écosystèmes et organisations en rendent difficile sa navigation.
La gestion des problèmes est une pratique exigeante, d’autant plus si appliquée à la globalité de l’entreprise.
Identifier, se focaliser et résoudre les vrais sujets est un réel défi, exemplifié par les montants de projets ne délivrant pas la valeur espérée.
Les réponses ne sont pas dans les modalités d’exécutions, en plan pluri-annuel ou en sprints agile, en SOA, microservices, mais bien dans les sujets adressés.
La gestion des problèmes est une compétence organisationnelle que le Quality Engineering doit animer, pour identifier les vrais problèmes et améliorer la performance structurelle du système.
Contre-intuitivement, la résolution des problèmes a fondamentalement besoin d’interactions humaines.
#2 Développer un système organisationnel collaboratif
Même si aléatoires et peu prévisibles, la structure et organisation d’un système permet d’encadrer les comportements.
Indépendamment du modèle, le système doit créer une capacité de collaboration en dehors des silos organisationnels et hiérarchiques, supportant la résolution des problèmes.
L’organisation doit donc favoriser des échanges transverses quand ils sont nécessaires, tout en orchestrant des tâches manuelles, semi-automatiques et automatiques entre les acteurs.
Les missions, valeurs et autres mécanismes d’incentives doivent être revus pour s’aligner avec la cible et les évolutions d’organisations.
Les divers éléments du système doivent être considérés et abordés comme un projet de conduite du changement d’entreprise en tant que tel.
En complément, la mesure de la performance doit évoluer pour favoriser le développement du système.
#3 Animer une organisation Purpose-Driven et Value-Driven
L’énergie, la vision et la culture par lesquelles sont animés les collaborateurs est le carburant du changement.
Poser la question suivante est souvent riche d’enrichissements : “À quoi contribuez-vous ?”
Une réponse relatant les prochains tickets de développements en cours dénote un manque de partage d’une vision et culture commune.
Vous pouvez par contre entendre “Je participe à la construction de notre plateforme de demain au service de nos clients”.
La vision partagée et animant les collaborateurs est l’une des caractéristiques clés d’une organisation Purpose-Driven.
À ce sujet, je vous recommande personnellement le livre Man’s Search for Meaning.
Des avantages notables se dégagent telles qu’une meilleure prise d’initiative, motivation au travail et collaboration au service de la performance d’entreprise.
Les avantages d’une organisation Value-Driven sont explicites dans sa définition.
A team is value-driven when the team members value working together; they are constantly improving themselves, their team, their environment, and their tools; and they strive to live an appropriate set of Values.
La culture et le sens partagé sont un réel défi pour le Quality Engineering souhaitant animer une dynamique transversale orientée client.
#4 Gérer la connaissance organisationnelle
Collecter, maintenir et diffuser de la connaissance est un enjeu pour les organisations,
Comme pour les clients, le “Anywhere, Anytime” s’applique également à l’accès à l’information.
La complexification des organisations ne simplifie pas la tâche au Quality Engineering, qui doit souvent naviguer entre des sources différentes et peu intégrables.
Avec un peu de chance, l’entreprise aura capitalisé sur un portail documentaire pour un minimum de documentation produit.
La problématique de la connaissance est plus large, englobant tant celle fonctionnelle que technique.
Les parties prenantes veulent également des formats utilisables, ajoutant une problématique de visualisation.
Pour complexifier la tâche, la connaissance est de plus en plus dynamique.
#5 Développer l’Analytics et l’Observability
Les processus sont vivants, évoluent et doivent être observés en mouvement.
Le domaine de l’Analytics consiste à créer de la valeur par l’analyse des données, rapports et et autres métriques.
Elle supporte une prise de décision de meilleure qualité, sur base d’historique et de plus en plus, de prévisions.
L’Observability se focalise sur la perception de l’état d’un système par l’analyse de ses attributs et données accessibles extérieurement.
Concrètement, savez-vous observer en temps réel vos différentes expériences clients digitales ?
La complexité des usages, organisations et technologies résulte le plus souvent en une vision partielle des processus.
L’émergence du Process Mining, des architectures en Data Mesh et les standards de métriques, événements viennent nous aider.
En attendant, l’Analytics et l’Observability restent de vrais défis pour le Quality Engineering, qui devra souvent croiser plusieurs rapports.
#6 Déployer l’automatisation
Au-delà du défi technologique, l’automatisation présente de réels sujets d’adoption et d’état d’esprit.
On pourrait se demander : “Pourquoi ne pas tout automatiser ?”
L’équilibre, pertinence et bon sens sont à considérer.
Des tâches peuvent être temporaires et instables rendant leur automatisation inutile.
Certains processus peuvent nécessiter des adaptations régulières avant d’être robustes. En plus d’un coût de rework élevé, le délai de feedback loop et donc d’amélioration s’en trouve ralenti.
Gardons en tête la citation Bill Gates mentionnant l’inefficacité à l’échelle de l’automatisation d’un mauvais processus.
Pour d’autres tâches, automatiser n’est simplement pas encore possible.
Je vous passe les défis inhérents à l’automatisation comme la formation, la mise en place technologique de RPA, trouver les profils nécessaires, etc.
Le Quality Engineering doit permettre une adoption raisonnée et apporteuse de valeur de l’automatisation, au service de l’entreprise.
#7 Accélérer la livraison logicielle sous contraintes
Un développeur doit pouvoir livrer une ligne de code utilisable par le client en quelques minutes.
Tout cela en assurant une disponibilité 24/7, multi-pays, sur les divers smartphones et dispositifs, sécurité, évolutivité, …
C’est avec ces contraintes qu’existe la complexe balance d’accélération et de maîtrise de la qualité des logiciels.
Les processus révèlent souvent leurs limites quand poussés dans leurs extrêmes, une situation de plus en plus courante dans les entreprises.
Le Quality Engineering doit donc réussir à être au service des parties prenantes du développement pour leur faciliter la vie.
Fournir une réelle plateforme de développement permettant de livrer, valider et réagir rapidement émergé dans les concepts de Developer Platform, DevEx, Engineering Productivity.
Même si le No-Code ou le Low-Code a le vent en poupe, il ne viendra pas résoudre tous nos problèmes, l’expérience de développement, ou DevEx, reste un sujet majeur.
#8 Maintenir une DevEx cohérente entre les environnements
Pour répondre à nos différentes contraintes, les architectures distribuées et environnements de tests ont émergé.
Nous avons par contre créé d’autres problématiques : la cohérence des divers environnements entre eux.
Le Test Environment Management (TEM) et le Test Data Management (TDM) sont des sujets trop souvent sous-estimés.
Les use-cases ont été détaillés, pourquoi se soucier de l’environnement et des jeux de données ?
Pour garantir l’apport de valeur des équipes.
Même avec le meilleur IDE et Cloud à la mode, un développeur sera peu productif s’il perd 4 heures à tenter d’intégrer son développement, à chaque changement.
L’intégration et la cohérence des environnements est un sujet principal pour un Quality Engineering permettant de décupler la performance des équipes.
#9 Adopter progressivement l’IA
Terminons avec notre dernière balle, la fameuse Intelligence Artificielle (IA).
Difficile de cerner les projets qui ont été jusqu’en production à l’échelle avec tant d’engouement pour le sujet.
Son but est d’automatiser des matrices de décisions complexes et réactives, à l’échelle.
Mettre en place de réels processus d’IA est une forme avancée d’automatisation, plus complexe organisationnellement, technologiquement, mais aussi humainement.
On aimerait avoir une IA de Quality Engineering effectuant les meilleures recommandations et ajustements aux développements.
Nous en sommes encore bien loin par l’immaturité de l’IA sur les processus de développement et les défis d’opérationnalisation.
Gardons néanmoins espoir et comme pour l’Observability, focalisons nous sur un perímètre plus restreint et défini, avec les données suffisantes.
Quelle probabilité de survie pour le Quality Engineering ?
La survie des entreprises dépendra en grande partie de leur capacité à créer des systèmes organisationnels performants, au-delà des changements technologiques.
C’est pourquoi je crois à un Quality Engineering d’entreprise, transverse et apporteur de valeur sur l’ensemble des processus et expériences clients.
Les défis identifiés restent valides, en avoir connaissance est la première étape pour adapter son approche.
Une capacité d’adaptation, qui, comme pour les humains, améliore nos chances de survie.
Références
https://www.accenture.com/us-en/insights/technology/quality-engineering-new
https://www.forbes.com/sites/hayleyleibson/2018/01/25/the-power-of-purpose-driven/?sh=238ae8215dca