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.
Rassembler les exigences dans un monde Agile
À 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 !)
Créer une vision commune entre les équipes
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.
Vous voulez essayer ? Inscrivez-vous ou connectez-vous à 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
- Le projet est déjà entièrement spécifié de façon très détaillée avant le début de tout travail d'ingénierie
- Une revue minutieuse et une approbation stricte sont requises de la part de toutes les équipes avant même que le travail ne démarre
- Les concepteurs et les développeurs ne savent pas quand les exigences ont été actualisées
- Les exigences ne sont jamais actualisées (parce que tout le monde les a approuvées, vous vous rappelez ?)
- Le Product Owner rédige les exigences sans faire participer l'équipe
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 ?
Un document d'exigences produit simplifié via un tableau de bord d'une page
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.
Le Manifeste Agile nous rappelle que nous pouvons faire preuve de flexibilité dans la façon de rédiger les exigences. Certaines équipes réalisent des exercices de cartographie des user stories afin d'identifier les problèmes et les solutions. Il arrive que le trio complet du produit (Product Owner, développeur et designer) se rende chez le client et réfléchisse aux solutions à un problème particulier que celui-ci a mentionné.
Peu importe comment naissent les exigences, l'équipe doit impérativement les considérer comme une méthode parmi tant d'autres pour définir et communiquer les problèmes du client. Consultez notre section consacrée au design Agile pour savoir comment les Product Owners peuvent, grâce à Keynote et PowerPoint, simuler des expériences réelles en tant qu'exigences.
Exemple de document d'exigences produit sur une page
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.
Vous voulez essayer ? Inscrivez-vous ou connectez-vous à Confluence >>
Une fois connecté, sélectionnez le modèle d'exigences produit, puis suivez le tutoriel ci-dessous pour vous aider à définir vos exigences :
Enseignements clés de l'approche sur une page :
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.
Défis
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.
Et maintenant, au travail !
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 stack technique.
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.
Évitez de suivre les user stories issues des exigences du projet et les défauts dans deux systèmes distincts. Gérer le travail dans deux systèmes différents, c'est se compliquer la vie pour rien. Une perte de temps, ni plus ni moins.
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.
