Générateur de PRD Plateforme

Utilisez cette compétence pour convertir des entrées brutes en exigences produit structurées et prêtes à être implémentées. Ne vous contentez pas de traduire. Comprenez, réorganisez, enrichissez et préservez le périmètre précis.

Modes Opératoires

Choisissez le mode le plus léger qui satisfait la demande :

Construction complète d'un PRD : créer un PRD complet pour une exigence complexe ou intersystèmes.
Construction d'une section : rédiger uniquement les sections demandées (contexte, périmètre, flux, modifications API/données, déploiement).
Réécriture / amélioration : améliorer la structure, la clarté, l'anglais ou la formulation bilingue sans modifier les décisions.
Normalisation d'entrée : convertir des notes éparses en décisions confirmées, hypothèses, décisions manquantes et langage lisible par l'ingénierie avant la rédaction.
Ajustement de gabarit : choisir le bon type d'artefact lorsque la demande n'est pas nécessairement un PRD complet.
Brouillon d'alignement directionnel : créer une version légère de concept/alignement avant de développer un PRD complet.

Premier Mouvement

Identifiez brièvement :

le scénario métier
la capacité de la plateforme
les systèmes impliqués
la phase actuelle et les exclusions
le type d'artefact : PRD complet, section de PRD, BRD une page, brouillon bilingue, réécriture anglaise, tableau ou description de flux

Si l'utilisateur demande uniquement un impact ou une faisabilité, ne rédigez pas encore le PRD ; utilisez d'abord une analyse d'impact.

Si le type d'artefact n'est pas clair, proposez l'artefact le plus petit et le plus utile et continuez, sauf si ce choix crée un risque de livraison.

Étape 0 : Détection de l'Étape

Avant de rédiger, classifiez l'étape de l'utilisateur :

Idée uniquement : créez d'abord un brouillon d'alignement directionnel.
Notes éparses : normalisez d'abord les décisions, hypothèses et décisions manquantes.
Périmètre non fixé : orientez vers platform-scope-checker avant de rédiger les exigences de la phase actuelle.
Prêt à rédiger : construisez le PRD ou la section demandé.
Brouillon existant : améliorez la structure ou orientez vers platform-prd-reviewer si l'utilisateur souhaite un retour.
Demande de détail RFC : conservez la sémantique produit dans le PRD et orientez les détails d'implémentation vers le suivi ingénierie.

Porte de Contestation de Construction

Avant de transformer une demande en un PRD lourd, contestez brièvement si le même objectif métier peut être atteint par :

une capacité existante de la plateforme
une configuration
un processus opérationnel ou une gestion manuelle temporaire
un changement de workflow plus petit
un déploiement progressif
un espace réservé de compatibilité sans comportement complet de la phase actuelle

Si la réponse n'est pas claire ou si le risque de construction est élevé, recommandez une vérification du périmètre avant de rédiger un PRD complet.

Livraison en Deux Phases

Pour les exigences ambiguës, de 0 à 1, ou intersystèmes de grande envergure, préférez deux phases :

Brouillon d'Alignement Directionnel : problème, utilisateurs/ops cibles, capacité plateforme, limites du périmètre, flux principal, propriété, hypothèses et décisions ouvertes.
PRD Détaillé : exigences par système, modifications champ/API/données, état/cas limites, déploiement/opérations, critères d'acceptation et risques.

Ne passez pas directement au PRD détaillé lorsque la direction produit principale, la limite MVP ou la source de vérité n'est pas encore fixée.

Quand NE PAS Utiliser

N'utilisez pas cette compétence comme premier mouvement lorsque :

le problème métier ou l'utilisateur cible est encore contesté ; clarifiez d'abord la direction avec platform-product-guide
la question est « Devrions-nous faire cela maintenant ? » ; utilisez d'abord platform-scope-checker
l'utilisateur ne souhaite qu'un retour sur un artefact existant ; utilisez platform-prd-reviewer
la demande est une pure RFC d'ingénierie, une conception de code ou un plan d'implémentation sans travail d'exigence produit

Normalisateur d'Entrée PM

Lorsque l'entrée est vague, non technique ou rédigée sous forme de notes éparses, traduisez-la d'abord en décisions produit lisibles par l'ingénierie avant de rédiger. N'exigez pas que l'utilisateur utilise un vocabulaire technique.

Utilisez cette sortie légère lorsque des décisions manquent :

Décisions Connues
- ...

Décisions Manquantes
- ...

Traduction Pertinente pour l'Ingénierie
- « Besoin d'un enregistrement d'approbation » signifie que les champs du journal d'audit, le moment de l'écriture, l'accès aux requêtes et la conservation nécessitent des décisions.
- « Notifier un autre système » signifie que le moment du callback, la relance, le délai d'attente, la gestion des échecs et la cohérence des statuts nécessitent des décisions.

Posez des questions en langage métier plutôt que des questions techniques :

Au lieu de « Quelle est la clé d'idempotence ? », demandez « Si la même demande est soumise deux fois, le système doit-il créer un nouvel enregistrement, le rejeter ou retourner l'enregistrement existant ? »
Au lieu de « Quelle est la stratégie de relance du callback ? », demandez « Si le système destinataire ne peut pas être notifié, que doivent voir les utilisateurs, qui le corrige et combien de temps cela peut-il rester non résolu ? »
Au lieu de « Qui est la source de vérité ? », demandez « Si deux systèmes affichent des statuts différents, lequel doit être considéré comme fiable ? »
Au lieu de « Quelle est la stratégie de compatibilité ? », demandez « Les enregistrements existants ou les processus en cours seront-ils affectés après le lancement ? »
Au lieu de « Définissez une machine d'état », demandez « Quels statuts cette demande peut-elle avoir de la création à l'achèvement, et quelles actions sont autorisées dans chaque statut ? »

Registre des Hypothèses et Preuves

Lorsque des décisions importantes sont déduites de notes approximatives, exposez-les avant de finaliser :

Hypothèses
- A1 : ...

Preuve / Source
- E1 : Note utilisateur / prototype / PRD antérieur / note de réunion / instruction explicite

Nécessite Confirmation
- C1 : ...

Ne transformez pas silencieusement des hypothèses en exigences. Si l'utilisateur demande de continuer, conservez les éléments non résolus dans les Questions Ouvertes avec le propriétaire/dépendance lorsque cela est connu.

Sélection du Gabarit

Choisissez le gabarit en fonction du type d'artefact plutôt que d'imposer une structure lourde.

PRD de fonctionnalité courte :

Contexte
Objectif
Périmètre
Exigences
Modifications API / Données
Cas limites
Pièce jointe / Liens

Note de modification API / champ :

Contexte
Contrat modifié
Tableau des champs
Validation / Comportement par défaut
Rétrocompatibilité
Consommateurs en aval
Exemples

PRD d'interface utilisateur de configuration :

Contexte
Objectif
Chemin de page / Point d'entrée
Champs de liste
Comportement de filtre / requête
Comportement de création / édition
Règles de validation
Autorisation / Audit
Pièce jointe / Prototype

PRD de migration :

Contexte
Périmètre
Systèmes source / cible
Flux de migration
Correspondance des données
Validation / Liste de vérification de rapprochement
Basculement / Retour arrière
Questions Ouvertes

PRD de logique de formule / règle :

Contexte
Format de la règle
Définitions des champs
Logique de traitement
Exemples
Cas limites
Rétrocompatibilité

Structure par Défaut du PRD

Utilisez cette structure sauf si l'utilisateur donne un gabarit différent :

Contexte
Objectif
Périmètre
Acteurs / Systèmes
Flux Global
Détails du Flux
Exigences par Système
Modifications API / Données
Scénarios et Cas Limites
Déploiement / Opérations
Questions Ouvertes
Dépendances / Risques

Pour les courtes sections, conservez uniquement les en-têtes pertinents mais préservez le même ordre de réflexion.

Utilisez le Modélisateur de Flux Plateforme Lorsque

Utilisez platform-flow-modeler avant de rédiger les sections Flux Global, Détails du Flux, Scénarios et Cas Limites, Transition d'État, ou Opérations lorsque l'exigence implique 3 systèmes ou plus, des changements de cycle de vie/statut, callback/relance/délai d'attente, retour arrière/annulation/resoumission, rapprochement, règlement, migration, ou repli manuel.

Laissez-le d'abord structurer les tableaux de flux, puis convertissez ces tableaux en prose de PRD, exigences par système, scénarios, critères d'acceptation et questions ouvertes.

Contrat de Sortie

Chaque sortie de type PRD doit rendre ces éléments testables :

Problème et « pourquoi maintenant »
Objectif de la phase actuelle
Limites du périmètre
Flux principal et flux d'exception clés
Décisions produit encore ouvertes
Critères d'acceptation ou matrice de scénarios
Propriétaire/source de vérité pour le comportement intersystèmes
Déploiement, retour arrière, ou gestion manuelle temporaire lorsque pertinent

Forme par défaut de la réponse :

Brève note sur le type d'artefact sélectionné, lorsque utile
Contenu du PRD rédigé ou section demandée
Hypothèses et décisions ouvertes, le cas échéant
Prochaine étape de révision suggérée : vérification de périmètre, relecture de PRD, suivi RFC, ou confirmation des parties prenantes

Cette compétence doit produire un artefact, pas seulement des conseils. Si l'artefact ne peut pas être produit en toute sécurité, fournissez le registre des décisions manquantes et la prochaine action à la place.

Pour les gabarits de PRD détaillés et les contrats de sortie spécifiques aux artefacts, lisez references/prd-output-contract.md lorsque la tâche implique un PRD complet, un PRD plateforme de 0 à 1, un PRD de migration, un PRD d'interface utilisateur de configuration, ou une note de modification API/données.

Scénarios et Critères d'Acceptation

Pour les sections Scénarios et Cas Limites, utilisez des critères d'acceptation Given/Quand/Alors lorsque cela améliore l'alignement QA et ingénierie :

**Scénario : [nom]**
- Given : [précondition : état du système, acteur, données, configuration]
- Quand : [action déclencheur]
- Alors : [résultat attendu : statut final, résultat visible utilisateur/ops, synchronisation en aval, enregistrement d'audit]

Couvrez ces types de scénarios lorsque pertinents :

Parcours heureux
Échec de validation : champ manquant, valeur invalide, soumission en double
Échec du système en aval : délai d'attente du callback, erreur API, échec partiel
Soumission concurrente ou en double
Cas limite de transition d'état : resoumission depuis un état terminal, annulation en cours de flux
Retour arrière ou inversion
Repli manuel : intervention ops ou entrée dans la file d'attente d'exception
Limite d'autorisation : acteur non autorisé ou divergence du système source

Rendez chaque clause Alors testable. Nommez le statut final, le résultat visible utilisateur/ops, si les systèmes en aval sont notifiés, et si un enregistrement d'audit/événement est créé.

Si la matrice de scénarios est volumineuse, utilisez un tableau compact :

Scénario	Précondition	Déclencheur	Statut Final	Résultat Utilisateur/Ops	Aval	Audit

Style de Tableau API / Données

Pour les modifications API ou données, utilisez par défaut des tableaux avec :

Champ
Type de Données / Type
Obligatoire
Valeur / Validation
Description
Exemple
Type de Changement : nouveau / existant / supprimé, lorsque pertinent
Propriétaire / Consommateur, lorsque la propriété est importante

Ajouts pour PRD Plateforme de 0 à 1

Pour les nouvelles capacités plateforme/infrastructure, ajoutez :

direction de la plateforme et principes de conception
objets de configuration vs objets d'exécution
tableau de propriété/source de vérité
cycle de vie / machine d'état
comportement de versionnage et d'instantané
comportement de callback, relance, délai d'attente et idempotence
journalisation d'audit/événement
autorisation et isolation du système source
exclusions MVP et itération future
modèle UI/espace de travail par rôle, périmètre de données et région opérationnelle

Règles de Rédaction

Convertissez les notes approximatives en anglais professionnel lorsque la sortie en anglais est demandée.
Préservez la terminologie mixte chinois/anglais lorsqu'elle reflète les vrais noms de systèmes ou artefacts d'équipe.
Ajoutez les explications manquantes nécessaires à la compréhension et à l'implémentation, mais n'inventez pas de décisions métier.
Si la qualité de l'entrée est inégale, normalisez-la en couche métier et couche de collaboration ingénierie avant de rédiger le PRD final.
Utilisez une hiérarchie numérotée pour la relecture.
Utilisez des tableaux pour les champs, API, propriété, scénarios, calculs, transitions d'état et questions ouvertes.
Séparez les exigences par système lorsque plusieurs systèmes changent.
Gardez les sections lisibles par le produit ; déplacez les détails de bas niveau dans les sections API/données ou questions ouvertes.
Suivez les prototypes fournis ou la structure de PRD existante lorsque l'utilisateur demande de s'en inspirer.

Discipline de Périmètre

Séparez toujours :

Dans le Périmètre
Hors du Périmètre
Non Pris en Charge dans Cette Phase
Itération Future

N'incluez pas de fonctionnalités de phase future dans les exigences de la phase actuelle, sauf en tant qu'exclusions explicites, notes de compatibilité, ou itération future.

Exigences de Flux et de Données

Pour le travail intersystèmes :

décrivez les flux de création/interrogation/callback/mise à jour/règlement/rapprochement séparément lorsque pertinent
identifiez les points de persistance et les changements de statut
définissez les champs de temps de configuration séparément des champs de temps d'exécution
distinguez les champs d'instantané des champs résolus dynamiquement
utilisez les noms de champs avec soin ; la dénomination singulière/plurielle peut coder le périmètre, comme portalCode vs portalCodes

Garde-fous

Traitez les PRD historiques comme du matériel de référence/apprentissage sauf si l'utilisateur demande de les réécrire.
N'injectez pas de contexte non lié de projets précédents.
Ne produisez pas de code lorsque l'utilisateur demande des exigences.
Ne polissez pas excessivement en langage marketing.
Ne cachez pas les décisions ouvertes ; listez-les clairement avec le propriétaire/dépendance lorsque connu.

Erreurs Courantes à Signaler

Rédiger des exigences détaillées avant que l'alignement directionnel soit prêt.
Transformer des hypothèses en exigences sans les étiqueter.
Mélanger le MVP actuel avec le comportement de l'itération future.
Rédiger uniquement le comportement de la page/bouton tout en laissant les états, la propriété et la gestion des exceptions implicites.
Sur-prescrire la conception de la base de données, de la file d'attente, du job de relance ou du service dans le PRD.
Considérer une demande d'implémentation comme prête pour le produit sans vérifier l'objectif métier et les limites du périmètre.

Routage

Orientez vers platform-product-guide lorsque la direction métier, l'abstraction de la plateforme ou le cadrage des décisions n'est pas prêt.
Orientez les sections lourdes en flux vers platform-flow-modeler avant de les convertir en contenu PRD.
Orientez vers platform-scope-checker lorsque l'inclusion de la phase actuelle, la taille du MVP ou la complexité cachée n'est pas résolue.
Orientez vers platform-prd-reviewer après la rédaction lorsque l'utilisateur souhaite une évaluation de la maturité, des lacunes ou un score.
Orientez les questions d'implémentation de niveau RFC vers le suivi ingénierie tout en conservant la sémantique produit dans le PRD.

Liste de Vérification Qualité

Avant de finaliser, vérifiez :

Le document explique quoi construire et pourquoi.
Le périmètre est explicite : dans le périmètre, hors périmètre, non pris en charge maintenant, futur.
Les exigences sont suffisamment testables pour une révision QA ou ingénierie.
La propriété intersystèmes et la source de vérité sont visibles.
Les hypothèses sont séparées des décisions confirmées.
Les considérations techniques sont exposées sans sur-prescrire l'implémentation.
La prochaine étape ou révision est explicite.

Références

references/prd-output-contract.md : à charger lorsque un gabarit détaillé, un contrat spécifique à un artefact ou une liste de vérification qualité est nécessaire.

lyndong/compétences-produit-plateforme

Qu'est-ce que compétences-produit-plateforme ?

Demander à votre IA préférée

Documentation