Le mandat
Transformer les preuves client en la plus petite version dont l’entreprise puisse tirer un apprentissage.
Transforme les preuves en stratégie produit, exigences, jalons, critères d’acceptation et cycles d’apprentissage.
L’agent produit traduit les besoins observés en résultats, exclusions, exigences, lots livrables et critères d’acceptation. Il empêche une fonctionnalité demandée de devenir un engagement de feuille de route avant que l’hypothèse sous-jacente soit comprise.
Éléments à fournir
Présentez un workflow, un utilisateur cible et les preuves du problème.
Le brief doit comprendre le comportement actuel et les contraintes, en plus du résultat recherché. Une liste de fonctionnalités sans preuves client ne suffit pas.
- 01
Le domaine produit, le parcours client ou le workflow à planifier.
- 02
L'utilisateur, la situation, l'alternative actuelle et le résultat souhaité.
- 03
Comportements observés, entretiens, éléments issus de l’assistance, données d’usage et hypothèses non résolues.
- 04
Contraintes de temps, de plateforme, juridiques, techniques, de design, commerciales et de dépendances.
- 05
Le résultat client et l’hypothèse importante que la prochaine version doit tester.
Ce que vous recevez
Une stratégie et un plan de livraison qui restent testables.
La stratégie produit, les exigences prioritaires et les lots à livrer partagent le même résultat client, les mêmes preuves, les mêmes dépendances et le même objectif d’apprentissage.
- 01
Stratégie produit
product/strategy.mdPrêt lorsque
Client, problème, résultat, contraintes et non-objectifs sont explicites.
- 02
Exigences prioritaires
product/requirements.jsonPrêt lorsque
Chaque exigence comporte des éléments de preuve et des critères d'acceptation.
- 03
Plan de livraison progressive
product/releases.mdPrêt lorsque
Chaque lot peut être testé indépendamment par un client cible.
La méthode
Cadrez le résultat, répartissez les risques et décidez ce que la version doit démontrer.
L'agent produit réduit délibérément la portée jusqu'à ce que la prochaine version puisse être utilisée, mesurée et discutée avec un client cible.
- 1
Cadrer
Définir l'utilisateur, le comportement actuel, le résultat souhaité, les preuves, les contraintes et les non-objectifs.
- 2
Découper
Choisissez la plus petite version utile en elle-même qui permette de tester une hypothèse importante.
- 3
Préciser
Rédiger les exigences, les dépendances, les cas limites et les critères d’acceptation observables.
- 4
Apprendre
Planifier la validation auprès des clients, la collecte des preuves et la décision après livraison.
Signaux et garde-fous
Un périmètre n’est pas validé simplement parce qu’il tient dans une feuille de route.
Des exigences sans preuves, des dépendances cachées et des lots livrables qui ne peuvent pas tester indépendamment un résultat restent des risques produit non résolus.
Signes que le travail est utile
- Achèvement du flux de travail principal
- Délai d’accès à la première valeur
- Apprentissage validé à chaque version
Motifs de la pause
- Le périmètre fonctionnel n’est pas lié aux preuves
- Les engagements pris dans le cadre de la feuille de route cachent les dépendances non résolues
Périmètre d’approbation
Ce point d’entrée ne déclare aucune action sur des systèmes externes. L’application de ses tâches nécessite tout de même une exécution de projet authentifiée et au périmètre défini.
Annexe technique
Le contrat exact derrière le profil.
Utile aux opérateurs qui souhaitent examiner la version immuable du Kit, son contrat typé et les éléments à vérifier.
- Kit
- company-suite@0.1.0
- Point d'entrée
- plan-product
- Fonction
- plan-product
- Environnement d’exécution
- python@3.12
- Entrée
- specialist-brief.schema.json
- Résultat
- specialist-plan.schema.json
Vérification
specialist-plan-quality · specialist-plan-schema
Systèmes connectés
Aucun connecteur externe n'est requis