Le dernier déploiement du vendredi s’est bien déroulé : pas d’interruption de service ni d’incident, tout le monitoring technique est au vert. Pourtant le lundi matin, des plaintes clients sont remontées.

Le monitoring fonctionnel a été oublié dans notre Definition of Done. La culture de l’équipe n’avait pas encore ce réflexe dans ses intéractions, un filet de secours comme une checklist aurait été utile.

Une structure systématique peut nous aider à améliorer la qualité de nos processus de construction logiciel. Une technique issue du conseil pour des missions les plus variées est disponible : MECE.

Cet article partage la définition, la valeur et comment utiliser MECE dans un contexte de Quality Engineering. Une bonne lecture et à vos bloc-notes pour que la pratique renforce la compréhension du modèle.

Qu’est-ce que MECE?

MECE est l’acronyme anglais pour le principe « Mutually Exclusive and Collectively Exhaustive« . Son utilisation est associée à McKinsey dans les années 1960 (disclaimer: je ne possède pas d’action chez eux, j’aime la structure). Les deux éléments ME et CE doivent être présents.

Le concept MECE consiste à créer des “listes des listes” d’éléments à la fois sans collisions et exhaustifs au sein de leur liste. Il est recommandé d’avoir des éléments comparables entre eux, au nombre de 3 dans le cadre d’un argumentaire. Une fois créé, nous devons prendre du recul sur de possibles incohérences et erreurs.

MECE apporte plusieurs avantages. La clarté de la structure facilite des échanges plus intuitifs entre les parties prenantes. L’approche systématique de construction de liste limite également le risque d’oubli. Enfin, nous pouvons travailler plus efficacement en évitant le chevauchement de thématiques. 

Intéressant dans un contexte de conseil, quelle utilité de MECE dans un contexte de Quality Engineering ?

Pourquoi utiliser MECE pour le Quality Engineering?

Notre démarche de Quality Engineering consiste à injecter la qualité dans notre écosystème logiciel, de la culture aux opérations du produit. Nos activités peuvent sembler loin du conseil, néanmoins, la structure a de la valeur à d’autres égards.

Le monde du logiciel est plein de listes : besoins fonctionnels et non-fonctionnels, tests en white-box et black-box. Les besoins non-fonctionnels peuvent ensuite être déclinés dans une autre liste : reliability, maintainability, etc. Le monde du logiciel nécessite également une capacité de conduite du changement et d’influence, d’où l’importance de la logique.

L’argumentation est un art omniprésent dans l’histoire de l’humanité, qui a été largement diffusé par les Grecs. Avec le temps, plusieurs modèles sont apparus (oui,  encore des listes). Le raisonnement déductif ou inductif sont les plus courants, même si les modèles chronologiques, structurés ou comparatifs sont également possibles et peuvent être combinés. Leur force se révèle dans un argumentaire structuré.

Nous pouvons appliquer MECE sur la chaîne de valeur logicielle en commençant par le besoin.

Utiliser MECE pour cadrer le besoin

Le recueil de besoin est un exercice difficile où la balance de plusieurs pratiques doit être réussie. L’utilisation de liste MECE nous aide à structurer notre préparation, questionnement et l’expression du besoin.

Le besoin commence par répondre aux deux questions du “Pourquoi?” et du “Pour quoi”. C’est un processus où nous devons agir en tant que Question Asker dans un rôle de Quality Assistance comme évoqué dans cette table-ronde. Notre but est d’explorer le besoin afin de réduire le nombre de sujets oubliés, très coûteux en bout de chaîne.

Prenons le cas de la mise en place d’un nouveau service digital pour les clients. Au-delà du besoin fonctionnel, nous pouvons identifier les canaux concernés par la demande : le site, l’application mobile, les magasins? Les typologies de clients doivent également être validées; parle-t-on uniquement du modèle B2C ou d’autres? Cela peut sembler trivial, mais les projets ayant oublié un périmètre significatif du besoin sont fréquents.

Nous commençons à voir que MECE apporte de la valeur quand il est combiné à d’autres compétences. L’écoute active, l’ingénierie des exigences et la connaissance du domaine sont améliorées par la structuration apportée par MECE. La pratique et la préparation restent fondamentales; ce n’est pas en arrivant dans la réunion que la liste doit être initiée. Dans cet exemple, la conception technique nécessitant de balancer des besoins et des contraintes sera largement facilitée par une bonne structuration du besoin en amont.

Nous pouvons également améliorer un sujet plus que récurrent, la résolution des problèmes.

Utiliser MECE pour résoudre les problèmes

MECE a été créé pour supporter la résolution de problèmes complexes auxquels McKinsey devait faire face. Les fameux case bien structurés assurent une meilleure réflexion et une parallélisation possible des hypothèses à creuser. 

MECE est puissant quand combiné à d’autres techniques de gestion des problèmes. Un Issue Tree permet d’articuler nos hypothèses de causes sous-jacentes permettant une prise de recul, avant d’en faire un tri et une priorisation. Nous pouvons ensuite appliquer un 5 Why aux causes vérifiées, identifiant les causes racines. MECE est également connu pour son utilité dans le cadre du Six Sigma.

Imaginons un cas concret de Quality Engineering. Vous devez présenter une démarche permettant d’améliorer la stabilité des livraisons, celles-ci n’arrivant pas à suivre les cycles des sprints. La première étape sera de prendre du recul sur le système et d’identifier les hypothèses pouvant expliquer cette instabilité. L’étape suivante est de rapidement supprimer les options que nous pouvons déjà invalider, pour creuser les plus probables. Faire des listes nous aidera à prendre du recul et structurer notre approche. Nous pouvons également nous inspirer de la méthodologie de McKinsey.

La résolution de problème passe également par savoir convaincre, MECE est également utile à cet égard.

Utiliser MECE pour structurer notre argumentaire

Les meilleures idées, compétences et analyses disponibles restent sans valeur si elles restent incomprises des parties prenantes. Une bonne argumentation fait la différence en conduite du changement pour convaincre et influencer les équipes.

Barbara Minto, à l’origine du modèle MECE , propose sa mise en pratique dans la Pyramide de Minto. Celle-ci consiste à structurer le message principal autour d’arguments qui sont eux mêmes supportés par des données, issus de notre modèle MECE. Encore une fois, la valeur de MECE se retrouve dans sa combinaison avec les  techniques de logique.

Dans l’ouvrage décrivant les principes de cette pyramide, trois éléments fondateurs à la conduite du changement sont identifiés. Premièrement, l’analyse de la situation orientée par des faits, sans émotions. Enfin, l’identification des obstacles potentiels et leur propositions de remédiations. Ces trois ingrédients sont à inclure dans l’argumentaire de changement proposé.

Avoir plusieurs cordes à notre arc se révèle bien utile pour adresser les priorités du Quality Engineering.

MECE, une technique à transformer en compétence

Le modèle MECE est applicable sur toute la chaîne de valeur de la création de logiciel. Comme d’autres techniques, la compréhension et la pratique sont nécessaires pour en faire une réelle compétence de nos équipes.

Les profils cartésiens aiment les listes au risque d’en abuser, utilisant MECE à toutes les sauces. Il faut garder en tête la signification de l’acronyme en deux temps, “ME” et “CE”, pour rapidement valider si notre liste est réellement MECE. Pour certains cas, nous avons d’ailleurs juste besoin de structure ou de décrire clairement un processus.

MECE possède également des limites intéressantes à identifier. Par exemple, le trade-off de la structure peut nous faire oublier des éléments externes ou superflus, parfois importants à considérer. Le principe de ne pas avoir de recoupement entre les éléments peut également être contre-productif dans certains cas; nos systèmes sont pleins de causes et effets, comme expliqué dans cet article du Chaos Theory.

Récapitulons les apports de MECE dans le cadre du Quality Engineering : 

• MECE est un modèle permettant de structurer des éléments à la fois exhaustif et sans chevauchement
• Nous pouvons améliorer notre chaîne de valeur en utilisant MECE pour le cadrage de solution, la résolution de problèmes et la structuration d’argumentaires
• MECE est utile quand il supporte le bon objectif et combiné à d’autres techniques tels qu’un Issue Tree ou 5 Why
• Les apports de MECE peuvent être augmentés par des démarches collaboratives, agiles et de l’intelligence émotionnelle

Vous pouvez concrètement utiliser MECE pour les sujets suivants :

• Identifier et pratiquer MECE sur les processus et activités les plus pertinentes pour capter sa valeur, de préférence en collaboratif
• Partager le concept MECE sous forme de talks interne, diffuser et partager les listes créées sur un portail documentaire
• Utiliser MECE pour structurer votre argumentaire avec une  pyramide de Minto et les techniques de logique

Une démarche de Quality Engineering nécessite une argumentation initiale, une conduite du changement et une implémentation de solutions concrètes. Gardons donc comme priorité l’amélioration de nos structures de réflexion organisationnelles, en utilisant MECE à bon escient, quand pertinent.

Sur quelle sujet pouvez-vous pratiquer MECE dès à présent ?

Références

Wikipedia, MECE principle https://en.wikipedia.org/wiki/MECE_principle 

Anjana Gosain, Sangeeta Sabharwal, Rolly Gupta, Non Functional Requirement Classification for Service-Oriented Data Warehousing  http://www.ijsrp.org/research-paper-0713/ijsrp-p19111.pdf 

Barbara Minto, MECE – I invented it so I get to say how to pronounce it https://www.mckinsey.com/alumni/news-and-insights/global-news/alumni-news/barbara-minto-mece-i-invented-it-so-i-get-to-say-how-to-pronounce-it