Grégory Weinbach nous a présenté sa conférence (voir la présentation) sous l’angle du storytelling. Il prend l’exemple de la facturation dans une société de services, le directeur souhaite améliorer la productivité et pour cela demande à une société tierce de lui réaliser une application pour remplacer les formulaires Excel. Que l’on soit dans un processus agile ou en cascade, les étapes s’enchaînent entre le recueil de besoins, l’analyse, la conception, le développement et le déploiement – dans un cadre agile, cet enchaînement sera répété plusieurs fois.
Dans l’histoire racontée par Grégory Weinbach, le product owner ne sait pas recueillir le besoin. Le rôle d’AMOA est donc délégué à une développeuse de l’équipe scrum, Angelina. L’utilisateur, Brad, explique son besoin : « J’ai besoin de créer mes factures et de les imprimer. J’ai besoin d’imprimer des duplicatas de factures déjà calculées. » Angelina se fait expliquer chacune de ces user stories, et les développements démarrent.
L’équipe d’Angelina évite de tomber dans le cas classique de centrer l’IHM sur la donnée, et produit une application qui permet de faire le travail demandé, avec deux menus qui correspondent aux processus :
- Saisir une facture
- Imprimer un duplicata
Lors de la saisie de la facture, il faut la lier à un contrat, auquel l’utilisateur peut accéder via un formulaire de recherche.
Lors des tests, Brad se plaint. En effet, dans la liste des contrats lui permettant de remplir sa facture, il voit tous les contrats, y compris ceux qui ne le concernent pas. Il avait pourtant bien précisé qu’il voulait créer ses factures, ce qui sous-entend bien qu’il ne s’agit pas de celles de ses collègues. Une première amélioration est donc effectuée en filtrant les résultats de recherche sur ses contrats.
L’application est ensuite mise en production, tout le monde est satisfait, ou presque. En effet, Brad se plaint qu’il oublie régulièrement des clients, que c’est long, fastidieux et répétitif. Créer une facture nécessite 7 clics et une saisie, ce qui est à multiplier par le millier créé chaque mois…
Où se situe donc le problème ? Il faut pour cela revenir au tout début, lors de la phase de recueil de besoins. Angelina a omis de poser une question cruciale à Brad, et cette question est : « Pourquoi ? ». Ainsi, Angelina aurait su que le besoin était de facturer le mois précédent. Avec cette perspective, l’application qui en aurait découlé n’aurait pas été une application de création de facture, mais une application de facturation :
- Affichage de la liste des contrats du mois précédent, avec génération des factures pour tous les contrats facturables, et envoi d’un mail de rappel pour les autres (ceux pour lesquels l’employé n’a pas rempli sa feuille de temps)
- Affichage des missions qui ne sont pas encore facturées
- Saisie/modification de factures
Cette application aurait été à l’origine d’une forte automatisation du travail, qui aurait bien mieux satisfait Brad.
En conclusion, Grégory Weinbach met en valeur ce problème des applications qui sont plus centrées sur les données que sur les besoins. C’est à nous d’y prendre garde, et de toujours creuser le besoin derrière celui exprimé pour obtenir une application qui facilitera au mieux la vie de l’utilisateur. Nous ne devrions jamais voir dans le afin d’une user story des termes tels que « créer une facture », « mettre à jour une commande », « consulter une réservation », « supprimer une note de frais ». En effet, ce ne sont pas des objectifs métier, mais des moyens éventuels d’y parvenir. La base d’une bonne expérience utilisateur, c’est une bonne expression du besoin.
J’ai personnellement beaucoup apprécié cette conférence, très complémentaire avec la mienne, qui aborde en détail le sujet de la réponse au besoin (plutôt qu’à la demande). En France, nous sommes encore en retard au sujet de l’UX pour des applications destinées aux clients, et c’est une bonne chose de voir de plus en plus de développeurs sensibilisés au sujet, en particulier pour les applications métier.
Crédits photo
Film Mr and Mrs Smith
