Repère les lacunes de ton PRD avant les relecteurs
6 min de lecture
La plupart des PRD partent après une seule relecture par la personne qui les a écrits. Cela rattrape les coquilles, mais rarement la lacune qui fait poser la même question de clarification dans les commentaires de chaque document que tu envoies, car tu connais déjà la réponse et lis sans t’arrêter là où elle manque. Un PM qui a porté le contexte d’une fonctionnalité dans sa tête pendant deux semaines lit un PRD à son sujet complètement autrement qu’un ingénieur qui ouvre le document à froid pour la première fois.
Attention
Une relecture par l’auteur vérifie si le document a du sens pour quelqu’un qui connaît déjà la fonctionnalité. Elle ne vérifie pas s’il a du sens pour quelqu’un qui ne la connaît pas, ce qui est le vrai relecteur.
Le PRD qui survit à ta propre relecture est celui que tu es le moins qualifié pour juger.
Pourquoi la même question revient sans cesse en relecture
Tu as écrit le document avec tout le contexte déjà en tête, si bien qu’une lacune dans les exigences ne te paraît pas une lacune, elle te paraît évidente. Le relecteur n’a pas ce contexte, si bien que le même genre de question, un cas limite non traité, une hypothèse non dite, refait surface document après document. Si trois de tes cinq derniers PRD ont reçu le même commentaire demandant comment la fonctionnalité doit se comporter pour un type d’utilisateur précis, ce n’est pas de la malchance, c’est un schéma dans ta façon d’écrire le périmètre.
Prends un PRD pour une fonctionnalité d’export en masse qui précise exactement ce qui se passe pour un utilisateur standard exportant jusqu’à 10 000 lignes. Il ne dit pas ce qui se passe à 100 000 lignes, ni pour un utilisateur d’une offre gratuite avec des limites d’export, parce que l’auteur pensait au cas courant tout le temps de la rédaction. Un ingénieur qui reprend le document n’a aucun moyen de déduire ces réponses, et le fil de commentaires qui en résulte, « que se passe-t-il au-delà de la limite de lignes ? », est la même question qui serait remontée sur les trois derniers PRD aussi, si quelqu’un avait pensé à vérifier.
Avant : écrire le PRD, le relire une fois, décider qu’il est clair, l’envoyer en relecture.
Après : le confier à Claude avec le vrai contexte de la fonctionnalité, demander précisément si le périmètre est clair et quels cas limites manquent, et corriger ce qu’il trouve avant qu’un relecteur n’ait à poser la question.
Une méthode pour tester un PRD avant la relecture
- 1
Donne à Claude le vrai brouillon et le vrai contexte
Colle l’énoncé du problème et les exigences tels qu’ils sont écrits, pas un résumé, avec le public visé par cette fonctionnalité. Un PRD pour un outil d’administration interne demande une couverture de cas limites différente de celle d’une fonctionnalité publique, et le même cas limite manquant compte plus ou moins selon les personnes concernées.
- 2
Demande précisément si le périmètre est clair
Un vague « est-ce que ça a du sens » obtient une réponse vague. Demande directement si quelqu’un sans contexte préalable pourrait dire ce qui est dans le périmètre et ce qui n’y est pas à partir du seul document, ce qui est le vrai test qu’affrontera un ingénieur reprenant le document à froid.
- 3
Demande les cas limites manquants, pas une critique générale
Demande les cas limites précis que les exigences ne traitent pas, pas un retour ouvert. Un cas limite manquant est concret et corrigeable ; « cela pourrait être plus clair » ne l’est pas.
- 4
Corrige les lacunes avant que quelqu’un d’autre ne voie le document
Mets à jour directement la section des exigences à partir de ce que Claude a signalé. La version que voit un relecteur doit déjà refléter les questions qu’on te poserait autrement dans les commentaires, pour que le temps de relecture aille à de vrais désaccords plutôt qu’à des clarifications de base.
Voici l’énoncé du problème et la section des exigences de mon PRD pour une fonctionnalité d’export en masse. Dis-moi honnêtement si le périmètre est clair, et signale tout cas limite que je n’ai pas traité.
”Pour une fonctionnalité soumise à une contrainte technique précise que tu connais déjà, une limite de débit, un plafond de taille de données, une frontière de permissions, il vaut la peine de la dire directement à Claude pour que la vérification des cas limites s’appuie sur le système réel plutôt que sur des suppositions génériques.
Notre système d’export a une limite stricte de 500 000 lignes au niveau de l’infrastructure, qui n’est mentionnée nulle part dans ce PRD. Compte tenu de cette contrainte, quels cas limites autour des limites de lignes les exigences doivent-elles traiter explicitement ?
”
Dans Claude Tutorial
Tester un document face à un lecteur qui n’a pas ton contexte est transposable.
Vérifier si quelque chose a du sens pour quelqu’un sans ton bagage, au lieu de te fier à ta propre relecture, vaut bien au-delà des PRD. L’appli propose une leçon complète à ce sujet, avec une pratique qui s’applique à tout document que tu écris pour que quelqu’un d’autre agisse.
Quand les lacunes viennent toujours de la même section
Si les cas limites remontent sans cesse dans la même partie de tes PRD, il vaut la peine de le repérer comme un schéma, et non de corriger à nouveau de zéro chaque fois. Une lacune récurrente, disons, dans la section des permissions signifie en général que cette section a besoin d’une liste de contrôle permanente, pas d’une énième relecture ponctuelle. Corriger la même catégorie de lacune trois fois séparément est le signe que c’est l’habitude de fond qui doit changer, pas seulement le document en cours.
Astuce
Demande à Claude de comparer les lacunes de ce PRD avec celles de tes derniers documents, si tu les as. Un schéma sur plusieurs PRD est un signal plus fort que les cas limites d’un seul document, et il t’indique où bâtir une liste de contrôle réutilisable.
C’est le troisième PRD de suite où les relecteurs posent des questions sur la gestion des permissions. Voici la section permissions de ce brouillon. Qu’est-ce qui manque, et que devrait couvrir désormais une liste de contrôle permanente pour cette section ?
”Une fois qu’une telle liste de contrôle existe, il vaut la peine de passer la section concernée de chaque nouveau PRD à travers elle avant la première relecture, plutôt que de compter sur la mémoire pour repérer chaque fois la même lacune récurrente.
Voici la liste de contrôle des permissions que nous avons construite la dernière fois, et voici la section permissions d’un nouveau PRD. Vérifie-la par rapport à la liste de contrôle et signale tout ce que la liste couvre et que ce brouillon n’a toujours pas.
”Pour aller plus loin
- Rédiger un PRD à partir d’une demande de fonctionnalité en une ligne : bien poser la structure dès le départ, avant la passe de relecture et de correction que cet article couvre.
- Transformer des tickets d’assistance en thèmes priorisés : d’où viennent souvent, au départ, les cas limites qu’un PRD doit couvrir.
- Bien démarrer avec Claude : les habitudes de fond, contexte, itération, précision, sur lesquelles repose tout ce processus.