Exigences produit : rédiger un PRD à partir d’entretiens
Transformez vos entretiens en document d’exigences produit : problème, scénarios, contraintes, périmètre de version et critères de vérification. Avec modèle et exemple.
Demander un bouton ne suffit pas à définir le besoin
Un client dit « Ajoutez un bouton d’export ». Cela ne dit pas qui utilisera le fichier, ce qu’il doit contenir ni à quoi il servira. Le document d’exigences produit, ou PRD, donne à l’équipe une compréhension commune de la tâche et de son périmètre.
Il s’agit ici d’un document court pour une fonctionnalité. L’architecture, le contrat et les exigences techniques de l’organisation gardent leur place. Le PRD rend le problème vérifiable avant le choix de l’implémentation.
De la demande utilisateur aux exigences
Revenez au dernier cas réel
Demandez quand l’export a été nécessaire, ce que la personne a fait à la place, quelles données elle a déplacées et où elle a rencontré une difficulté. Notez l’exemple et la conséquence. « C’est peu pratique » doit être précisé pour vérifier une amélioration.
Décrivez le scénario avant de choisir l’interface
Notez qui commence, avec quelles données et pour quel résultat. Un bouton, un courriel et un rapport automatique sont des solutions possibles. Étudiez le besoin et les contraintes avant d’imposer le premier choix.
Définissez le périmètre de la version
Écrivez ce qui est inclus et volontairement exclu. Listez à part les accès, les champs et les cas sans résultat. Convenez des conditions de mesure avant de fixer des exigences de vitesse ou de volume.
Formulez la vérification
Pour chaque exigence, donnez un résultat observable et des données d’exemple. Reliez le test au problème initial. Si un point n’a pas été confirmé, notez une question ouverte, la personne chargée d’y répondre et la date de décision.
Exporter une liste de demandes clôturées
Cet exemple est fictif. Les noms, conditions et résultats servent à expliquer la méthode.
Chaque vendredi, je copie à la main les demandes clôturées dans un tableau. Le responsable a besoin du sujet, de la date de clôture et de la personne chargée du dossier. Les échanges sont inutiles.
Il faut transmettre des champs précis sur une période. L’entretien ne demande ni toute la base, ni les pièces jointes, ni le texte intégral des échanges.
Critère possible : après sélection d’une période, l’export contient les demandes clôturées pendant celle-ci et seulement les champs convenus. Précisez à part le traitement des dates limites.
| Élément du PRD | Saisie d’exemple | Statut |
|---|---|---|
| Utilisateur | Responsable de l’assistance | Confirmé dans l’entretien |
| Champs | Sujet, date de clôture, responsable | À vérifier avec le destinataire |
| Hors périmètre de cette version | Échanges et pièces jointes | À convenir |
| Question ouverte | Quel fuseau horaire définit les limites de période ? | Réponse nécessaire |
Modèle de PRD pour une fonctionnalité
Reliez chaque exigence à une observation. Une source peut soutenir plusieurs points. Il faut encore confirmer leur validation.
Nom et version de la fonctionnalité : Problème utilisateur : Cas concret de l’entretien : Utilisateur et contexte : Scénario principal : Résultat attendu : Données et contraintes : Dans et hors du périmètre : Critères de vérification : Hypothèses et questions ouvertes : Sources et repères temporels : Validation par et date :
Peut-on vérifier les exigences sans l’auteur ?
- Chaque exigence explique quel problème elle résout.
- Le résultat vérifiable est distinct de l’implémentation.
- Le périmètre de la version est explicite.
- Les questions ouvertes sont identifiées.
Dans le détail
Peut-on rédiger un PRD à partir des seuls souhaits du commanditaire ?
Un brouillon est possible. Vérifiez les scénarios et contraintes réels. Un souhait décrit une solution possible et peut laisser le problème de l’utilisateur sans explication.
Quelle longueur donner au document ?
Il doit rendre le scénario, le périmètre, les contraintes et le contrôle compréhensibles. Pour une petite fonctionnalité, un texte court avec exemples est souvent plus pratique qu’une longue description d’objectifs généraux.