Je veux
répondre aux tickets sans y passer la journée
Les tickets entrants sont triés, les doublons fermés, les manques signalés, les réponses écrites. Il reste ceux qui méritent une décision.
À la fin
Une file où il ne reste que les vraies décisions.
Les phrases, dans l’ordre
Copiez une phrase, laissez l’étape rendre ce qui est nommé, puis passez à la suivante.
standardiste
Le tri, les doublons, les informations manquantes demandées, les réponses rédigées.
Sous le capot
Standardistestandardiste des tickets entrants
audit produit
Ce que la file de tickets dit du produit, au-delà de chaque ticket.
Sous le capot
Cartographecartographe des routes produit
tracer
Les tickets tranchés envoyés dans la boucle ticket → PR.
Sous le capot
Convoyeuseconvoyeuse de l'issue à la relecture
Sous le capot — 3 cartes
Si ce n’est pas tout à fait ça
- Je veux transformer les tickets en pull requestsLa boucle complète : un ticket étiqueté est pris, compris, implémenté, et rendu en PR relue. Sans qu’on ait à le lancer à chaque fois.
- Je veux comprendre ce que veulent mes utilisateursDes réponses d’enquête, des retours en vrac, des chiffres. Traduits en décisions, pas en jolis graphiques.
Tirage écrit à la main dans data/parcours.json, tenu par scripts/parcours/check-parcours.sh : chaque carte citée existe dans le registre du framework.


