Mise à jour de la feuille de route

Si vous voyez des placeholders inhabituels ou avez besoin de vérifier quels outils sont connectés, consultez CONNECTORS.md.

Mettre à jour, créer ou réorganiser les priorités d'une feuille de route produit.

Utilisation

/roadmap-update $ARGUMENTS

Workflow

1. Comprendre l'état actuel

Si un suivi de projet est connecté :

Récupérer les éléments de feuille de route actuels avec leurs statuts, responsables et dates
Identifier les éléments en retard, à risque ou récemment terminés
Mettre en évidence tout élément sans propriétaire ou date claire

Si aucun outil de gestion de projet n'est connecté :

Demander à l'utilisateur de décrire sa feuille de route actuelle ou de la coller/charger
Accepter n'importe quel format : liste, tableau, feuille de calcul, capture d'écran ou description textuelle

2. Déterminer l'opération

Demander ce que l'utilisateur souhaite faire :

Ajouter un élément : nouvelle fonctionnalité, initiative ou élément de travail à la feuille de route

Recueillir : nom, description, priorité, effort estimé, délai cible, responsable, dépendances
Suggérer où l'insérer en fonction des priorités et capacités actuelles

Mettre à jour le statut : modifier le statut des éléments existants

Options : non commencé, en cours, à risque, bloqué, terminé, annulé
Pour « à risque » ou « bloqué » : demander le problème bloquant et le plan d'atténuation

Réorganiser les priorités : modifier l'ordre ou la priorité des éléments

Demander ce qui a changé (nouvelle information, changement de stratégie, changement de ressources, feedback client)
Appliquer un cadre de priorisation si utile — voir Cadres de priorisation ci-dessous pour RICE, MoSCoW, ICE et valeur-vs-effort
Montrer une comparaison avant/après

Déplacer le calendrier : décaler les dates des éléments

Demander pourquoi (changement de périmètre, glissement de dépendance, contrainte de ressources)
Identifier les impacts en aval sur les éléments dépendants
Signaler les éléments qui dépassent les échéances fermes

Créer une nouvelle feuille de route : construire une feuille de route à partir de zéro

Demander le délai (trimestre, semestre, année)
Demander la préférence de format (Maintenant/Suivant/Plus tard, colonnes trimestrielles, aligné OKR) — voir Cadres de feuille de route ci-dessous
Recueillir la liste des initiatives à inclure

3. Générer un résumé de la feuille de route

Produire une vue de feuille de route avec :

Aperçu du statut

Résumé rapide : X éléments en cours, Y terminés cette période, Z à risque.

Éléments de la feuille de route

Pour chaque élément, afficher :

Nom et description d'une ligne
Indicateur de statut (sur la bonne voie / à risque / bloqué / terminé / non commencé)
Délai cible ou date
Responsable
Dépendances clés

Regrouper les éléments par :

Délai (Maintenant / Suivant / Plus tard) ou trimestre, selon le format
Ou par thème/objectif si l'utilisateur préfère

Risques et dépendances

Éléments bloqués ou à risque, avec détails
Dépendances interéquipes et leur statut
Éléments approchant des échéances fermes

Changements cette mise à jour

Si c'est une mise à jour d'une feuille de route existante, résumer ce qui a changé :

Éléments ajoutés, supprimés ou réorganisés
Décalages calendaires
Changements de statut

4. Suivi

Après la génération de la feuille de route :

Proposer de formater pour un public spécifique (résumé exécutif, détails d'ingénierie, face au client)
Proposer de rédiger une communication sur les changements de feuille de route
Si un outil de gestion de projet est connecté, proposer de mettre à jour les statuts des tickets

Cadres de feuille de route

Maintenant / Suivant / Plus tard

Le format de feuille de route le plus simple et souvent le plus efficace :

Maintenant (sprint/mois actuel) : travail engagé. Confiance élevée dans le périmètre et le calendrier. Ce sont les choses que l'équipe construit activement.
Suivant (1-3 prochains mois) : travail planifié. Bonne confiance sur le quoi, moins de confiance sur le quand exactement. Délimité et priorisé mais pas encore commencé.
Plus tard (3-6+ mois) : directionnel. Ce sont des paris stratégiques et des opportunités que nous avons l'intention de poursuivre, mais le périmètre et le calendrier sont flexibles.

Quand l'utiliser : la plupart des équipes, la plupart du temps. Particulièrement efficace pour communiquer en externe ou à la direction car cela évite une fausse précision sur les dates.

Thèmes trimestriels

Organiser la feuille de route autour de 2-3 thèmes par trimestre :

Chaque thème représente un domaine stratégique d'investissement (p. ex., « Préparation Entreprise », « Améliorations d'activation », « Extensibilité de la plateforme »)
Sous chaque thème, lister les initiatives spécifiques planifiées
Les thèmes doivent correspondre aux OKR de l'entreprise ou de l'équipe
Ce format facilite l'explication de POURQUOI vous construisez ce que vous construisez

Quand l'utiliser : quand vous devez montrer l'alignement stratégique. Bon pour les réunions de planification et la communication exécutive.

Feuille de route alignée sur les OKR

Mapper directement les éléments de feuille de route aux Objectifs et Résultats clés :

Commencer par les OKR de l'équipe pour la période
Sous chaque Résultat clé, lister les initiatives qui feront bouger cette métrique
Inclure l'impact attendu de chaque initiative sur le Résultat clé
Cela crée une responsabilité claire entre ce que vous construisez et ce que vous mesurez

Quand l'utiliser : organisations qui fonctionnent sur les OKR. Bon pour s'assurer que chaque initiative a un « pourquoi » clair lié à des résultats mesurables.

Vue calendrier / Gantt

Vue basée sur le calendrier avec les éléments sur une chronologie :

Affiche les dates de début, de fin et les durées
Visualise le parallélisme et l'enchaînement
Bon pour identifier les conflits de ressources
Affiche les dépendances entre les éléments

Quand l'utiliser : planification d'exécution avec l'ingénierie. Identification des conflits d'ordonnancement. PAS bon pour communiquer en externe (crée des attentes de fausse précision).

Cadres de priorisation

Score RICE

Scorer chaque initiative sur quatre dimensions, puis calculer RICE = (Portée x Impact x Confiance) / Effort

Portée : combien d'utilisateurs/clients cela affectera-t-il dans une période donnée ? Utiliser des chiffres concrets (p. ex., « 500 utilisateurs par trimestre »).
Impact : combien cela fera-t-il bouger l'aiguille pour chaque personne atteinte ? Scorer sur une échelle : 3 = massif, 2 = élevé, 1 = moyen, 0,5 = faible, 0,25 = minimal.
Confiance : à quel point sommes-nous confiants dans les estimations de portée et d'impact ? 100 % = confiance élevée (soutenue par les données), 80 % = moyen (quelques preuves), 50 % = faible (intuition).
Effort : combien de mois-personne de travail ? Inclure l'ingénierie, le design et toute autre fonction.

Quand l'utiliser : quand vous avez besoin d'une priorisation quantitative et défendable. Bon pour comparer un grand backlog d'initiatives. Moins bon pour les paris stratégiques où l'impact est difficile à estimer.

MoSCoW

Catégoriser les éléments en Indispensable, Important, Souhaitable, Hors périmètre :

Indispensable : la feuille de route est un échec sans ceux-ci. Engagements non négociables.
Important : important et attendu, mais la livraison est viable sans eux.
Souhaitable : désirable mais clairement de priorité inférieure. Inclure seulement si la capacité le permet.
Hors périmètre : explicitement hors de portée pour cette période. Important à lister pour plus de clarté.

Quand l'utiliser : délimiter une version ou un trimestre. Négocier avec les parties prenantes sur ce qui tient. Bon pour forcer les conversations de priorisation.

Score ICE

Plus simple que RICE. Scorer chaque élément 1-10 sur trois dimensions :

Impact : combien cela fera-t-il bouger la métrique cible ?
Confiance : à quel point sommes-nous confiants dans l'estimation d'impact ?
Facilité : à quel point est-ce facile à mettre en œuvre ? (Inverse de l'effort — plus élevé = plus facile)

Score ICE = Impact x Confiance x Facilité

Quand l'utiliser : priorisation rapide d'un backlog de fonctionnalités. Bon pour les produits en phase initiale ou quand vous n'avez pas assez de données pour RICE.

Matrice valeur vs effort

Tracer les initiatives sur une matrice 2x2 :

Valeur élevée, Effort faible (Gains rapides) : Faire ceux-ci en premier.
Valeur élevée, Effort élevé (Paris majeurs) : Planifier ceux-ci soigneusement. Vaut l'investissement mais a besoin d'une délimitation appropriée.
Valeur faible, Effort faible (Remplisseurs) : Faire ceux-ci quand vous avez de la capacité de réserve.
Valeur faible, Effort élevé (Gouffres financiers) : Ne pas faire ceux-ci. Supprimer du backlog.

Quand l'utiliser : priorisation visuelle dans les sessions de planification d'équipe. Bon pour construire une compréhension partagée des tradeoffs.

Cartographie des dépendances

Identifier les dépendances

Rechercher les dépendances dans ces catégories :

Dépendances techniques : la Fonctionnalité B nécessite un travail d'infrastructure de la Fonctionnalité A
Dépendances d'équipe : la Fonctionnalité nécessite un travail d'une autre équipe (design, plateforme, data)
Dépendances externes : attendre un fournisseur, partenaire ou intégration tiers
Dépendances de connaissance : besoin de résultats de recherche ou d'investigation avant de commencer
Dépendances séquentielles : doit livrer la Fonctionnalité A avant de commencer la Fonctionnalité B (code partagé, flux utilisateur)

Gérer les dépendances

Lister toutes les dépendances explicitement dans la feuille de route
Assigner un responsable à chaque dépendance (qui est responsable de la résoudre)
Fixer une date « besoin avant » : quand l'élément dépendant a-t-il besoin que ce soit résolu
Construire une marge autour des dépendances — ce sont les éléments à plus haut risque sur n'importe quelle feuille de route
Signaler les dépendances qui traversent les frontières d'équipe tôt — celles-ci nécessitent de la coordination
Avoir un plan de contingence : que faites-vous si la dépendance glisse ?

Réduire les dépendances

Pouvez-vous construire une version plus simple qui évite la dépendance ?
Pouvez-vous paralléliser en utilisant un contrat d'interface ou un mock ?
Pouvez-vous enchaîner différemment pour déplacer la dépendance plus tôt ?
Pouvez-vous absorber le travail dans votre équipe pour supprimer la coordination interéquipes ?

Planification de la capacité

Estimer la capacité

Commencer par le nombre d'ingénieurs et la période
Soustraire les surcharges connues : réunions, rotations de garde, entretiens, vacances, congés
Une règle commune : les ingénieurs passent 60-70 % du temps sur le travail de fonctionnalités planifiées
Prendre en compte le temps de montée en puissance de l'équipe pour les nouveaux membres

Allouer la capacité

Une allocation saine pour la plupart des équipes produit :

70 % fonctionnalités planifiées : éléments de feuille de route qui avancent les objectifs stratégiques
20 % santé technique : dette technique, fiabilité, performance, expérience développeur
10 % imprévu : marge pour les problèmes urgents, gains rapides et demandes d'autres équipes

Ajuster les ratios selon le contexte de l'équipe :

Nouveau produit : plus de travail de fonctionnalités, moins de dette technique
Produit mature : plus de dette technique et d'investissement en fiabilité
Post-incident : plus de fiabilité, moins de fonctionnalités
Croissance rapide : plus de scalabilité et performance

Capacité vs ambition

Si les engagements de feuille de route dépassent la capacité, quelque chose doit donner
Ne pas résoudre les problèmes de capacité en prétendant que les gens peuvent faire plus — résoudre en réduisant le périmètre
Quand l'ajout à la feuille de route, toujours demander : « Qu'est-ce qui s'en va ? »
Mieux vaut s'engager sur moins de choses et livrer de manière fiable que de trop s'engager et décevoir

Communiquer les changements de feuille de route

Quand la feuille de route change

Déclencheurs courants de changements de feuille de route :

Nouvelle priorité stratégique de la direction
Feedback client ou recherche qui change les priorités
Découverte technique qui change les estimations
Glissement de dépendance d'une autre équipe
Changement de ressources (l'équipe grandit ou rétrécit, départ d'une personne clé)
Mouvement concurrentiel qui nécessite une réponse

Comment communiquer les changements

Reconnaître le changement : être direct sur ce qui change et pourquoi
Expliquer la raison : quelle nouvelle information a motivé cette décision ?
Montrer le tradeoff : qu'a été déprioritisé pour faire de la place ? Ou qu'est-ce qui glisse ?
Montrer le nouveau plan : feuille de route mise à jour avec les changements reflétés
Reconnaître l'impact : qui est affecté et comment ? Les parties prenantes qui s'attendaient aux éléments déprioritisés doivent l'entendre directement.

Éviter les changements de feuille de route chaotiques

Ne pas changer la feuille de route pour chaque nouvelle information. Avoir un seuil de changement.
Regrouper les mises à jour de feuille de route à des cadences naturelles (mensuellement, trimestriellement) sauf si quelque chose est vraiment urgent.
Distinguer entre « changement de feuille de route » (réorganisation stratégique) et « ajustement de périmètre » (affinement d'exécution normal).
Suivre la fréquence des changements de feuille de route. Les changements fréquents peuvent signaler une stratégie peu claire, pas une bonne réactivité.

Format de sortie

Utiliser un format clair et scannable. Les tableaux fonctionnent bien pour les éléments de feuille de route. Utiliser les labels de statut textuel : Terminé, Sur la bonne voie, À risque, Bloqué, Non commencé.

Conseils

Une feuille de route est un outil de communication, pas un plan de projet. La maintenir au bon niveau — thèmes et résultats, pas tâches.
Lors de la réorganisation des priorités, toujours demander ce qui a changé. Les changements de priorité doivent être motivés par de nouvelles informations, pas par du hasard.
Signaler les problèmes de capacité tôt. Si la feuille de route a plus de travail que l'équipe ne peut gérer, le dire.
Les dépendances sont le plus grand risque pour les feuilles de route. Les mettre en évidence explicitement.
Si l'utilisateur demande d'ajouter quelque chose, toujours demander ce qui s'en va ou se déplace. Les feuilles de route sont à somme nulle par rapport à la capacité.