Pourquoi l’IA ne devrait pas rédiger vos user stories
Lorsque Open AI a lancé ChatGPT en novembre 2022, il y a d'abord eu une période d'intense curiosité sur ce que cet outil pouvait accomplir.
S'en est suivi une véritable course pour comprendre comment exploiter cette technologie révolutionnaire.
Il n'a pas fallu longtemps avant que les chefs de produit s'intéressent à ce sujet et puissent aborder la question sous deux angles différents :
Vous voulez plus de The CPO Club ?
Inscrivez-vous gratuitement pour terminer la lecture de cet article :
Have an account? Log In
- Où puis-je intégrer l'IA dans mon produit ?
- Comment puis-je utiliser l'IA pour me simplifier la vie en tant que chef de produit ?
Si vous travaillez sur une plateforme de gestion de produit, vous pourriez voir l'intersection de ces deux angles en intégrant la génération automatique de user stories à votre outil.
Brillant !
Mais ce n'est pas parce que vous pouvez faire quelque chose, que vous devriez forcément le faire.
La pertinence de l'IA pour rédiger des user stories
En un clin d'œil, toute une nouvelle catégorie d'outils d'IA pour les chefs de produit a émergé—les générateurs de user stories.
Certains sont même gratuits !
Puis, les plateformes de gestion de produit reconnues ont commencé à intégrer des fonctionnalités d'IA dans leurs outils, notamment la génération de user stories en un clic.
Les avantages promis par ces outils, relayés par de nombreux articles, étaient des déclinaisons de cette liste :
- Générer des user stories grâce à l'IA est plus rapide et plus efficace que de les créer manuellement.
- Générer des user stories avec l'IA garantit un format cohérent et donc plus de clarté.
- Générer des user stories avec l'IA permet d'obtenir des histoires plus précises.
- Générer des user stories avec l'IA stimule la créativité.
- Générer des user stories avec l'IA favorise la collaboration.
Je vais examiner chacune de ces hypothèses, mais d'abord il me semble important de revenir sur l'objectif initial des user stories.
À quoi servaient les user stories à l'origine
Dans son livre, User Story Mapping, Jeff Patton résume parfaitement l'origine du terme user story :
Ce n'est pas ce qui est écrit qui compte dans une story, mais la manière dont elle doit être utilisée.
-JEFF PATTON, USER STORY MAPPING
Jeff approfondit ensuite cette idée en citant Kent Beck, qui a développé le concept de user story.
« Si nous nous retrouvons pour discuter du problème que nous voulons résoudre avec le logiciel, qui l'utilisera et pourquoi, alors, ensemble, nous pouvons arriver à une solution et construire une compréhension partagée tout au long du chemin. »
Les user stories identifient ce que quelqu'un veut accomplir avec votre produit, et pourquoi.
Il existe trois points essentiels à garder à l'esprit concernant les user stories, qui entrent en jeu lorsqu'il s'agit de décider comment, ou même si, vous devez utiliser l'IA pour les créer.
1. Les user stories sont des rappels pour susciter une conversation
Elles doivent servir de point de départ à une discussion plus approfondie au sein de votre équipe produit sur le problème que vous aidez vos utilisateurs à résoudre.
Vous voudrez sans doute prendre des notes sur ce qui a été dit, mais faites-le comme mémo et référence, pas comme seul moyen de communiquer les exigences. Même si cela ne remplace pas la rédaction des user stories, l'IA peut s'avérer utile dans la phase de collecte des besoins.
2. Les user stories sont un outil de planification
Elles vous permettent de découper le travail pour construire votre produit en fonction de ce que vos utilisateurs pourront réaliser avec, plutôt que de lister toutes les tâches à effectuer.
Détailler le travail de cette façon vous aide à aller dans le détail quand il le faut—pas trop tôt.
Les user stories vous aident aussi à rester focalisé sur ce que vous allez intégrer dans le produit, et ce que vous n'allez pas intégrer, d'une façon qu'une simple liste de tâches ne permet pas.
C'est pourquoi faire un brainstorming d'une multitude de user stories potentielles n'est pas forcément utile non plus. Nous y reviendrons dans un instant.
3. Ce n'est pas la rédaction qui compte le plus
En raison des deux points précédents, il s'avère que la manière de rédiger les user stories n'est finalement pas si importante.
Comme pour beaucoup de choses dans la vie, on peut se tourner vers Seinfeld pour illustrer ce principe.
Dans l’épisode The Alternate Side, Jerry réserve une voiture de location, pour découvrir qu’ils avaient bien sa réservation, mais pas la voiture. Voici ce qui s’est passé.
Jerry Seinfeld à propos de la réservation de voitures de location :
« Vous voyez, vous savez prendre la réservation, vous ne savez juste pas garder la réservation. Et c’est vraiment la partie la plus importante : garder la réservation. N’importe qui peut les prendre ! »
Si on paraphrase cela pour les user stories :
Vous voyez, vous savez écrire l’user story, mais vous ne savez pas créer de la compréhension partagée avec l’user story. Et c’est vraiment la partie la plus importante : la compréhension partagée. Tout le monde peut les écrire !
Les user stories que vous écrivez et que vous n’écrivez pas sont bien plus importantes que la façon dont vous les écrivez.
Aussi longtemps que votre user story contient assez d’informations pour que l’équipe produit se souvienne de ses discussions sur ce que l’utilisateur cherche à accomplir — cela devrait suffire.
Pourquoi vous ne devriez pas utiliser l’IA pour écrire vos user stories
En gardant ce contexte en tête concernant l’objectif des user stories, utilisons les arguments pour utiliser l’IA afin d’expliquer pourquoi il ne faudrait pas le faire.
Supposition n°1 : C’est plus rapide et plus efficace
Contre-argument : Pas forcément.
La plupart des articles qui ont introduit l’utilisation de l’IA dans la discovery produit pour écrire des user stories insistent ou affirment explicitement que les user stories sont un mal nécessaire.
On entend des plaintes sur le temps qu’il faut pour rédiger toutes ces user stories et pour les rendre parfaites. De doux rêves du style « si seulement on pouvait faire cette tâche plus vite et plus efficacement ! » Certains souhaitent même supprimer tout le brainstorming autour des user stories.
Quand je vois ce genre de plaintes, je me demande si certains ne passent pas à côté de l’essentiel. Noter la user story initiale ne devrait pas être difficile. C’est juste un rappel pour approfondir et noter les informations issues de cette discussion. Elle ne doit pas être parfaite dès le départ.
Écrire plein d’user stories en mode brainstorming et les entasser dans le backlog produit pour s’en occuper plus tard est une mauvaise habitude que beaucoup d’équipes produit ont prise au fil des années.
Une meilleure approche consiste à partir d’un résultat spécifique et à identifier les stories qui permettront d’y parvenir.
Des techniques collaboratives comme les impact maps et les opportunity solution trees vous aident à identifier ces user stories.
Supposition n°2 : C’est cohérent en termes de format et de clarté
Contre-argument : La cohérence de format n’est pas cruciale au début.
À première vue, des user stories cohérentes et claires, c’est une bonne chose. La question à se poser c’est : est-ce important que les user stories soient dans un format cohérent quand vous les rédigez, ou après que l’équipe produit en ait discuté ?
Je soutiens qu’éditer pour la cohérence juste avant que l’équipe ne démarre le développement est plus important que d’être cohérent dès la première rédaction.
Vous allez de toute façon discuter la user story, donc écrivez juste assez pour lancer la conversation et arrêtez-vous là.
Si vous craignez d’oublier ce que signifiait un petit bout de phrase, c’est probablement le signe que vous écrivez la user story trop en avance par rapport au moment où l’équipe va s’en occuper.
Supposition n°3 : Cela stimule la créativité
Contre-argument : Cela peut aussi vous éloigner de l’essentiel.
Les outils dopés à l’IA promettent de vous sortir du syndrome de la page blanche via toute une série de modèles de user stories et d’invitations prêtes à l’emploi. C’est super si vous voulez générer tout un tas d’idées farfelues.
Mais, comme je l’ai dit plus tôt, vous ne voulez pas remplir votre backlog de tout un tas de bruit généré par les user stories. À la place, concentrez-vous sur ce qui va vraiment vous permettre de progresser vers vos résultats attendus.
Les techniques que j'ai mentionnées plus tôt offrent un excellent moyen d’identifier des user stories pertinentes axées sur l’atteinte de résultats. Et n’oubliez pas, les contraintes sont idéales pour stimuler la créativité.
Hypothèse n°4 : C’est plus précis
Contre-argument : Ce n’est vrai que si votre outil d’IA possède une compréhension très approfondie de votre produit et de vos utilisateurs.
L’argument en faveur de la précision affirme que générer des user stories à partir de grandes quantités de données et de retours clients aboutit à des histoires plus précises. On considère en effet que ces stories sont plus « précises » parce qu’elles sont mieux alignées sur les besoins des clients.
C’est sans doute le meilleur argument pour utiliser l’IA, mais il repose sur quelques grands « si ».
- Vous entraînez votre outil d’IA sur les données spécifiques de votre produit.
- Vous disposez de suffisamment de données produit pour réaliser une analyse efficace.
Le premier « si » élimine tous ces outils « gratuits » construits sur GPT 3, 4, etc.
Le second si n’est pas très utile si vous concevez un nouvel outil, ou si vous commencez tout juste à recueillir des retours clients de manière significative.
Hypothèse n°5 : Une collaboration améliorée
Contre-argument : Pardon—quoi ?!
Oui… j’ai dû relire quand j’ai vu cet argument.
On veut me faire croire qu’automatiser la génération des user stories par l’IA—impliquant qu’elles seront prêtes à être jetées par-dessus le mur vers les développeurs dès leur sortie de l’outil—améliore la collaboration ?
J’ai ensuite relu les explications. Elles proclament surtout les bienfaits collaboratifs des user stories en général, et non pas celles créées spécifiquement par l’IA.
Bien essayé, mais je ne suis pas convaincu.
Sous-entendez-vous que je ne dois pas du tout utiliser l’IA ?
Je ne suis pas un opposant à la technologie.
L’IA a sa place, même dans les outils de gestion produit. Chercher à automatiser les activités nécessitant de la collaboration avec votre équipe produit n’est cependant pas la bonne voie.
Il est pertinent d’utiliser l’IA pour synthétiser tous les retours clients que vous recevez. Elle peut aussi s’avérer utile pour générer différents cas de test afin de garantir une couverture complète.
Doug Steele a traité de ce même sujet sur LinkedIn et a suggéré que vous ne devriez pas demander à l’IA de rédiger vos user stories à votre place, mais qu’elle peut vous aider à renforcer vos efforts.
Ce n’est pas parce que vous pouvez que vous devez le faire.
En matière de rédaction de user stories, ou de toute idée d’entreprise liée à l’IA, n’utilisez pas l’IA simplement pour le principe. Identifiez précisément là où l’IA apporte réellement de la valeur.
Un excellent point de départ consiste à reformuler les questions que j’ai posées ci-dessus.
- À quel endroit l’IA pourrait-elle avoir du sens dans votre produit ?
- À quel endroit cela a-t-il du sens d’utiliser l’IA pour soutenir vos activités de gestion produit ?
Formuler les questions de cette façon vous aidera à utiliser l’IA de manière responsable—pour améliorer votre produit et vous faciliter la vie de PM.
N’oubliez pas de vous abonner à notre newsletter pour plus de ressources et de guides en gestion produit, ainsi que pour découvrir les derniers podcasts, entretiens et autres perspectives de leaders et experts du secteur.
