Écrire une spécification

Si vous voyez des placeholders non familiers ou devez vérifier quels outils sont connectés, consultez CONNECTORS.md.

Rédigez une spécification de fonctionnalité ou un document de requirements produit (PRD).

Utilisation

/write-spec $ARGUMENTS

Flux de travail

1. Comprendre la fonctionnalité

Demandez à l'utilisateur ce qu'il souhaite spécifier. Acceptez l'un des éléments suivants :

Un nom de fonctionnalité (« Support SSO »)
Une déclaration de problème (« Les clients d'entreprise demandent sans cesse une authentification centralisée »)
Une demande utilisateur (« Les utilisateurs veulent exporter leurs données en CSV »)
Une idée vague (« Nous devrions faire quelque chose à propos de la baisse des abandons lors de l'onboarding »)

2. Recueillir le contexte

Demandez à l'utilisateur les informations suivantes. Soyez conversationnel — ne posez pas toutes les questions à la fois. Posez d'abord les questions les plus importantes et combler les lacunes au fur et à mesure :

Problème utilisateur : Quel problème cela résout-il ? Qui l'éprouve ?
Utilisateurs cibles : Quel(s) segment(s) d'utilisateurs cela concerne-t-il ?
Métriques de succès : Comment saurons-nous que cela a fonctionné ?
Contraintes : Contraintes techniques, chronologie, exigences réglementaires, dépendances
Antécédents : Cela a-t-il été tenté auparavant ? Y a-t-il des solutions existantes ?

3. Récupérer le contexte des outils connectés

Si ~~gestionnaire de projets est connecté :

Recherchez les tickets, épics ou fonctionnalités associés
Extrayez les requirements ou critères d'acceptation existants
Identifiez les dépendances sur d'autres éléments de travail

Si ~~base de connaissances est connectée :

Recherchez les documents de recherche, spécifications antérieures ou documents de conception connexes
Extrayez les découvertes pertinentes de la recherche utilisateur
Trouvez les notes de réunion ou dossiers de décision connexes

Si ~~conception est connectée :

Extrayez les maquettes, wireframes ou explorations de conception connexes
Recherchez les composants du système de conception pertinents pour la fonctionnalité

Si ces outils ne sont pas connectés, travaillez entièrement à partir de ce que l'utilisateur fournit. Ne demandez pas à l'utilisateur de connecter des outils — procédez simplement avec les informations disponibles.

4. Générer le PRD

Produisez un PRD structuré avec ces sections. Consultez Structure du PRD ci-dessous pour un guide détaillé sur ce que chaque section doit contenir.

Déclaration du problème : Le problème utilisateur, qui est affecté et l'impact de ne pas le résoudre (2-3 phrases)
Objectifs : 3-5 résultats spécifiques et mesurables liés aux métriques utilisateur ou commerciales
Hors-objectifs : 3-5 choses explicitement hors périmètre, avec une brève justification pour chacune
Histoires utilisateur : Format standard (« En tant que [type d'utilisateur], je veux [capacité] afin que [bénéfice] »), groupées par persona
Requirements : Catégorisés comme Obligatoire (P0), À avoir (P1) et Considérations futures (P2), chacun avec des critères d'acceptation
Métriques de succès : Indicateurs avancés (changent rapidement) et indicateurs retardés (changent au fil du temps), avec cibles spécifiques
Questions ouvertes : Questions non résolues étiquetées avec qui doit y répondre (ingénierie, conception, juridique, données)
Considérations relatives à la chronologie : Dates limite fermes, dépendances et phases

5. Examiner et itérer

Après avoir généré le PRD :

Demandez à l'utilisateur si des sections ont besoin d'ajustements
Proposez d'étendre des sections spécifiques
Proposez de créer des artefacts de suivi (brief de conception, répartition des tickets d'ingénierie, pitch pour les parties prenantes)

Structure du PRD

Déclaration du problème

Décrivez le problème utilisateur en 2-3 phrases
Qui éprouve ce problème et à quelle fréquence
Quel est le coût de ne pas le résoudre (douleur utilisateur, impact commercial, risque concurrentiel)
Ancrez ceci dans des preuves : recherche utilisateur, données de support, métriques ou retours clients

Objectifs

3-5 résultats spécifiques et mesurables que cette fonctionnalité doit atteindre
Chaque objectif doit répondre : « Comment saurons-nous que cela a réussi ? »
Distinguez les objectifs utilisateur (ce que les utilisateurs obtiennent) des objectifs commerciaux (ce que l'entreprise obtient)
Les objectifs doivent être des résultats, non des livrables (« réduire le temps jusqu'à la première valeur de 50 % » et non « créer un assistant onboarding »)

Hors-objectifs

3-5 choses que cette fonctionnalité ne fera EXPLICITEMENT pas
Capacités adjacentes qui sont hors du périmètre pour cette version
Pour chaque hors-objectif, expliquez brièvement pourquoi c'est hors du périmètre (impact insuffisant, trop complexe, initiative distincte, prématuré)
Les hors-objectifs préviennent le scope creep lors de l'implémentation et définissent les attentes avec les parties prenantes

Histoires utilisateur

Rédigez les histoires utilisateur dans le format standard : « En tant que [type d'utilisateur], je veux [capacité] afin que [bénéfice] »

Directives :

Le type d'utilisateur doit être assez spécifique pour être significatif (« administrateur d'entreprise » et non juste « utilisateur »)
La capacité doit décrire ce qu'ils veulent accomplir, non comment
Le bénéfice doit expliquer le « pourquoi » — quelle valeur cela apporte-t-il
Incluez les cas limites : états d'erreur, états vides, conditions aux limites
Incluez différents types d'utilisateurs si la fonctionnalité sert plusieurs personas
Classez par priorité — les histoires les plus importantes d'abord

Exemple :

« En tant qu'administrateur d'équipe, je veux configurer SSO pour mon organisation afin que les membres de mon équipe puissent se connecter avec leurs identifiants d'entreprise »
« En tant que membre d'équipe, je veux être automatiquement redirigé vers la connexion SSO de mon entreprise afin que je n'aie pas besoin de mémoriser un mot de passe distinct »
« En tant qu'administrateur d'équipe, je veux voir quels membres se sont connectés via SSO afin que je puisse vérifier que le déploiement fonctionne »

Requirements

Obligatoire (P0) : La fonctionnalité ne peut pas être livrée sans celles-ci. Ces éléments représentent la version minimale viable de la fonctionnalité. Posez-vous la question : « Si nous supprimons ceci, la fonctionnalité résout-elle toujours le problème fondamental ? » Si non, c'est du P0.

À avoir (P1) : Améliore significativement l'expérience mais le cas d'usage fondamental fonctionne sans elles. Celles-ci deviennent souvent des suites rapides après le lancement.

Considérations futures (P2) : Explicitement hors du périmètre pour la v1 mais nous voulons concevoir d'une manière qui les soutient plus tard. Documenter celles-ci prévient les décisions architecturales accidentelles qui les rendent difficiles plus tard.

Pour chaque requirement :

Rédigez une description claire et sans ambiguïté du comportement attendu
Incluez les critères d'acceptation (voir ci-dessous)
Notez les considérations techniques ou contraintes
Signalez les dépendances sur d'autres équipes ou systèmes

Questions ouvertes

Questions qui doivent obtenir des réponses avant ou pendant l'implémentation
Étiquetez chacune avec qui doit y répondre (ingénierie, conception, juridique, données, parties prenantes)
Distinguez les questions bloquantes (doivent être répondues avant de commencer) et les non-bloquantes (peuvent être résolues lors de l'implémentation)

Considérations relatives à la chronologie

Dates limite fermes (engagements contractuels, événements, dates de conformité)
Dépendances sur le travail ou les versions d'autres équipes
Phases suggérées si la fonctionnalité est trop importante pour une seule version

Rédaction d'histoires utilisateur

Les bonnes histoires utilisateur sont :

Indépendantes : Peuvent être développées et livrées seules
Négociables : Les détails peuvent être discutés, l'histoire n'est pas un contrat
Précieuses : Apportent de la valeur à l'utilisateur (non seulement à l'équipe)
Estimables : L'équipe peut estimer grossièrement l'effort
Petites : Peuvent être complétées en un sprint/itération
Testables : Il existe un moyen clair de vérifier que cela fonctionne

Erreurs courantes dans les histoires utilisateur

Trop vague : « En tant qu'utilisateur, je veux que le produit soit plus rapide » — qu'est-ce qui devrait être spécifiquement plus rapide ?
Solution prescriptive : « En tant qu'utilisateur, je veux un menu déroulant » — décrivez le besoin, non le widget UI
Aucun bénéfice : « En tant qu'utilisateur, je veux cliquer sur un bouton » — pourquoi ? Qu'est-ce que cela accomplish ?
Trop grande : « En tant qu'utilisateur, je veux gérer mon équipe » — divisez cela en capacités spécifiques
Orientation interne : « En tant qu'équipe d'ingénierie, nous voulons refactoriser la base de données » — ceci est une tâche, non une histoire utilisateur

Catégorisation des requirements

Framework MoSCoW

Doit avoir : Sans ceux-ci, la fonctionnalité n'est pas viable. Non négociable.
Devrait avoir : Important mais non critique pour le lancement. Suites rapides de haute priorité.
Pourrait avoir : Souhaitable si le temps le permet. Ne retardera pas la livraison s'il est supprimé.
N'aura pas (cette fois) : Explicitement hors du périmètre. Peut être revisité dans les futures versions.

Conseils pour la catégorisation

Soyez impitoyable avec les P0. Plus la liste des must-have est serrée, plus vite vous livrez et apprenez.
Si tout est P0, rien n'est P0. Challengez chaque must-have : « Ne livrerions-nous vraiment pas sans ceci ? »
Les P1 doivent être des choses que vous êtes confiant de construire bientôt, non une liste de souhaits.
Les P2 sont une assurance architecturale — ils guident les décisions de conception même si vous ne les construisez pas maintenant.

Définition des métriques de succès

Indicateurs avancés

Métriques qui changent rapidement après le lancement (jours à semaines) :

Taux d'adoption : % des utilisateurs éligibles qui essaient la fonctionnalité
Taux d'activation : % des utilisateurs qui complètent l'action fondamentale
Taux de complétion des tâches : % des utilisateurs qui accomplissent avec succès leur objectif
Temps pour compléter : Combien de temps le flux de travail fondamental prend
Taux d'erreur : À quelle fréquence les utilisateurs rencontrent des erreurs ou des impasses
Fréquence d'utilisation de la fonctionnalité : À quelle fréquence les utilisateurs reviennent pour utiliser la fonctionnalité

Indicateurs retardés

Métriques qui prennent du temps à se développer (semaines à mois) :

Impact de rétention : Cette fonctionnalité améliore-t-elle la rétention des utilisateurs ?
Impact sur le revenu : Cela stimule-t-il les mises à niveau, l'expansion ou un nouveau revenu ?
Changement NPS / satisfaction : Cela améliore-t-il la perception des utilisateurs du produit ?
Réduction des tickets de support : Cela réduit-il la charge de support ?
Taux de victoire concurrentielle : Cela aide-t-il à remporter plus de contrats ?

Définir des cibles

Les cibles doivent être spécifiques : « 50 % d'adoption dans 30 jours » et non « adoption élevée »
Basez les cibles sur des fonctionnalités comparables, des points de référence du secteur ou des hypothèses explicites
Définissez un seuil de « succès » et une cible « stretch »
Définissez la méthode de mesure : quel outil, quelle requête, quelle fenêtre de temps
Spécifiez quand vous évaluerez : 1 semaine, 1 mois, 1 trimestre après le lancement

Critères d'acceptation

Rédigez les critères d'acceptation au format Given/When/Then ou sous forme de checklist :

Given/When/Then :

Étant donné [précondition ou contexte]
Quand [action que l'utilisateur entreprend]
Alors [résultat attendu]