J’ai longuement hésité sur le terme permettant de décrire une volonté de faire évoluer structurellement la qualité logicielle en transverse. Le Quality Engineering est loin d’être un seul sujet d’Engineering.
Mes expériences de transformation m’ont régulièrement frustré sur le manque de transversalité et de composition des équipes. La verticalisation de métiers de plus en plus complexes s’accélère, au détriment de silos peu perméables.
Les résultats de tels systèmes sont peu satisfaisants en création de valeur utilisateur que in fine, pour les organisations elles-mêmes. Les avantages concurrentiels sont éphémères par une compétition accélérée dans un environnement peu prévisible.
Dans ce contexte, les entreprises ont besoin de développer une capacité structurelle de survie : le Continuous Quality at Speed. La livraison de valeur en continu au high standard est le meilleur investissement à réaliser pour survivre.
Le Quality Engineering est le paradigme d’implémentation du Quality at Speed permettant l’atteinte de livraison continue de valeur. C’est le système que nous co-créons incrémentalement dans la QE Unit entre pairs, en transverse.
Cet article a pour but de clarifier la perspective systémique nécessaire à la mise en place du Quality Engineering. Le framework QEF (Quality Engineering Framework) en cours de définition s’articule autour de 5 piliers du MAMOS :
- Methods qui apportent la structure et la systématisation
- Architecture permettant de donner vie par l’Engineering
- Management pour animer, fédérer et piloter le QE
- Organization afin d’articuler les décisions et flux d’informations
- Skills pour permettre la composition d’expertises requises
Le Quality Engineering pose ses fondations sur l’organisation des activités.
Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.
Le Quality Engineering est structuré par les méthodes
Les meilleurs ingénieurs avec le plus beau code ne créent pas de valeur en étant désorganisés, focalisés sur les mauvaises priorités, en réinventant la roue à chaque problématique. La structure est essentielle.
Les méthodes sont fondamentales à identifier et travailler sur les bonnes problématiques de Quality. Le modèle des 5 Why en est un bon exemple, permettant d’utiliser efficacement son temps à la résolution des causes racines. Dans un flux projet, des activités de prototypages ou d’interviews utilisateurs focalisent également l’effort.
Le second objectif du Speed nécessite d’utiliser son temps sur les bons sujets de manière répétable et scalable. Cela permet de basculer d’une perte de temps à un investissement pour rester compétitif. C’est ce qui permet l’atteinte des fameuses economies of speed, et non des seules economies of scale, insuffisantes dans l’écosystème digital actuel.
Un écosystème digital qui a bien besoin de l’architecture de ses technologies.
Le Quality Engineering prend vie par l’architecture technologique
Le temps presse. Nous n’avons pas le temps de recréer une n-iéme librairie de logging ou de testing, et encore moins de l’opérer. La composition de technologies à valeur ajoutée tout en gardant de la flexibilité est la balance pour atteindre le Quality at Speed.
Aller vite en technologie requiert de faire des choix. On aligne nos principes de Make or Buy qui cascadera ensuite sur nos choix de développement et d’intégration. La valeur ajoutée du code est dans la création de la plateforme, de l’expérience utilisateurs et des processus métiers. Les couches de bas niveau et le recours à des solutions as a Service sont donc nécessaires.
Une contre-balance est néanmoins requise pour être rapide en continu. C’est ici la force de l’architecture dans l’atteinte du Quality et du Speed. Le découpage en plateformes, le découplage, les standards de interopérabilités sont autant de pièces nécessaires. Nous pouvons intégrer une solution à valeur rapidement en permettant sa composition à court-terme, tout en gardant une flexibilité d’évolution à moyen-terme.
Pour réussir, les acteurs au centre du système doivent collaborer efficacement au sein de modèles organisationnels.
Le Quality Engineering doit être porté, animé et piloté
Le rôle du management est d’impulser la vision du Quality Engineering dans l’organisation pour la décliner en animation opérationnelle. Son rôle est d’ailleurs celui d’un leader enabler plus que l’image du manager historique.
Les managers doivent fédérer les acteurs sur la mission de l’organisation pour ses utilisateurs. Leur valeur est dans le partage du sens commun, de la vision et de “faire prendre la mayonnaise”. Définir des objectifs clairs, composer avec des expertises et forces différentes, et fournir un cadre d’exécution performant est leur responsabilité.
Pour accélérer, les managers ne peuvent pas être un point de contention d’information, de décisions ou d’actions. Un véritable manager de Quality Engineering n’est pas seulement jugé sur ses compétences d’ingénierie. Il doit pouvoir anticiper et supprimer les points de blocage. Il doit savoir traiter les conflits organisationnels. Il est également le garant de la bonne utilisation des méthodologies en transverse.
Un réel manager est également un architecte de l’organisation.
Le Quality Engineering doit architecturer l’organisation
La structure d’une organisation cascade directement sur la performance de l’organisation. Le périmètre, budget et tenure des pôles influent sur la capacité d’atteinte du Quality at Speed en continu.
Produire du logiciel apporteur de Quality nécessite de réels investissements dans le temps. Un tel commitment permet de favoriser l’engagement des acteurs, leur focus et capacité de création de valeur aux besoins des clients. La contre force est que les ressources sont limitées. Des choix sont donc nécessaires pour mutualiser des ressources au détriment d’une qualité globale. C’est là toute la difficulté d’articulation d’une structure organisationnelle.
“La mesure de l’apport de valeur relie les outputs aux outcomes afin d’évaluer la performance des modèles organisationnels.”
Antoine Craske
Des investissements stables permettent à l’organisation d’atteindre la livraison de valeur logicielle en continu. Il devient possible de capitaliser sur les expertises sans les distraire par des réorganisations globales tous les ans. Ces fameuses “réorganisations” sont souvent décevantes quand elles n’adressent pas le fond du sujet : permettre la prise de décision en continu la plus rapide et au moindre coût. Les écosystèmes plus souples, adaptables et orientés plateformes sont les réponses d’équipes apporteuses de valeur globale en continu.
Ces modèles organisationnels prennent vie par l’activité de ses acteurs.
Le Quality Engineering requiert la composition d’expertises
Délivrer du logiciel á valeur ajoutée en continu requiert une collaboration transversale d’expertises de plus en plus verticalisées. Le Quality Engineering nécessite de réussir un assemblage de compétences entre les différents acteurs.
Nos méthodologies, architectures technologiques et modèles organisationnels définissent les expertises requises. La cartographie des compétences est la première étape permettant de définir l’étendu et les niveaux nécessaires. Bien souvent, il manquera des expertises de haut niveau pour les briques les plus différenciantes de notre plateforme. C’est là qu’il faut concentrer son effort et savoir aller vite.
Le recrutement interne, les plans de formations et d’évolutions annuels sont nécessaires mais pas suffisants. Pour aller vite, il faut avoir prévu des mécanismes rapidement actionnables. Un réseau de partenaires pour obtenir des ressources on-demand est un premier pas. Modulariser son architecture pour permettre des contributions isolées et rapides en est une autre. Les expertises sont rares, ponctuelles et resteront là où il y a de l’émulation.
Un écosystème attractif est porté par une vision, animé et en amélioration continue.
Le Quality Engineering est l’atteinte du Quality at Speed systémique
J’espère que cet article vous aura convaincu que le Quality Engineering n’est pas seulement faire du clean code, déployer des pipelines, et faire des tests. C’est une transformation du paradigme de livraison de logiciel.
Nous l’avons évoqué en introduction, la capacité délivrer en continu le Quality at Speed est nécessaire pour rester pertinent dans l’environnement actuel. Au sein de ressources contraintes, nous faisons face à un réel défi de survie.
Gardons en tête l’aspect systémique du Quality Engineering et son approche sur les piliers du MAMOS. Aligné sur notre pourquoi, le quoi et le comment sont en cours de définition plus précises avec la communauté.
Rejoignez la QE Unit pour contribuer à cette vision.