Remplacer la User Story par la Job Story

Bonjour à tous. Traduit un autre matériel intéressant pour les étudiants du cours "Product Manager IT-projects" . Bonne lecture

---

Plus tôt, j'ai déjà écrit sur les problèmes avec la user story (user stories). À cette époque, je pensais qu'il valait mieux demander à l'équipe de discuter des modifications proposées au produit. La stratégie était bonne si l'équipe apportait son aide et que le produit était déjà mûr. Cependant, maintenant je travaille avec une nouvelle équipe et je crée un produit à partir de zéro. Dans ce cas, nous avons une feuille vierge et il n'est pas facile pour nous de parvenir à un accord en ce qui concerne la motivation du client, les événements et les attentes. Aujourd'hui, tout a changé. J'ai trouvé un excellent moyen d'utiliser la philosophie Jobs To Be Done pour définir la fonctionnalité du produit. Aujourd'hui, nous allons parler de Job Stories.

D'où venait-elle?

Cette idée est venue de gars très intelligents d' Intercom . Voici ce qu'ils disent à ce sujet:

Nous appelons chaque tâche d'architecture Job, nous nous concentrons sur la situation ou l'événement qui l'initie, la motivation ou le but, et nous obtenons ce qui suit:

Lorsque _____, je veux que ______ à _______.

Par exemple, lorsqu'un nouveau client important s'inscrit, je souhaite recevoir des alertes afin de pouvoir entamer une conversation avec lui.

Dans cet article, je ne fais pas référence à cette construction quant à Job Story, mais je vais la nommer de manière à pouvoir y faire référence facilement à l'avenir.

Aujourd'hui, nous ne passerons pas beaucoup de temps à expliquer le concept, je vais juste expliquer pourquoi je l'aime et pourquoi c'est mieux que User Story.

À propos du problème de la user story [encore une fois]

En général, le problème avec les user stories est qu'elles contiennent trop d'hypothèses et peu de causalité. Lorsqu'une tâche est définie au format d'une user story ( comme [type d'utilisateur], je veux que [action] obtienne [résultat] ), il n'y a pas de place pour la question «pourquoi?». En fait, vous êtes simplement limité à une certaine séquence prise hors contexte.

Voici comment je vois ce format:


Hypothèses et manque de communication entre une personne et son action.

Le premier problème est que nous partons d'une personnalité, ce qui n'est pas une bonne idée , puis vient l'action, qui, à notre avis, devrait être prise pour atteindre le résultat souhaité. Comme je l'ai déjà noté dans la figure ci-dessus, en fait, l'écart est entre l'action et la personnalité.

Regardons quelques histoires d'utilisateurs existantes:


Un exemple de comment écrire des User Stories

En regardant le tableau ci-dessus, peut-on dire que les types d'utilisateurs «modérateur» et «évaluateur» ajoutent de la couleur à l'image globale? En tout cas, cela ajoute de l'ambiguïté. Nous pouvons offrir notre propre interprétation de ces concepts et pourquoi le contexte ressemble à ceci.

Ici, essayez-le. Supprimez toute la partie «en tant que [type d'utilisateur]» et voyez si vous perdez vraiment quelque chose. Comparez les déclarations suivantes:

En tant que modérateur, je souhaite créer un nouveau jeu en entrant un nom et une description facultative.

Ou bien:
Je veux créer un nouveau jeu en entrant un nom et une description facultative.
Le ciel s'est-il effondré?

Histoire de travail: tout sur le contexte et la causalité


Format de l'histoire de l'emploi

Basé sur encore plus d'expérience et de commentaires, j'utilise maintenant une explication légèrement différente. Maintenant, je le vois comme suit .

Regardons à nouveau l'image et commençons enfin!

Toutes les informations ci-dessus sont très importantes et informatives, car nous nous concentrons sur le lien de causalité. Chaque Job Story doit contenir autant de contexte que possible et se concentrer sur la motivation, pas seulement sur la mise en œuvre.

Après avoir travaillé avec Job Story pendant un certain temps, j'ai changé Motivations en Motivations and Acting Forces. Jetez un œil à l'article «5 conseils pour rédiger une histoire de poste», où ce sujet est abordé directement. Vous pouvez en savoir plus sur les forces agissantes dans ce podcast et ce court article .

Réécrivons quelques exemples du tableau Job Story ci-dessus dans Job Story, en ajoutant de la motivation et du contexte à chacun.

Histoire d'utilisateur:
En tant que modérateur, je souhaite créer un nouveau jeu en entrant un nom et une description facultative.
Histoire d'emploi:
Lorsque je suis prêt, pour que les évaluateurs parient sur mon jeu, je veux créer le jeu dans un format qu’ils comprennent, afin que les évaluateurs puissent trouver mon jeu et comprennent qu’ils peuvent parier.

Histoire d'utilisateur:
En tant qu'évaluateur, je souhaite voir l'objet valorisé afin de savoir sur quoi je parie.
Histoire d'emploi:
Lorsque je trouve un article que je veux évaluer, je veux pouvoir le regarder afin de comprendre que j'ai vraiment besoin de l'article sur lequel je parie.

Histoire d'utilisateur:
En tant que modérateur, je souhaite sélectionner un élément pour évaluation ou réévaluation, l'équipe voit cet élément et peut l'évaluer.
Histoire d'emploi:
Lorsqu'un élément n'a pas de note ou que je n'aime pas la note, je veux pouvoir redémarrer le processus d'évaluation et informer tout le monde afin que l'équipe sache qu'un certain sujet doit être évalué.

Qu'en est-il des rôles et événements multiples?

Étant donné que je reçois diverses critiques sur le Job Story et que je continue à travailler avec eux, je trouve approprié d'inclure parfois certains rôles ou personnages dans la partie Quand _____ .

Produits à rôles multiples

Les rôles et les personnages sont plus utiles lorsque le produit lui-même a plusieurs rôles, par exemple, un produit informatique (administrateur, gestionnaire, participant) ou un produit de marché ouvert (acheteur, vendeur). La raison en est qu'il faut toujours comprendre de qui on parle.

Prenons eBay comme exemple:

Lorsque l'acheteur a déjà placé un pari sur le produit, il craint que quelqu'un fasse une grosse offre et souhaite recevoir des notifications afin d'avoir suffisamment de temps pour évaluer et mettre à jour sa propre offre.

Rôles et causalité

Parfois, des situations surviennent lorsque le Job Story décrit l'interaction de plusieurs rôles à la fois, créant un scénario causal.

Et encore une fois, prenez eBay comme exemple:

Lorsque le vendeur n'est pas satisfait des offres reçues et retire son produit du marché, les acheteurs qui ont déjà soumis des offres souhaitent recevoir immédiatement une notification que le produit a été retiré de la vente aux enchères afin qu'ils ne suivent plus sa dynamique de prix et recherchent un autre produit similaire.

Utilisation d'événements au lieu de rôles

Parfois, une situation peut survenir lorsqu'un événement affecte tous les rôles ou groupes de personnes: par exemple, vous devez obtenir un rappel de mot de passe. Dans ce cas, il n'y a aucune raison d'introduire un rôle spécifique, mais plutôt de le laisser au niveau des concepts généraux, par exemple, «client» ou quelque chose de similaire (mais pas «utilisateur»):

Lorsqu'un client utilise son appareil mobile et oublie le mot de passe, il souhaite disposer d'un mot de passe qui pourrait être facilement restauré à l'aide de son appareil mobile afin que le client puisse continuer à se connecter et accéder à son fil d'actualités.

Pourquoi pas un utilisateur ? Un «utilisateur» semble sans vie et sans résultat, tandis qu'un «client» vous rappelle qu'il y a des personnes à qui vous devez fournir un service et qui doivent être respectées.

Définir la motivation, pas la mise en œuvre

Les histoires de travail sont bonnes car elles nous font penser à la motivation et au contexte, et suppriment également l'accent mis sur l'ajout d'une implémentation particulière. Souvent dû au fait que les gens se concentrent sur les questions «qui» et «comment», oubliant complètement le «pourquoi». Lorsque vous commencez à penser au «pourquoi», votre esprit s'ouvre à des façons créatives et originales de résoudre le problème.

En savoir plus

Votre histoire d'emploi a besoin d'un moment difficile (https://jtbd.info/your-job-story-needs-a-struggling-moment-c03de87c6026), 5 conseils pour rédiger une histoire d'emploi.
Vous pouvez également en apprendre davantage sur JTBD et Job Story dans mon livre When Coffee and Kale Compete.
Vous pouvez le dire gratuitement en PDF ou acheter une version papier ici . Et ici, vous pouvez le commander en ligne.