« Il faut faire un microservice dans le Cloud avec un service mesh ». Une autre journée, un autre choix technologique. Mais quand vous demandez « Pourquoi ? Pour faire quoi? » et n’obtenez qu’une réponse désordonnée, il vaut mieux arrêter l’initiative.

J’ai eu cette tendance à l’orientation technologique de mon background d’engineering. Nous aimons résoudre des problèmes complexes grâce à la conception, la créativité et trouver des solutions élégantes. Le fait est que le problème doit être à valeur ajoutée pour être résolu en premier lieu.

Le pourquoi et le quoi sont des éléments essentiels de toute initiative logicielle. Les précipitations dues à l’impatience, à la pression de livrer et à la culture organisationnelle peuvent créer des raccourcis dangereux, confondant le fait d’être occupé avec lui de générer de la valeur.

Cet article partage les éléments clés d’une méthodologie structurée que vous pouvez appliquer à toute initiative logicielle. Le livrable que vous allez produire doit être compréhensible par l’ensemble de l’équipe, y compris pour les parties prenantes de l’entreprise :

• Un comment n’a pas de sens en soi
• Un comment doit commencer par le Pourquoi
• Un comment cascade du Pourquoi et du Quoi
• Un comment est l’une des solutions possibles
• Un Comment de valeur exige des Méthodes

Commençons par clarifier pourquoi il n’y a pas de temps pour des initiatives peu claires.

Un Comment n’a pas de sens en soi

Certaines personnes diront que des initiatives technologiques sans raison métier claire sont toujours bénéfiques : « Il est préférable d’avoir un logiciel au niveau plutôt qu’un dépassé. » En comparaison, utiliseriez-vous votre salaire juste pour améliorer votre voiture un peu dépassée ?

La mise en œuvre demande du temps, de l’énergie et de l’argent. Il n’y a pas de temps à perdre dans un monde numérique de concurrence accélérée et de ressources limitées. Les initiatives peu claires ne tiennent pas compte de l’importance du coût d’opportunité : la perte d’autres alternatives lorsqu’une alternative est choisie.

Le coût d’opportunité – la perte d’autres alternatives lorsqu’une alternative est choisie – nécessite de prioriser ses efforts en Quality Engineering.

Antoine Craske

Les entreprises ont besoin d’économies d’échelle et de rapidité pour survivre. Les choses changent vite. Un actif logiciel de valeur aujourd’hui peut être complètement remplacé lorsqu’une entreprise pivote. C’est pourquoi les initiatives cloisonnées qui manquent de clarté sont très probablement du gaspillage.

Le Quality Engineering n’a pas de place pour le waste, seulement pour la valeur.

Un comment doit commencer par le Pourquoi

Le pourquoi est essentiel à toute activité. Simon Senek a rendu populaire l’expression Start With Why dans son livre à succès. On le retrouve aussi dans divers points des 7 Habitudes des Personnes Très Efficaces par Stephen R. Covey, atteignant également des millions dans ses conseils de vie et de comportement.

Le Pourquoi nous donne un sens, un but et des objectifs durables. Le Pourquoi pousse notre action en cascade sur le Quoi, le Comment, et même sur le Qui. Le Pourquoi matérialise la valeur de nos actions. A travers l’histoire, un pourquoi a permis aux gens de traverser des périodes dramatiques comme dans Man’s search for meaning de Viktor Frankl.

Un pourquoi convaincant est un catalyseur étendu collaboration. Les gens ont pu construire des cathédrales et d’autres monuments durables en croyant à la vision globale, à la mission et au pourquoi. Les organisations ont besoin d’un pourquoi moteur, animé par ses managers, pour maintenir un alignement des valeurs lors de la mise en œuvre.

En Quality Engineering, le Pourquoi est la raison d’être pour continuellement délivrer l’écart de valeur à nos utilisateurs. Nous créons de la valeur en aidant nos utilisateurs à résoudre leurs problèmes avec succès. Un logiciel, aussi bon soit-il techniquement, n’a pas de sens s’il n’a pas de valeur pour quelqu’un qui compte. 

Toutes ces raisons d’avoir un pourquoi clair avant de passer au quoi.

Un Comment découle du Pourquoi et du Quoi

Un périmètre structuré est essentiel à une mise en œuvre efficace. Il n’y a pas de temps à perdre sur le Comment jusqu’à ce qu’il soit défini. Cela conduirait probablement à des implémentations partiellement apporteuses de valeur, complexes et longues, pleines de rework inutiles.

Le quoi découle du pourquoi. Cela peut être une expérience pour évaluer la valeur potentielle d’une fonctionnalité pour nos utilisateurs. Cela peut être un ajout à une fonctionnalité déjà réussie. Il peut s’agir d’un correctif détecté à partir d’un rapport d’incident ou de sécurité. Quoi qu’il en soit, cela doit être clairement identifié.

Délimiter le périmètre d’un changement de logiciel est vital. Cela oblige à être plus concret sur les cas d’utilisation et ses fonctionnalités. Cela commence à soulever des éléments hors périmètre et des exigences non fonctionnelles telles que la couverture, la performance ou la sécurité.

Un périmètre clairement défini est également indispensable à la collaboration des expertises. Les product owner et les ingénieurs doivent être alignés sur ce qu’ils essaient d’accomplir. À partir de ce moment-là, ils peuvent même hiérarchiser les incréments à délivrer.

Ce n’est qu’alors qu’ils peuvent travailler sur les différentes implémentations possibles.

Un comment est l’une des solutions possibles

Il n’y a pas de comment unique. Différentes solutions existent au même problème. Ces différences sont à l’origine des compromis associés. C’est pourquoi un seul Comment ne suffit pas, une solution sans inconvénients ne suffit pas et le contexte est clé pour décider.

Identifier plusieurs possibilités permet de mieux choisir. Un seul Comment est dangereux par manque de recul sur le problème à résoudre et par les compromis impliqués. Vous pouvez manger dans une pizzeria, un restaurant Michelin ou un fast food, chacun répondant au besoin de s’alimenter. L’expérience globale est différente en termes de prix, de durée et de nutrition. Une fois que vous avez plusieurs options, vous devez en choisir une. C’est l’importance des trade-offs.

Les compromis aident à articuler les avantages et les inconvénients associés à une option particulière. Ils sont nécessaires pour surmonter les biais spécifiques de la prise de décision comme celui de confirmation ou de récence. Ils aident également à factualiser les options qui facilitent la collaboration. Les compromis ne doivent pas être mélangés avec la prise de décision. Toutes les options ont des compromis. Une solution proposée sans inconvénients doit être remise en cause pour les identifier. Mais décider s’ils sont bons ou mauvais dépend du contexte.

Le contexte guide notre prise de décision en privilégiant certains critères par rapport à d’autres. Le contexte contient le Pourquoi et les évolutions possibles de l’organisation, deux éléments essentiels à la prise de décision. Acheter une maison n’est pas toujours la solution. Vous pouvez acheter différentes maisons si vous êtes célibataire, en couple ou en famille. Vous pouvez acheter, louer ou même louer avec une option d’achat.

Le pouvoir de la structure est le résultat de ce processus.

Un Comment à valeur requiert des Méthodes

Le Pourquoi sécurise le besoin réel de travailler sur l’initiative. Le Quoi défini quoi faire, dans quel ordre et sous quel cadre. Le Comment donne le pouvoir de choisir pour articuler la trajectoire la plus pertinente dans le système.

Un processus structuré est le fondement de la performance organisationnelle. Une approche systématique permet un rendement accru et une meilleure évolutivité. Le découplage des phases étape par étape accélère le résultat, réduit la complexité et évite les reworks  inutiles.

Le Quality Engineering est la livraison continue de logiciel à valeur ajoutée à nos utilisateurs. C’est la réalisation de Quality at Speed ​​dans un écosystème en constante évolution. Il n’y a pas d’énergie, de temps et d’argent à perdre dans des initiatives peu claires.

Le framework du Quality Engineering, MAMOS, commence par les Méthodes. C’est le moyen de mettre en œuvre des processus structurés de qualité totale, allégés et à valeur pour la livraison de logiciels.

Alors, quand ça commence avec un Comment, arrêtez maintenant.