Prompt pour document d'exigences produit (PRD)

Quand l'utiliser

Utilisez ce prompt lorsque vous devez concevoir un premier PRD pour une fonctionnalité au périmètre défini et que vous souhaitez obtenir une base technique et opérationnelle solide plutôt qu'un plan abstrait. Remplacez les éléments par vos propres données produit, contraintes système et métriques d'équipe avant de le présenter aux équipes d'ingénierie.

Le prompt

## Rôle
Agis en tant que Product Manager senior. Applique une approche d'analyse systémique structurée et fais preuve de clarté technique, tout en veillant à ce que la documentation reste accessible aux équipes transverses.

## Contexte
BeaconHR est une plateforme interne d'opérations destinée aux cliniques et établissements de santé de taille moyenne. Les gestionnaires d'équipes coordonnent actuellement les échanges de gardes d'urgence entre infirmiers par téléphone et sur des tableaux blancs physiques, ce qui entraîne des doublons de planning et des retards dans la prise en charge. BeaconHR intègre un nouveau module mobile d'« Échange de gardes » (Shift Swap Requests). La sortie cible est prévue pour le deuxième trimestre auprès d'un groupe pilote de 12 cliniques régionales.

## Objectif
Rédige un PRD complet décrivant le workflow de bout en bout pour une demande d'échange de garde de pair à pair, l'étape de validation par un responsable, et la mise à jour du journal d'audit.

## Public cible
Les lecteurs principaux sont les ingénieurs logiciels, les designers UI/UX et les responsables des opérations cliniques. Fournis une logique claire, sans ambiguïté, et des critères d'acceptation exploitables, sans théorie superflue.

## Exigences
Inclus : l'énoncé du problème ; les personas utilisateurs (Personnel demandeur, Personnel acceptant, Superviseur de la clinique) ; les user stories avec des critères d'acceptation explicites ; les spécifications fonctionnelles couvrant l'initiation de la demande, l'acceptation par le collègue et la validation par le superviseur ; la gestion des erreurs et les cas limites (ex. : chevauchement de gardes, demandes expirées) ; ainsi qu'un tableau de métriques mesurant l'adoption de la fonctionnalité et le délai de traitement des échanges.

## Contraintes
Limite strictement le périmètre aux échanges de gardes individuels (1:1) au sein d'un même site clinique et pour une même classification de poste. N'inclus pas de régénération automatique des plannings, d'intégration avec la paie, de transferts entre différents sites, ni de passerelles de notifications SMS externes. Travaille exclusivement avec le scénario indiqué. Identifie explicitement toutes les hypothèses fonctionnelles.

## Ton & style
Sois concis, rigoureux et fonctionnel. Utilise un langage clair et sans ambiguïté (ex. : « doit », « devrait ») et des tableaux markdown structurés pour les états et les cas limites. Évite le jargon d'entreprise et les généralités vagues.

## Format de sortie
Fournis le PRD directement sous les en-têtes standard de documentation produit. Regroupe les hypothèses architecturales et les questions ouvertes non résolues dans une section distincte à la fin. Conclus par une checklist des dépendances requises pour la validation technique et de conformité.

## Ce qu'il faut éviter
Ne présume pas de fonctionnalités d'API non mentionnées ou d'outils tiers externes. Évite de mélanger les exigences fonctionnelles avec les spécifications de design visuel. N'omets aucun état d'erreur ni cas limite.

## Critères de réussite
Un responsable technique (lead dev) doit pouvoir évaluer l'effort technique et un ingénieur QA doit pouvoir déduire des cas de test directement à partir des exigences, sans avoir besoin d'éclaircir les règles métier fondamentales.

## Questions de clarification
Pose au maximum trois questions ciblées, uniquement si une ambiguïté bloque fondamentalement la rédaction des exigences. Dans le cas contraire, poursuis en posant des hypothèses opérationnelles raisonnables, clairement signalées comme des éléments à faire valider par les parties prenantes.

Pourquoi cela fonctionne

• Le scénario fournit au modèle des contraintes métier concrètes et des rôles d'utilisateurs précis, plutôt qu'une idée vague de fonctionnalité.
• Les exigences imposent de détailler les cas limites fonctionnels, les critères d'acceptation et les états d'erreur explicites, souvent oubliés lors des premières ébauches.
• Les contraintes éliminent explicitement toute dérive du périmètre (scope creep), comme les algorithmes de planification automatique ou les passerelles de paie externes.
• Les critères de réussite orientent la sortie vers l'exploitabilité technique et la testabilité, plutôt que vers une exhaustivité purement superficielle.

Adaptez-le à vos besoins

Créez une version sur mesure avec PromptDeck en remplaçant le scénario fictif par votre propre contexte, votre public cible et vos contraintes. Conservez les étapes de vérification pour que le résultat final reflète précisément vos connaissances réelles.