Une présentation d’exigences produit n’est pas un PRD copié-collé. Elle met en avant ce dont la revue a besoin : problème, périmètre, non-objectifs, critères d’acceptation et décisions en suspens. Avec texte vers présentation, vous pouvez créer un premier brouillon éditable à partir d’un plan vérifié ; les exigences et leurs limites doivent toujours venir de votre PRD.
Nommer la question de revue
Ouvrez par une phrase comme « valider le périmètre de la première version de la boîte partagée ». Ajoutez le décideur, la date visée et le problème utilisateur ou métier. Un nom de projet ne permet pas de savoir si le support répond à la bonne question.
Décrivez le problème avec une observation et une limite. Séparez besoin et solution : « les agents perdent le contexte quand une conversation change de file » est un problème ; « construire un service de routage » est une hypothèse. La première diapositive doit rester utile à une personne arrivée en retard : décision, recommandation, périmètre et risque ouvert. Le guide de présentation des résultats de recherche utilisateur montre comment relier les observations à une décision produit sans généraliser un petit échantillon qualitatif à l’ensemble des utilisateurs.
Rendre le périmètre explicite
Présentez trois niveaux : inclus, exclu et reporté. Les éléments inclus décrivent un comportement ou un résultat observable. Pour une boîte partagée, il peut s’agir d’affecter une conversation à une file, d’afficher son responsable et de tracer un transfert ; le routage automatique par sentiment ou une application mobile peuvent être exclus. Ce sont des exemples, pas des fonctionnalités promises.
Quand deux exigences se contredisent, montrez l’arbitrage. Une première version plus rapide peut ne prendre en charge qu’un fournisseur d’identité, tandis qu’une phase ultérieure en ajoute d’autres. Nommez la conséquence et la personne qui accepte le compromis.
Expliquer le plus petit flux utile
Choisissez un flux principal : déclencheur, choix importants et résultat attendu. Gardez les cas limites à part jusqu’à ce que le chemin principal soit compris. Pour chaque étape, montrez l’information nécessaire, l’action et le retour reçu. Signalez les politiques et services externes ; n’inventez pas des contrôles pour remplir un écran.
Signalez accessibilité et erreurs lorsqu’elles changent l’exigence : que se passe-t-il en cas de refus, de connexion indisponible ou de permission absente ? Un flux qui ne fonctionne que dans le cas idéal n’est pas une exigence complète.
Rendre l’acceptation vérifiable
Utilisez une forme observable : étant donné une condition, lorsqu’une action survient, alors un résultat est visible. Regroupez critères fonctionnels, qualité et préparation opérationnelle. Associez les critères à risque à une méthode de vérification : test automatisé, session d’utilisabilité, contrôle de sécurité, test de charge ou inspection manuelle. Cette méthode est le contrôle convenu, pas une preuve de succès futur.
Le guide PRD d’Atlassian explicite les hypothèses et les exclusions ; les comportements non tranchés doivent aussi rester visibles.
Dans l’exemple de boîte partagée, une conversation se trouve déjà dans la file Q. La première version doit permettre à un agent autorisé de se l’attribuer. Les critères suivants sont proposés pour un produit fictif : ils ne décrivent ni des fonctions de Presenti ni des tests terminés. Le routage automatique par sentiment et l’application mobile restent exclus, conformément à la diapositive de périmètre.
| Situation et action | Résultat observable ou décision ouverte | Méthode et rôle responsable |
|---|---|---|
| Une conversation de Q n’est pas attribuée ; un agent autorisé dans Q se l’attribue | L’agent apparaît comme responsable ; l’attribution persiste à la réouverture, et la trace de transfert identifie l’auteur de l’action et la conversation | QA utilise un compte autorisé, examine l’attribution enregistrée et la trace, puis transmet le résultat au responsable produit |
| Un agent sans autorisation pour Q tente la même attribution, y compris par une requête directe hors de l’interface habituelle | L’attribution est refusée ; le responsable et la trace de transfert restent inchangés, et la réponse ne révèle pas le contenu protégé de la conversation | Le responsable sécurité définit le test négatif ; QA teste l’interface et les requêtes, puis vérifie que l’état n’a pas changé |
| Deux agents autorisés voient la même conversation non attribuée et tentent de se l’attribuer presque simultanément | Règle à trancher : faut-il refuser l’attribution concurrente avec une invitation à actualiser, ou appliquer une autre règle convenue ? La dernière écriture ne constitue pas automatiquement le comportement approuvé | Le responsable produit et le responsable technique décident de la règle et du retour attendu avant que QA crée un test de concurrence reproductible |
Le scénario concurrent ne peut être accepté tant que son résultat attendu reste indéfini. Consignez la règle, son décideur et la date de revue dans le journal, puis actualisez le PRD et la diapositive ensemble. Masquer une commande ne prouve pas que les autorisations sont appliquées : le cas non autorisé doit aussi tester les requêtes directes. Conservez les résultats avec chaque critère, sans faire passer cette matrice proposée pour un rapport de test.
Associez chaque critère à une priorité et aux dépendances connues pour repérer les conditions qui déterminent l’acceptation.
Montrer dépendances et choix
Listez fournisseur d’identité, migration, contrôle juridique, composant du design system ou API d’une autre équipe avec responsable et état. Le calendrier ne doit montrer que les points d’intégration, de test et de décision utiles à la revue ; une estimation incertaine n’est pas un engagement. Pour les options, comparez temps d’apprentissage, réversibilité, risque utilisateur et maintenance, puis dites pourquoi une option est préférable.
Une dépendance ne bloque pas nécessairement le projet. Indiquez son statut, son responsable et la prochaine action ; sans responsable désigné, elle doit apparaître parmi les risques ou les décisions à prendre.
Terminer par une approbation enregistrable
Demandez une validation du périmètre, une validation sous conditions ou un retour pour une modification précise. Ajoutez un journal : approuvé, exclu, responsable et prochaine échéance. Si les preuves sont faibles, proposez une tâche de découverte ou un prototype avec un objectif d’apprentissage. Envoyez le support avec le PRD et une date de version afin de conserver ce qui était connu, choisi et non résolu. Les diapositives ne remplacent ni la spécification complète ni l’implémentation. Distinguez dans le journal les éléments confirmés en revue des exigences encore proposées.
