Donnez à cinq parties prenantes un PRD clair, éclairé par plusieurs perspectives rédactionnelles

Fixez le périmètre avant d'améliorer la phrase

Rédigez la décision actuelle en termes simples : qui a besoin de quel résultat, quelles conditions s'appliquent, ce qui est hors périmètre et quelles questions restent sans réponse. Marquez une décision proposée différemment d’une décision approuvée. Sinon, une réécriture élégante peut tranquillement transformer une suggestion en une exigence.

Atlassian décrit un PRD comme une description commune de l’objectif du produit, de ses fonctionnalités, des besoins des utilisateurs et des critères de réussite. Utilisez cet objectif commun comme contrainte sur la variation de l’IA. Les explications spécifiques aux parties prenantes doivent mettre en lumière la même exigence, et non créer cinq versions du produit qui ne peuvent pas toutes être livrées.

Une exigence fictive qui invite aux bonnes questions

Considérez un produit de reporting fictif avec ce brouillon : les utilisateurs devraient pouvoir exporter facilement des rapports. La portée approuvée est plus étroite : les propriétaires d'espace de travail peuvent exporter la table actuellement filtrée sous forme de fichier CSV UTF-8. Les exportations programmées sont exclues. Les limites de taille de fichier, les résultats vides et le comportement en cas d'échec restent à décider. Il s'agit d'exigences illustratives, et non de fonctionnalités de Colay.

Une déclaration de base plus claire est la suivante : un propriétaire d'espace de travail peut exporter les lignes correspondant aux filtres de table actifs sous forme de fichier CSV UTF-8. Mettez les exclusions et les questions sans réponse à côté. Ne laissez pas un modèle remplacer la décision de performance manquante par une durée inventée.

Demandez huit perspectives, puis consolidez-les

Utilisez les agents disponibles sélectionnés dans Ask separately pour inspecter leurs interprétations initiales. Les huit perspectives demandées ne nécessitent pas huit modèles indépendants. Gardez tout désaccord qui laisse présager un véritable choix de produit. Par exemple, le fait qu'un tableau vide produise ou non un fichier contenant uniquement un en-tête est une décision qui appartient à l'équipe et non une préférence stylistique de faire une moyenne.

Relisez cet extrait du PRD : [texte]. Décisions approuvées : [faits]. Propositions : [pas encore approuvées]. Hors périmètre : [liste]. Questions ouvertes : [liste]. Produisez huit formulations mettant l'accent sur les résultats utilisateur, la portée concise, la testabilité, les autorisations, le comportement en cas d'échec, les performances, les besoins d'assistance et le contexte exécutif. Chaque version doit conserver la même portée approuvée. N’inventez pas de limites techniques et ne résolvez pas les questions ouvertes en silence. Pour chaque version, identifiez une ambiguïté qu’elle expose. Proposez ensuite une exigence canonique, des exemples de cas d'acceptation et une liste de décisions avec les responsables suggérés. Marquez chaque nouvelle suggestion comme une proposition.

Construisez le dossier de révision autour d'une exigence

Pour l'exigence d'exportation fictive, un cas de test approuvé peut vérifier qu'un propriétaire reçoit un CSV contenant des lignes correspondant aux filtres actifs. L'interface attendue par un non-propriétaire et une réponse à résultat vide restent des questions à moins que l'équipe ne les ait décidées. Cette distinction empêche qu'une liste de tests générée par l'IA ne devienne une portée accidentelle.

1. Choisissez une formulation de base et comparez-la avec la liste de décisions approuvée. Vérifiez les rôles, les conditions, les résultats et les exclusions mot par mot.
2. Ajoutez des exemples de cas d'acceptation pour les décisions déjà prises. Étiquetez les cas impliquant un comportement non résolu comme des questions plutôt que comme des tests convenus.
3. Séparez les modifications de formulation des propositions de portée. Une nouvelle limite de lignes, une règle d'autorisation ou un chemin de récupération nécessite une décision de produit même lorsque la phrase est meilleure.
4. Envoyez aux réviseurs le texte canonique, les modifications significatives et les questions ouvertes et leurs responsables via votre processus de révision existant.

Utilisez le raccourci macOS pour une passe de formulation ciblée

Gardez le PRD ouvert et invoquez Colay avec ⌘⇧K par défaut, ou votre raccourci configuré dans Paramètres. Collez uniquement l'extrait et le contexte autorisé nécessaires à la révision. La superposition ouvre un espace de travail de rédaction ; elle ne lit pas automatiquement le document et ne soumet pas le PRD pour approbation.

Après l'examen, enregistrez les commentaires qui ont modifié le libellé et ceux qui ont modifié la décision relative au produit. Mettez à jour ensemble l’exigence canonique et ses exemples. Réutilisez l'invite sur un paragraphe difficile si nécessaire, plutôt que de réécrire à plusieurs reprises l'intégralité du PRD. Un résultat utile est un ensemble plus petit et plus clair de décisions réelles que l'équipe doit prendre.

Questions, réponses