Avant, je commençais toujours par réfléchir aux données à utiliser dans mon code.
Quelles vont être les structures de données ? Comment les organiser dans ma base de données ?
Je décrivais les données en utilisant des noms communs : une commande, une affaire, un prix, une période, un produit.
Et je dessinais dès le début des schémas relationnels pour décrire les données (c'était parfois l'un des premiers livrables demandés par mes clients).
Et bien c'est une erreur de commencer comme ça.
Pourquoi ?
Parce que les données comptent moins que les actions. Les substantifs comptent moins que les verbes.
Vous sous-estimez probablement l'impact du vocabulaire et de la formulation
Pour votre entreprise, ce n'est pas important de savoir stocker des commandes. Ce qui compte, c'est qu'un utilisateur puisse commander vos produits.
Ce n'est pas important de mémoriser un planning. Ce qui compte, c'est qu'un utilisateur puisse planifier une tâche.
Vous pensez que c'est un détail ? Que ce sont les mêmes idées formulées différemment ?
Pas du tout.
En décrivant les fonctionnalités sous la forme d'actions réalisées par les utilisateurs, le développeur va comprendre la dynamique de ce qu'il code. La valeur ajoutée du logiciel sera plus importante, le code sera mieux organisé.
Parce que si l'on veut juste stocker des données, il suffit d'utiliser Excel. Excel, c'est le règne des noms de colonnes.
Dans Excel on ajoute une ligne dans l'onglet "liste des commandes". Alors que dans la vraie vie, on veut que "le client passe une commande".
Quand le client passe une commande, on va décrémenter le stock, aller chercher l'article dans l'entrepôt et l'expédier au client. L'objet "commande" ça n'est qu'un bout de papier ou d'octets sur un disque dur. C'est un détail qui permettra de se souvenir que ça c'est passé.
On appelle ça un enregistrement dans un système qualité. Il est secondaire par rapport au processus.
Lorsqu'on conçoit un logiciel, j'observe souvent que l'on se focalise trop sur l'enregistrement au détriment du processus.
La transformation numérique fictive.
Dans certaines entreprises, les utilisateurs ont des dizaines de fichiers Excel.
On se dit, c'est bien, dans ma boîte tout est informatisé. Zéro papier. On a réussi la transformation numérique de l'entreprise.
Sauf qu'on n'a rien transformé du tout. La procédure est sur un post-it !
Tout ce qu'on a fait, c'est de mettre des données dans Excel au lieu de les mettre dans un cahier.
Pour aller plus loin, il faut coder le processus écrit sur le post-it.
Bien formuler les users stories
Quand on veut décrire un processus, il faut un verbe. Mais pas n'importe lequel. Il y a des faux verbes, pauvres de sens.
"L'utilisateur peut saisir une prévision"
"L'utilisateur peut gérer ses prospects".
"Saisir" ou "Gérer" ne sont que des enluminures des noms communs "prévision" et "prospects". Personne n'a besoin d'un logiciel pour saisir des données. C'est plutôt le logiciel qui a besoin d'un utilisateur pour avoir des données.
En utilisant des noms ou des verbes pauvres de sens, on prend implicitement la décision de faire dépendre l'utilisateur de son outil. C'est le logiciel qui pilote l'utilisateur pour le plier à ses exigences, et éventuellement en retour lui fournir des résultats qui l'intéressent.
Pour éviter ce piège, il faut passer du temps pour trouver la bonne formulation.
J'ai vu des "user stories" écrites en 10 secondes, avec un verbe inconsistant. C'est quand même hallucinant de passer si peu de temps sur un truc qui va conditionner plusieurs jours de développement et de tests.
"En tant de gestionnaire de contrat, je veux pouvoir ajouter une entreprise pour faire plaisir au logiciel qui a besoin de cette donnée".
OK je caricature un peu. Mais ça illustre la prédominance du nom ("entreprise") dans l'expression de la fonctionnalité.
Pourquoi le gestionnaire de contrat a-t-il besoin de l'entreprise ? Pour faire quelle action ? Dans quelle intention ?
- lui écrire lorsque ... ?
- faire un virement bancaire au moment de ... ?
- donner ses coordonnées à ... qui en a besoin pour ... ?
Ce temps consacré à réfléchir aux processus et à les formuler correctement est précieux. C'est lui qui permettra de mettre en ligne un logiciel à plus forte valeur ajoutée pour les utilisateurs.
C'est lui qui permettra de décoller les post-its des écrans.
