#4 - DDD Stratégique : Modéliser les parcours clients

L'article 3 nous a permis de commencer à nous familiariser avec le domaine, en définissant les acteurs, et leurs besoins. L'étape suivante pourrait être de voir comment leur besoins prennent forme, à l'heure actuelle. Rentrer dans le détail d'un processus permet de mettre à nu le dit processus, et donc d'en comprendre tous les rouages. Et ça c'est top pour notre compréhension de ce qui se passe avant que l'on commence à intervenir, en sommes comment est organisé le fameux problème.

Détailler les processus

Pour rentrer dans ce niveau de détail, il nous faut échanger. Echanger cette fois ci de manière un peu plus organisée, au travers d'atelier de définition. Il existe énormément de façons d'organiser un échange pour modéliser un processus, des plus ou moins bonnes. Il y en a surtout une mauvaise.

La mauvaise c'est le cahier des charges.

Un bon gros cahier des charges de 200 pages, qui décrit en détail la couleur de fond du bouton de l'écran 12, mais qui ne donne aucune compréhension étendue du domaine, et surtout un cahier des charges c'est focalisé vers la solution, pas sur le problème. Le truc est donc aussi utile à un dev qu'un  soutient-gorge à une enclume.

Bref depuis quelques années et l'apparition du design thinking, on voit apparaître des modes d'échange et d'idéation basé sur des ateliers collaboratifs. Alors certes tout dans le design thinking n'est pas a garder, mais certaines méthodes sont redoutablement efficace pour transmettre une vision. Les trois techniques d'échanges les plus à la mode à l'heure actuelle sont listées ci-dessous. En revanche j'avoue humblement ne pas être un expert de l'event storming, ou du domain story telling. Du story mapping, un peu plus déjà.

Le story mapping
Cette technique fait un peu figure de doyenne, et existe depuis 2014 (c'est quand même incroyablement récent...). Le bouquin de référence est celui de Jeff Patton, dispo en français. La méthode a été présenté de manière parfaite par Alexandre Boutin dans une conf dédiée en 2015. Personnellement, et jusqu'à présent, c'est ma technique préférée pour discuter du besoin avec un client ou un expert du domaine. Je la trouve naturelle et très souple. Bien que cette souplesse puisse conduire a des ateliers improductifs si on se concentre sur la technique davantage que sur les problèmes, ou les parcours de l'utilisateur. Le story mapping, c'est vraiement comme un story-board de production vidéo, on découpe les processus par étapes, tant qu'on ne comprend pas exactement ce qu'il y a dans une étape, et une fois que c'est clair on passe à la suite. Cette souplesse en fait un moyen idéal d'échange et de modélisation des processus, dans l'espace du problème pour comprendre le fonctionnement actuel, ou dans l'espace de solution pour imaginer comment va fonctionner notre plate-forme demain.

L'event Storming
Inventé récemment par Alebrto Brandolini, internet regorge de ressources sur le sujet, je vous laisse faire vos propres recherches. De mon point de vue cette méthode est intéressante, mais je trouve l'approche trop technique, et pour certains profils qui ne seraient pas à mon avis capable du niveau d'abstraction nécéssaire. Bref pour moi, cela n'est pas assez orienté client, et trop orienté sur le besoin des devs.

Le domain story Telling
Le petit nouveau des techniques d'interview. Je trouve ça hyper intéressant mais un peu verbeux, et peu lent. et de ce que j'ai pu voir la technique révèle son plein potentiel à une échelle un peu en dessous de la stratégie. Plus efficace donc pour modéliser le détail d'un scénario d'usage, qu'un ensemble de parcours client. A utiliser dans un second temps, pour moi.

Bref tout ça n'est que mon avis évidemment, et se discute totalement. Pour avancer, j'ai donc organisé un story mapping, dont voici le résultat.

Disclaimer: comme tout le reste, un story mapping est valide à un instant T, et devrait donc évoluer avec le temps. Avec le temps la solution s'affine, ouvre d'autre perspectives, le contexte du projet évolue... bref, s'adapter au contexte est un peu obligatoire, mais le story mapping nous donne déjà des infos sur la direction dans laquelle partir.

Le pitch de l'atelier

Cadrer un atelier d'échange est hyper important. L'introduction que j'utilise est généralement "Nous allons décrire ensemble les étape que vous franchissez aujourd'hui pour faire votre métier" Cela permet aux expert de nous livrer la nature des tâches que nos intervenant réalisent, sans se focaliser sur les outils qui sont en jeu. C'est le but du jeu : comprendre ce qu'ils font, et pourquoi ils le font. Surtout pas comment. Si on tombe dans le comment on risque de se focaliser sur la solution que l'on imagine, et nous n'en sommes pas encore là.

Le story mapping par acteur

En partant des besoins primaires listés à l'étape 3, nous avons construit les User Map ci dessous :

Le Coach :

Nous avons donc au passage ajouté quelques besoin qui n'étaient pas listés dans l'article 3.

Le Commissaire de ligue

Evidemment cette partie est beaucoup plus fournie. Le commissaire de ligue est notre cible principale, c'est à lui que nous allons rendre service au final, et c'est lui qui est en charge de davantage de tâches.

Je pense pas qu'il soit nécéssaire de présenter en détail le contenu des cartes, en toute logique elles sont suffisamment parlantes, que ça soit pour la partie coach ou pour la partie commissaire de ligue.

Maintenant que nous avons identifié une première version des parcours client, l'étape suivante va être de regrouper ces parcours, sémantiquement parlant en domaine cohérents. Nous aurons ensuite davantage de facilité à proposer une solution, elle aussi découpée en contextes. Nous approcheront ainsi la définition de nos contextes d'utilisations, ou bounded contexts.

C'est objectif de l'article #5: Définir les domaines et sous-domaines