05 – Consensus produit ou service

L’objectif d'une modélisation légère orientée "expérience utilisateur" impose l’obtention d’une base descriptive du futur produit ou service garantissant la compréhension globale de l’équipe de développement et son alignement avec les réels besoins applicatifs.

Un minimum de concepts et de vocabulaire

Le MVP (minimum viable product) est un produit ou service se limitant volontairement à un minimum permettant de valider l’hypothèse de développement (POC, prove of concept). Ensuite apparaît le MMF (minimum marketable feature) dont la mise en service doit générer une valeur (au minimum marketing). Découle de ces approches une structure de concepts, qui, selon la définition de SAFe la plus exhaustive, se présente ainsi : Theme (un objectif stratégique business), Epic (un container englobant les divers éléments du développement d’une solution, tels une justification économique et un MVP), Capability (une solution complète), Value stream (une chaîne de valeur autonome), Feature (un service livrable), User story (une fonctionnalité indépendante), etc. (Pour une vision d’ensemble se reporter à la figure : Experience - besoin mapping, laquelle ne représente qu’une possibilité adaptable liée à un environnement particulier.)

Note : Existent aussi les concepts de MMR (Minimum Marketable Release) et de MMP (Minimum Marketable Product). Néanmoins la complexité relative de cette décomposition n’est pas à mettre en oeuvre sans de bonnes raisons généralement liées à des formes sophistiquées de mise en marché.

Vision globale de la notion de Mapping

Depuis la découverte des deux premières méthodes Agiles (RAD 1991 et XP 1999), le développement de SI dispose de ses propres formes de modélisation. Ces expressions du besoin ont été imaginées simples, pragmatiques, mais surtout plus accessibles aux représentants des métiers et surtout aux utilisateurs finaux.

Le plus souvent la pensée « Design Thinking » (sujet de la cartouche de connaissance numérotée 04 communiquée précédemment) permettra de définir le problème et sa solution. Parfois même, un de ses sous-ensembles, la « Créative », suffira par son livrable à cerner suffisamment le sujet pour en permettre le développement (prototype). Lors de problématiques plus complexes ou plus lourdes, l’usage d’autres outils deviendra indispensable tant pour la détection et la formalisation de la situation actuelle que pour l’expression consensuelle et précise de la projection de sa résolution (le produit cible). Dans ce cas, mais toujours suite à une session de «DT», plusieurs formes de modélisation - généralement sous le format cartographie (map) - pourront alors matérialiser l’expérience utilisateur (contexte, besoin et solution). Par niveau d’abstraction, on trouvera (figure suivante) : la carte conceptuelle « Mind mapping » obtenue lors d’un « Brain storming », puis la carte « Impact mapping » impliquant une structuration plus opérationnelle et multicritère de la conception, puis, au final, la décomposition détaillée et priorisée du produit à développer, laquelle sera exprimée dans un « Story mapping ». Cette dernière représentation permet de co-construire et visualiser globalement les trois aspects de la modélisation classique (communication, traitement, données) sous une forme compréhensible pour le métier ou l’utilisateur.

Note : Cette cartouche de connaissance n’abordera simplement que des principes généraux limités à la vision d’un usage réduit au développement applicatif.

Mind mapping et carte conceptuelle

Parfois, lors d’un Story telling, lorsque les intervenants se trouvent dans l’incapacité de formuler précisément le problème et d’imaginer une solution novatrice déterminante, un Brain storming préalable au mapping est conseillé. Cette étape implique des techniques de formalisation des idées issues du Mind mapping comme par exemple une carte conceptuelle multicritère de la problématique. Sans considérer cette représentation comme indispensable ou spécifique à l’agilité – car relativement complexe à réaliser en atelier sans un coach averti - elle constitue un outil de réflexion intéressant à condition de se limiter à un emploi simple - sur un mur inscriptible ou permettant l’affichage de Post-it.

Impact mapping

Cet outil s’avère une aide à la compréhension et à l’innovation. Faisant généralement suite au Story telling - lors duquel les clients du produit ou service expriment la séquence de leurs besoins sous une forme narrative - l’Impact mapping précise le contexte global, les interventions des acteurs, les divers cas d’usage concernés et les grandes fonctions attendues. Cette représentation multi-axes se trouve à la base de l’UX design et offre d’avantage d’angles d’approches du problème et de ses solutions. Sont ainsi couverts les éléments significatifs concernant les données, les traitements, les communications, la planification, la priorisation. De façon plus générale se trouve ainsi matérialisée une « Spécification par l’exemple – Priorisation par la valeur ». Ainsi se facilite visuellement l'émergence de solutions réalistes et novatrices tout en développant un consensus transversal et une capacité d’apprentissage à partir de l’action professionnelle directe et du retour d’expérience. En résumé, il est obtenu une vision globale de l’expérience « utilisateur » avec ses interactions concrètes, ses canaux de communication privilégiés et les freins ou obstacles rencontrés (Customer Life cycle mapping).

Note : cette communication n’a pas pour but de présenter toutes les formes de mapping, de nombreux articles se trouvent sur le Net. Par contre elle fournira quelques conseils dans leur utilisation Agile.

Story mapping et MVP, MMF

Dans une étape plus « fonctionnelle » et détaillée, le Story mapping permet de préciser les fonctionnalités attendues et leurs priorités respectives. Le livrable visuel de cette étape se présente sous la forme d’un mur de post-it où l’ensemble du processus et des fonctions s’organise sur deux axes : temporel et de priorité. Cette représentation globale et aisément modifiable permet à de multiples participants de visualiser immédiatement l’ensemble de la co-reflexion en cours. Par contre, cette étape n’offre généralement pas d’indication de durée temporelle du scénario (problématique qui nécessite d’autres approches telles que l’amélioration continue ou la réingénierie des processus).

Pour obtenir une vision combinant une description des fonctionnalités, des flux et même une planification sommaire de la réalisation, il reste possible d’indiquer les interdépendances et de décrire certaines données. En ce qui concerne les dépendances, un simple bout de laine tiré entre les fonctionnalités sera suffisant (comme sur le Program Board de SAFe entre les « features »). Pour la description et l’organisation des données - dont l’importance est capitale dans un développement adaptatif - la forme la plus simple de visualisation demeure les cartes CRC (classe, responsabilité, collaborateurs). Un jeu permet ensuite de valider le modèle proposé en simulant des scénarios d'exécution. Les participants s’approprient alors les rôles des classes lors de l’utilisation virtuelle du produit. Rien d’ailleurs n’empêche de relier les US aux CRC - ce qui s’apparenterait à forme américaine de modélisation globale DFD (Data Flow Design). Ces derniers aspects qui peuvent dépasser la vision d’un simple utilisateur seront approfondis dans le cadre du prochain cartouche 06 - Conception simplifiée, Agile modeling techniques.

Note vitale : respectez un principe agile élémentaire : évitez le biais de la recherche de complétude lors de la spécification et reportez la formalisation des détails au cœur de la réalisation. Ces pratiques resteront toujours les impératifs essentiels du cœur de l’agilité réelle.

UX Design Lean Startup, Canevas, POC

La cartographie du parcours utilisateur (équivalent d’User Journey map en DT) représente une vue d’ensemble des actions et des interactions d’un utilisateur avec une application durant le processus d’utilisation. Comprendre le parcours de l’utilisateur (User flow) correspond à formaliser la notion « d’expérience client ». Cette approche de co-construction adopte toujours le point de vue de l’utilisateur réel et non celui de l’organisation qui développe l’application. S’il existe différentes manières de définir le parcours, l’objectif est toujours de s’approprier l’état d’esprit de l’utilisateur final du produit ou du service à chaque phase de son utilisation. Les différents intervenants peuvent ainsi :

Partager une vision claire des besoins et attentes
Améliorer les fonctionnalités existantes ou en proposer de nouvelles
Déterminer des opportunités d’innovation
Constater l’impact positif ou négatif d’une nouvelle fonctionnalité
Découvrir les obstacles auxquels se confronte l’utilisateur réel

L’ensemble des représentations venant d’être décrites génère aussi une vision économico-financière et organisationnelle (Lean Startup, Canevas) des changements envisagés par le développement de la solution, sa mise en œuvre et son exploitation. Parmi les autres outils désormais employés lors des développements actuels réussis se remarque également la « preuve de concept, POC » ou démonstration de faisabilité. « La POC est une réalisation expérimentale concrète et préliminaire, courte ou incomplète, illustrant une certaine méthode ou idée afin d'en démontrer la faisabilité. Située très en amont dans le processus de développement d'un produit ou d'un process nouveau, la preuve de concept représente une étape de plus en plus importante techniquement et économiquement sur la voie d'un produit pleinement fonctionnel. »

Conclusion pragmatique

Non seulement les diverses pratiques de « mapping » offrent naturellement une visibilité exceptionnelle, mais elles induisent pour tous la satisfaction d’avoir participé à la définition d’une vision partagée de la solution. De plus, le livrable de ce type d’atelier correspond exactement à la définition d’un « backlog » de produit selon la terminologie et la vision de Scrum ou de SAFe. La séquence d’action des acteurs représente alors un modèle de communication simple et clair à partir duquel les aspects organisationnels sous-jacents pourront être déduits.

Note : Un informaticien, même expérimenté et Agile, se trouverait certainement en difficulté s’il devait couvrir la totalité des techniques impliquées dans un « Continuous sprint 0 » car cette phase englobe l’ensemble des disciplines permettant de spécifier et modéliser globalement (au sens primitif du terme) l’espace du problème, de la solution et de son acceptation. (Le poster récapitulatif de cette proposition se trouvera ici : Continuous Sprint 0 ). La difficulté réelle de mise en œuvre de l’ensemble des cartouches de connaissances composant Sprint 0 ne se situe pas dans leur contenu mais dans la capacité des organisations à comprendre et mettre en œuvre la notion de « continuous » ; laquelle sera traitée dans la communication finale clôturant la présentation de cette approche, chaînon absent des méthodes agiles actuelles.

L’ensemble des concepts évoqués, ainsi que leurs représentations sous la forme de cartographies, trouvent une utilité certaine dans des contextes particuliers. Dans les cas les plus complexes, ces travaux serviront d’ailleurs de base à une modélisation plus formelle. Par contre et par principe, lors de leur mise en œuvre, limitez-vous à l’indispensable. Le plus souvent, un simple atelier de story mapping sera suffisant à une description exhaustive mais de haut niveau du produit à construire « product backlog ». La complexité du détail de la réalisation ne sera jamais à formaliser autrement que lors de la phase de Construction, dans le code, sa documentation, ses tests. Cette « spécification détaillée – codage – test - validation permanente » co-engageant simultanément métier et informaticiens, c’est cela l’Agilité, et rien d’autre !