Comment créer un document d'exigences produit

Résumé : un document d'exigences produit définit les exigences d'un produit spécifique, y compris son objectif, ses fonctionnalités et son comportement. Il sert de guide aux équipes métier et techniques pour les aider à développer, lancer ou commercialiser le produit.

Développer un produit d'exception demande beaucoup de recherches et une planification exhaustive. Mais par où commencer ? Les responsables produit commencent souvent par un document d'exigences produit.

Un document d'exigences produit définit le produit que vous allez développer : il décrit l'objectif du produit, ses fonctionnalités et son comportement.

Ensuite, vous partagez le document d'exigences produit avec les parties prenantes (équipes métier et techniques) et sollicitez leur contribution. Elles vous aideront à développer, lancer ou commercialiser votre produit.

Une fois toutes parties prenantes alignées, le document d'exigences produit sert de boussole, définissant une orientation claire sur la finalité d'un produit, tout en créant une vision commune au sein des équipes métier et techniques.

À quoi ressemble le processus de rassemblement des exigences à l'ère Agile ? Cela paraît délicat, et ça l'est. Mais pas d'inquiétude. Chez Atlassian, nous maîtrisons parfaitement la création de documents d'exigences produit dans un environnement Agile. Voici quelques éléments à ne pas oublier :

Les exigences Agile sont les meilleures amies du responsable produit. Celui qui ne les utilise pas se retrouve à devoir préciser chaque détail afin de pouvoir livrer le logiciel adéquat (puis à croiser les doigts en espérant que les spécifications sont correctes). D'autre part, les exigences Agile dépendent de la vision commune du client, à savoir celle qui est partagée entre le responsable produit, le concepteur et l'équipe de développement. Cette compréhension et cette empathie communes pour le client cible ouvrent des horizons nouveaux pour le responsable produit. Il peut se concentrer sur les exigences principales et laisser les détails de la mise en œuvre à l'équipe de développement, laquelle est parfaitement équipée pour le faire, encore une fois grâce à cette vision commune. (Et paf !)

Si l'idée d'une compréhension partagée vous emballe, mais que vous ne savez pas du tout comment y parvenir, suivez ces quelques conseils :

• Lors des entretiens avec les clients, invitez un membre des équipes de conception et de développement afin qu'il puisse entendre le client directement plutôt que de faire confiance aux notes du responsable produit. Il aura également la chance de sonder un peu plus en détail le sujet tant qu'il est frais dans l'esprit du client.
• Faites en sorte que l'élaboration et l'utilisation de la personnalité du client soient un travail d'équipe. Chaque individu au sein de l'équipe présente ses propres perspectives et opinions, et doit comprendre de quelle façon la personnalité influence le développement du produit.
• Faites en sorte que le tri des tickets et la préparation du backlog soient également des sports d'équipe. C'est une excellente occasion pour vous assurer que tout le monde est sur la même longueur d'onde et comprend pourquoi le Product Owner a hiérarchisé le travail comme il l'a fait.

Want to give it a try? Sign up or log into Confluence >>

Créez un modèle d'entretien client pour documenter vos informations sur les clients. Suivez notre tutoriel pour apprendre à réaliser des entretiens clients pertinents :

• Créer des pages d'entretien client pertinentes
• Transformer des informations en données exploitables grâce à la pyramide des entretiens client

Bon, vous avez analysé une série de user stories avec votre ingénieur et votre concepteur. Après les avoir examinées sous toutes les coutures, et après quelques sessions de tableau blanc, vous en avez conclu que vous deviez envisager d'autres dimensions pour la fonctionnalité sur laquelle vous êtes en train de travailler. Vous avez besoin d'étoffer quelques-unes de vos hypothèses, de réfléchir un peu plus à la façon dont cela s'inscrit dans le schéma global et d'assurer le suivi de toutes les questions ouvertes auxquelles vous devez répondre. Et après ?

Lorsque vous rédigez un document d'exigences, il peut être utile d'utiliser un modèle unique à tous les niveaux de l'équipe. Ainsi, tout le monde peut y souscrire et donner son feedback. Chez Atlassian, nous utilisons Confluence pour créer les exigences produit via le modèle d'exigences produit. Nous estimons que la section ci-dessous fournit « juste ce qu'il faut » de contexte pour comprendre les exigences d'un projet et son impact sur les utilisateurs :

1. Définition des spécificités du projet
Nous vous conseillons d'insérer, en haut de la page, une orientation globale comme suit :

• Participants : qui est impliqué ? Inclure le responsable produit, l'équipe, les parties prenantes
• État : quel est l'état actuel du programme ? Cap tenu, risque, retard, report, etc.
• Date de livraison : quand est-elle prévue ?

2. Objectifs de l'équipe et objectifs métier
Allez droit au but. Informez, sans être ennuyeux.

3. Contexte et pertinence stratégique
Pourquoi faisons-nous cela ? Comment cela s'inscrit-il dans les objectifs globaux de l'entreprise ?

4. Hypothèses
Dressez la liste de vos éventuelles hypothèses techniques, métier ou utilisateur.

5. User stories
Dressez la liste des user stories concernées ou fournissez le lien idoine. Fournissez également le lien vers les entretiens client et ajoutez les captures d'écran de ce que vous avez vu. Donnez suffisamment de détails pour que le récit soit complet et n'oubliez pas les métriques de réussite.

6. Interaction avec l'utilisateur et design
Une fois que l'équipe a étoffé la solution pour chaque user story, reliez les explorations du design et les maquettes fonctionnelles à la page.

7. Questions
En général, au fur et à mesure que l'équipe comprend quel est le problème à résoudre, des questions émergent. Dressez un tableau des éléments qui doivent faire l'objet d'une décision ou de recherches afin d'en assurer le suivi.

8. Ce que nous ne faisons pas
Recentrez l'attention de l'équipe sur la tâche en cours en affirmant clairement ce que vous ne faites pas. Signalez les aspects qui, pour le moment, sont en dehors du périmètre, mais pourraient être envisagés ultérieurement.

Voici un document d'exigences produit complet créé avec Confluence. Rappelez-vous, il n'existe pas deux exigences produit identiques. Utilisez cet exemple pour comprendre les différents éléments qui devraient être inclus dans votre document d'exigences produit, mais pas comme la seule manière de le faire.

Si vous ne devez retenir qu'une seule chose de ce blog, c'est qu'il faut comprendre le « pourquoi », pas le « quoi ». En effet, le « pourquoi » vous aidera à découvrir ce qui est mieux pour votre équipe. Voici les avantages et les défis que nous avons observés dans l'approche de tableau de bord d'une page :

1. Une page, une source
Visez la simplicité. Le document d'exigences produit devient la « page d'accueil » de tout ce qui a trait à l'ensemble des problèmes au sein d'une epic spécifique. En proposant aux membres de l'équipe un espace centralisé, vous leur faites gagner du temps pour accéder à ces informations et leur fournissez une vue concise.

2. Agilité supplémentaire
L'un des formidables avantages qu'il y a à utiliser une simple page pour collaborer (plutôt qu'un outil de gestion des exigences dédié), c'est que cela offre une grande agilité pour la documentation ! Vous n'avez pas à suivre le même format à chaque fois. Faites ce dont vous avez besoin, lorsque vous en avez besoin, et restez agile en le faisant. Vous pouvez changer et vous adapter en fonction des besoins.

3. Juste ce qu'il faut de contexte et de détails
Nous oublions souvent le pouvoir d'un simple lien. Nous insérons un grand nombre de liens dans nos documents d'exigences produit. Cela permet de décomplexifier et de divulguer progressivement les informations au lecteur, au fil des besoins. Les liens vers des ressources détaillées peuvent inclure, entre autres :

• Entretiens clients concernant l'historique, la validation ou la précision du contexte pour la fonctionnalité
• Pages ou blogs où des idées similaires ont été proposées
• Discussion antérieure ou documentation technique et schémas
• Vidéos de démos de produits ou autres contenus associés provenant de sources externes

4. User stories vivantes
J'observe beaucoup de clients qui procèdent de la même façon. Une fois que les user stories ont été grosso modo imaginées et enregistrées sous forme de tickets dans Jira, nous insérons des liens vers celles-ci sur notre page (qui, et c'est bien pratique, crée également un lien inverse, des tickets vers la page). Grâce à la synchronisation bidirectionnelle entre Confluence et Jira, nous voyons automatiquement le statut actuel de chaque ticket, directement depuis la page des exigences.

5. Sagesse collective
Le regroupement des exigences produit dans Confluence permet aux membres des autres équipes d'apporter facilement leurs contributions et suggestions. J'ai été épaté du nombre de fois où les membres des autres équipes intervenaient dans la conversation par des commentaires très utiles, des suggestions ou des leçons tirées de projets similaires. Grâce à cela, une grande organisation se sent comme une petite équipe.

6. Insertion de supports supplémentaires
Les schémas réalisés au moyen d'outils tels que Visio, Gliffy ou Balsamiq permettent de mieux communiquer les problèmes à votre équipe. Vous pouvez également insérer des images externes, des vidéos et des contenus dynamiques.

7. Collaboration !
L'aspect le plus important de tout cela, c'est d'impliquer tout le monde. Ne rédigez jamais un document d'exigences produit par vous-même. Vous devez toujours avoir un développeur à vos côtés pour la rédaction. Partagez la page avec votre équipe et recueillez son feedback. Commentez, posez des questions, encouragez les autres à apporter leur contribution par leurs réflexions et leurs idées. C'est particulièrement important pour les équipes décentralisées qui n'ont pas souvent l'occasion de discuter des projets en face à face.

Chaque approche présente des inconvénients. Voici deux défis principaux que nous avons rencontrés et observés chez des clients également :

1. La documentation peut devenir obsolète
Que se passe-t-il lorsque vous implémentez une user story, recevez un feedback, puis modifiez la solution ? Est-ce que quelqu'un actualise la page des exigences avec l'implémentation finale ? C'est une difficulté que l'on rencontre avec n'importe quel type de documentation, et il est toujours judicieux de se demander si de tels compromis en valent la peine. Discutez avec votre équipe de ce que vous feriez dans un tel cas.

2. Manque de participation
« Que faire pour inciter les autres à commenter ? Comment les encourager à rédiger davantage de spécifications et de user stories sur notre intranet ? » C'est un vrai casse-tête. Globalement, votre organisation doit appliquer différentes techniques d'adoption du wiki. De nombreuses ressources peuvent vous aider en ce sens. Toutefois, cela peut également être lié à certains aspects culturels plus profonds.

Lorsque les exigences sont souples, le Product Owner dispose de plus de temps pour comprendre le marché et s'y adapter. Les exigences doivent rester informatives mais brèves. Ainsi, l'équipe de développement pourra utiliser la mise en œuvre la plus adéquate pour son architecture et sa pile technologique.

Une fois que les exigences du projet sont raisonnablement prêtes, nous vous conseillons de relier les user stories de la section 5 ci-dessus aux stories correspondantes dans l'outil de suivi des tickets de l'équipe de développement. Le processus de développement est ainsi plus transparent : il est facile de visualiser l'état de chaque tâche, ce qui permet de prendre des décisions en meilleure connaissance de cause, que ce soit pour le responsable produit ou pour les équipes en aval, comme le marketing et le support.

N'oubliez pas de rester Agile dans l'évolution des exigences de votre projet. Il est parfaitement acceptable de modifier les user stories au fur et à mesure que l'équipe développe, livre et reçoit du feedback. Maintenez toujours une qualité élevée et une culture d'ingénierie saine, même si cela implique de livrer moins de fonctionnalités.