En tant que préparateur, je veux passer la commande en statut
en cours de préparationafin d'informer le client de l'avancement de sa commande.
Vous avez déjà vu cette User Story. Si ce n'est elle, c'est donc sa sœur. Nous nous imaginons souvent nos procédures métier comme une évolution linéaire, une succession d'états d'une ressource donnée qui tendent irrémédiablement vers un statut terminé. Tirer à droite ! ou Zero stock ! sont autant de gimmicks qui révèlent notre inlassable vision finaliste d'un processus de production en flux.
C'est pourquoi nous avons souvent dans nos modélisations, nos schémas, nos user stories, nos bases de données et nos APIs un petit champ nommé status, parce que l'anglais ça fait classe.
Et bien je vous le dis tout de bon, ce petit champ qui stocke le statut de votre ressource, il sent mauvais et augure bien des périls, en particulier si vous pouvez le modifier. Il peut être révélateur d'une perte de richesse fonctionnelle de notre solution ainsi que de défauts de cohérence ou de résilience de la conception technique. Bref : Les statuts, ça pue.
Lorsque l'on modélise nos processus, il arrive fréquemment qu'on tombe sur une modélisation dite d'automate fini. Ces modèles sont pratiques car faciles à visualiser et à décrire. Sans s'engager complètement dans leur formalisme, ils gardent un grand pouvoir explicatif. Par exemple, pour mon exemple de système de livraisons de commandes.
Ce diagramme indique le cycle de vie d'une commande dans un service de logistique une fois qu'elle est passée par un client. On y voit les temps d'attente entre les équipes qui préparent les commandes et celles qui les livrent. On y voit également quel état précède quel état, et donc quelles transitions sont légitimes.
Cependant j'y vois déjà 3 défauts :
Le premier point est le plus aisé à corriger, puisqu'il suffit de nommer nos transitions :
Voilà qui est un peu plus clair. Ce qui me gène encore, c'est que le statut en_attente traduit l'attente d'acteurs variés qui, selon mon métier, agissent tour à tour ou en parallèle. Démêlons ceci pour l'instant afin d'y voir plus clair :
Génial ! Rendre explicite quelles personnes peuvent résoudre une attente nous a permis d'identifier un travail distinct entre 2 processus en série. Ceci rendra le raisonnement plus simple. En sus, du vocabulaire plus spécifique est apparu avec des commandes qui identifient le traitement que ces états appellent.
Tentons maintenant de modéliser les cas d'échecs (seulement sur la seconde partie du processus).
Prévoir les cas d'erreurs possibles et la reprise sur échec d'un processus est souvent long et difficile… Je me suis arrêté en route pour me concentrer sur 2 éléments :
En se posant seulement les questions Quelle action résulte en cet état ?, Qui fait cette action ? et Quand fait on cette action ?, nous avons pu :
C'est justement sur ce dernier point que je voulais attirer votre attention.
Si la finalité du Système d'Informations que nous développons est de garantir la cohérence d'un processus 1, alors notre principal enjeu est d'implémenter correctement les transitions qui régissent ce processus. À l'inverse, fonder notre modélisation sur les étapes d'un processus risque de nous faire manquer des éléments fonctionnels cruciaux ainsi que des stratégies de priorisation par la valeur utiles.
C'est tout à fait évident dans l'exemple de user story que j'ai donné en introduction. En voici une version amendée pour coller à la modélisation que nous venons de faire.
En tant que préparateur, je veux commencer le picking d'une commande afin d'aller chercher les bons produits dans le stock
Ici on ne parle plus de statut, mais bien de la transition que l'on cherche à implémenter. En réalité, le statut de la commande, tel qu'affiché à un client ou tracé dans un journal, ne concerne que peu le préparateur. Il vaudra alors mieux rendre ces fonctionnalités explicites pour les utilisateurs qui en ont effectivement besoin et les réaliser en temps opportun.
En tant que client, je veux visualiser l'état de préparation de ma commande afin de me rassurer sur son avancement
En tant que contremaître, je veux lister les préparations de commandes réalisées par un préparateur afin de valider son quota quotidien
(Ah c'est sûr, rédiger correctement ses stories peut conduire à réaliser qu'on participe à la construction d'un outil d'oppression 😳)
La modélisation d'un processus ou du cycle de vie d'une ressource sous forme de diagramme d'automate est très utile et pertinente. Cependant, il convient de lire cette modélisation en se focalisant sur les arcs qui lient les états entre eux. En effet, quand ils interagissent avec notre système, nos utilisateurs expriment les transitions qu'ils veulent déclencher et non les états qu'ils veulent atteindre1. L'état courant d'une ressource peut en revanche leur permettre de décider quelle interaction ils décident d'avoir ensuite. C'est bien le nom des transitions qui apparaît dans la section « je veux … » de nos User Stories.
Ces diagrammes sont un bon support de discussion pour explorer et expliquer les règles fonctionnelles d'un logiciel. Pour aller plus loin, vous pouvez collaborer sur cette documentation à la façon des ADR évoqués dans cet article si vous vous basez comme moi sur le langage Dot pour les décrire.
Dans le prochain article nous nous intéresserons aux stratégies de découpage en User Story une fois que le cycle de vie de notre ressource est bien compris.
[1]: Nous parlons bien ici des logiciels qui sont garants d'un processus métier. Dans un prochain article, nous verrons qu'il y a des cas légitimes qui contredisent ce qui est énoncé ici, parce que sinon, c'est pas drôle 🙃.