wwas

Présentation de wwas

wwas est un skill de prompt pour rédiger des items de backlog produit au format Why-What-Acceptance. Utilisez le skill wwas quand vous avez besoin d’un item de backlog qui ne se contente pas de résumer une fonctionnalité : il doit expliquer la raison métier, décrire clairement le changement et définir des critères d’acceptation testables par l’équipe.

Ce skill convient particulièrement bien aux product managers, analystes, designers et agents IA qui doivent transformer des idées de fonctionnalités approximatives en éléments de travail prêts pour le sprint. L’objectif réel est de préserver le contexte stratégique tout en gardant des items indépendants, utiles et négociables. Le skill wwas est surtout pertinent quand vous voulez une formulation de backlog cohérente à l’échelle d’une équipe, sans sur-spécifier l’implémentation.

Ce que wwas fait le mieux

wwas est particulièrement adapté au découpage de fonctionnalités, à la livraison produit incrémentale et à la planification transverse, quand l’équipe a besoin de clarté sur l’intention avant le code. Il aide aussi lorsque vos entrées de départ sont désordonnées, comme une note de réunion, un lien Figma ou une demande encore à moitié formalisée.

En quoi wwas est différent

Par rapport à un prompt générique, wwas pousse le modèle à séparer le Why, le What et les Acceptance Criteria. Cela réduit les tickets flous, limite le périmètre et rend la sortie plus simple à relire en phase de planification. Le skill encourage aussi des items que l’on peut prioriser, estimer et tester sans transformer le prompt en spécification complète.

Quand installer wwas

Installez wwas si votre flux de travail dépend de la propreté du backlog, d’une qualité de tickets répétable ou d’une planification des exigences assistée par IA. Il est le plus utile quand votre équipe a besoin d’un format partagé pour la Requirements Planning, plutôt que d’une génération de prose ponctuelle.

Comment utiliser le skill wwas

Installer wwas et retrouver les fichiers source

Installez le skill avec npx skills add phuryn/pm-skills --skill wwas. Lisez ensuite SKILL.md en premier, car il contient le workflow, le modèle d’item et la liste d’arguments qui structurent l’usage de wwas. Si vous l’adaptez à votre propre processus, inspectez aussi le répertoire de skills plus large pour repérer d’éventuelles conventions partagées avec les skills adjacents.

Ce qu’il faut fournir à wwas

wwas fonctionne mieux avec quatre entrées : le nom du produit ou du système, la fonctionnalité ou capacité, un lien de design si vous en avez un, et les hypothèses ou le contexte stratégique. Des entrées faibles comme « améliorer l’onboarding » produisent généralement des critères d’acceptation vagues. Des entrées solides ressemblent plutôt à ceci : nom du produit, utilisateur cible, résultat attendu et contraintes.

Comment écrire un meilleur prompt

Un bon prompt wwas nomme l’unité de livraison et la raison métier. Par exemple : « Crée un item WWA pour le parcours de paiement mobile. Why : réduire l’abandon de panier chez les utilisateurs récurrents. What : ajouter la sélection d’un moyen de paiement enregistré, en utilisant le lien Figma. Hypothèses : utilisateurs authentifiés uniquement, pas de nouveau fournisseur de paiement. » Cela donne au skill assez de contexte pour produire un item de backlog exploitable, et pas seulement un paragraphe proprement rédigé.

Flux de travail concret pour la Requirements Planning

Utilisez wwas une fois que vous avez une orientation fonctionnelle, mais avant la spécification détaillée. D’abord, rassemblez la demande brute et les notes de design ou de discovery disponibles. Ensuite, lancez wwas pour produire la structure Why-What-Acceptance. Puis relisez l’item sous l’angle de l’indépendance, de la taille du périmètre et de la testabilité. Si l’item mélange encore plusieurs résultats, découpez-le et relancez wwas sur l’unité plus petite.

FAQ du skill wwas

wwas est-il réservé aux product managers ?

Non. Le skill wwas est utile à toute personne qui a besoin d’une sortie de Requirements Planning exploitable par l’ingénierie et le design : PM, business analysts, fondateurs, responsables delivery et workflows de documentation assistés par IA.

En quoi wwas diffère-t-il d’un prompt normal ?

Un prompt classique peut produire une note descriptive de fonctionnalité. wwas est plus cadré : il impose une structure d’item de backlog avec contexte stratégique, description concise de la fonctionnalité et critères d’acceptation observables. Cela réduit généralement le travail de reprise après génération.

Faut-il des fichiers de design pour utiliser wwas ?

Non, mais les liens de design améliorent la précision. Si vous n’en avez pas, fournissez suffisamment de contexte pour définir le besoin utilisateur, les limites du travail et le comportement attendu. Sans cela, le skill peut produire des items trop larges.

Quand ne faut-il pas utiliser wwas ?

N’utilisez pas wwas quand vous avez besoin d’une conception technique détaillée, de tâches d’implémentation ou de notes de version. C’est un outil de Requirements Planning, pas un générateur de spécifications de code.

Comment améliorer le skill wwas

Formulez le problème de manière plus précise

Les meilleures sorties wwas commencent par un problème utilisateur ou métier concret. Remplacez « ajouter des filtres » par « aider les agents support à retrouver plus vite les dossiers ouverts dans une file à fort volume ». Ce type d’entrée renforce la section Why et évite les critères d’acceptation génériques.

Posez les limites dès le départ

wwas fonctionne mieux quand vous dites clairement ce qui est hors périmètre. Si la fonctionnalité est réservée au mobile, à l’interne ou à un seul segment d’utilisateurs, indiquez-le d’emblée. Cela évite que les critères d’acceptation dérivent vers des cas sans rapport.

Vérifiez l’indépendance et la testabilité

Le mode d’échec le plus courant avec wwas consiste à générer un item de backlog qui mélange plusieurs livrables. Si la sortie regroupe interface, analytics et permissions dans un seul item, séparez ces sujets et relancez le skill. Vérifiez aussi que les critères d’acceptation décrivent des résultats observables, et non des détails d’implémentation.

Itérez à partir du premier brouillon

Considérez la première sortie wwas comme un brouillon de cadrage. Si le Why est faible, renvoyez l’objectif métier. Si le What est trop large, resserrez la fonctionnalité. Si les critères d’acceptation sont trop flous, ajoutez le rôle, le déclencheur et le résultat attendu. Cette boucle d’itération améliore souvent davantage l’artifact final de Requirements Planning que l’ajout de contexte initial supplémentaire.