Mise à jour des parties prenantes

Si vous voyez des espaces réservés non familiers ou avez besoin de vérifier quels outils sont connectés, consultez CONNECTORS.md.

Générez une mise à jour des parties prenantes adaptée à l'audience et à la cadence.

Utilisation

/stakeholder-update $ARGUMENTS

Flux de travail

1. Déterminer le type de mise à jour

Demandez à l'utilisateur quel type de mise à jour :

• Hebdomadaire : Mise à jour régulière sur la progression, les blocages et les prochaines étapes
• Mensuelle : Résumé haut niveau avec tendances, jalons et alignement stratégique
• Lancement : Annonce d'un lancement de fonctionnalité ou de produit avec détails et impact
• Ponctuelle : Mise à jour unique pour une situation spécifique (escalade, pivot, décision majeure)

2. Déterminer l'audience

Demandez à qui s'adresse la mise à jour :

• Exécutifs / leadership : Haut niveau, axé sur les résultats, cadrage stratégique, concis
• Équipe d'ingénierie : Détails techniques, contexte de mise en œuvre, blocages, décisions nécessaires
• Partenaires transversaux : Détails appropriés au contexte, focus sur les objectifs partagés et les dépendances
• Clients / externe : Axé sur les avantages, timelines clairs, pas de jargon interne
• Conseil d'administration : Piloté par les métriques, stratégique, focus sur les risques, très concis

3. Extraire le contexte des outils connectés

Si ~~suivi de projet est connecté :

• Récupérer le statut des éléments de feuille de route et des jalons
• Identifier les éléments complétés depuis la dernière mise à jour
• Mettre en évidence les éléments à risque ou bloqués
• Récupérer la progression du sprint ou de l'itération

Si ~~chat est connecté :

• Rechercher les discussions et décisions pertinentes de l'équipe
• Trouver les blocages ou problèmes soulevés dans les canaux
• Identifier les décisions clés prises de manière asynchrone

Si ~~transcription de réunion est connectée :

• Récupérer les notes de réunion récentes et les résumés de discussions
• Trouver les décisions et éléments d'action des réunions pertinentes

Si ~~base de connaissances est connectée :

• Rechercher les notes de réunion récentes
• Trouver les documents de décision ou les revues de conception

Si aucun outil n'est connecté, demandez à l'utilisateur de fournir :

• Ce qui a été réalisé depuis la dernière mise à jour
• Les blocages ou risques actuels
• Les décisions clés prises ou nécessaires
• Ce qui arrive ensuite

4. Générer la mise à jour

Structurez la mise à jour pour l'audience cible en utilisant les modèles et cadres ci-dessous.

Pour les exécutifs : TL;DR, indicateur de statut (V/J/R), progression clé liée aux objectifs, décisions prises, risques avec atténuation, demandes spécifiques et prochains jalons. À garder sous 300 mots.

Pour l'ingénierie : Ce qui a été livré (avec liens), ce qui est en cours (avec propriétaires), blocages, décisions nécessaires (avec options et recommandation) et ce qui arrive ensuite.

Pour les partenaires transversaux : Ce qui arrive et les affecte, ce que vous avez besoin d'eux (avec délais), décisions qui impactent leur équipe et domaines ouverts aux retours.

Pour les clients : Ce qui est nouveau (cadré comme avantages), ce qui arrive bientôt, problèmes connus avec contournements, et comment envoyer des retours. Pas de jargon interne.

Pour les annonces de lancement : Ce qui a été lancé, pourquoi c'est important, détails clés (portée, disponibilité, limitations), métriques de succès, plan de déploiement et canaux de retour.

5. Examiner et livrer

Après la génération de la mise à jour :

• Demandez si l'utilisateur souhaite ajuster le ton, le niveau de détail ou l'emphasis
• Proposez de formater pour le canal de livraison (email, message chat, document, diapositives)
• Si ~~chat est connecté, proposez de rédiger le message pour envoi

Modèles de mise à jour par audience

Mise à jour exécutive / leadership

Les exécutifs veulent : contexte stratégique, progression par rapport aux objectifs, risques qui nécessitent leur aide, décisions qui nécessitent leur avis.

Format :

Statut : [Vert / Jaune / Rouge]

TL;DR : [Une phrase — la chose la plus importante à savoir]

Progression :
- [Résultat atteint, lié à l'objectif/OKR]
- [Jalon atteint, avec impact]
- [Mouvement de métrique clé]

Risques :
- [Risque] : [Plan d'atténuation]. [Demande si nécessaire].

Décisions nécessaires :
- [Décision] : [Options avec recommandation]. Nécessaire par [date].

Prochains jalons :
- [Jalon] — [Date]

Conseils pour les mises à jour exécutives :

• Commencez par la conclusion, pas par le voyage. Les exécutifs veulent « nous avons livré X et cela a déplacé la métrique Y » et non « nous avons eu 14 standups et résolu 23 tickets ».
• À garder sous 200 mots. S'ils en veulent plus, ils vous le demanderont.
• L'indicateur de statut doit refléter VOTRE évaluation sincère, pas ce que vous pensez qu'ils veulent entendre. Le jaune n'est pas un échec — c'est une bonne gestion des risques.
• Incluez uniquement les risques sur lesquels vous voulez de l'aide. Ne listez pas les risques que vous gérez déjà sauf s'ils ont besoin de le savoir.
• Les demandes doivent être spécifiques : « Décision sur X vendredi » et non « du soutien nécessaire ».

Mise à jour de l'équipe d'ingénierie

Les ingénieurs veulent : des priorités claires, un contexte technique, des blocages résolus, des décisions qui affectent leur travail.

Format :

Livré :
- [Fonctionnalité/correction] — [Lien vers PR/ticket]. [Impact si notable].

En cours :
- [Élément] — [Propriétaire]. [Completion attendue]. [Blocages le cas échéant].

Décisions :
- [Décision prise] : [Justification]. [Lien vers ADR si existe].
- [Décision nécessaire] : [Contexte]. [Options]. [Recommandation].

Changements de priorité :
- [Ce qui a changé et pourquoi]

À venir :
- [Éléments suivants] — [Contexte sur pourquoi c'est ensuite]

Conseils pour les mises à jour d'ingénierie :

• Liez des tickets, PRs et documents spécifiques. Les ingénieurs veulent cliquer pour les détails.
• Quand les priorités changent, expliquez pourquoi. Les ingénieurs sont plus impliqués quand ils comprennent la raison.
• Soyez explicite sur ce qui les bloque et ce que vous faites pour débloquer.
• Ne leur faites pas perdre de temps avec des informations qui n'affectent pas leur travail.

Mise à jour des partenaires transversaux

Les partenaires (design, marketing, ventes, support) veulent : ce qui arrive et les affecte, ce qu'ils doivent préparer, comment envoyer des retours.

Format :

Ce qui arrive :
- [Fonctionnalité/lancement] — [Date]. [Ce que cela signifie pour votre équipe].

Ce que nous avons besoin de vous :
- [Demande spécifique] — [Contexte]. Par [date].

Décisions prises :
- [Décision] — [Comment cela affecte votre équipe].

Ouvert aux retours :
- [Sujet sur lequel nous aimerions des retours] — [Comment les envoyer].

Mise à jour client / externe

Les clients veulent : ce qui est nouveau, ce qui arrive, comment cela les bénéficie, comment commencer.

Format :

Ce qui est nouveau :
- [Fonctionnalité] — [Avantage en termes client]. [Comment l'utiliser / lien].

À venir bientôt :
- [Fonctionnalité] — [Timing attendu]. [Pourquoi c'est important pour vous].

Problèmes connus :
- [Problème] — [Statut]. [Contournement si disponible].

Retours :
- [Comment partager des retours ou demander des fonctionnalités]

Conseils pour les mises à jour client :

• Pas de jargon interne. Pas de numéros de tickets. Pas de détails de mise en œuvre technique.
• Cadrez tout en termes de ce que le client peut maintenant FAIRE, pas ce que vous avez construit.
• Soyez honnête sur les timelines mais ne vous surengagez pas. « Plus tard ce trimestre » est mieux qu'une date que vous pourriez manquer.
• Ne mentionnez les problèmes connus que s'ils impactent le client et vous avez un plan de résolution.

Cadre de rapport de statut

Statut vert / jaune / rouge

Vert (Sur la bonne voie) :

• Progresse comme prévu
• Aucun risque ou blocage significatif
• Sur la bonne voie pour respecter les engagements et délais
• Utilisez Vert quand les choses vont vraiment bien — pas comme valeur par défaut

Jaune (À risque) :

• La progression est plus lente que prévu, ou un risque s'est matérialisé
• L'atténuation est en cours mais le résultat est incertain
• Peut manquer les engagements sans intervention ou ajustement de portée
• Utilisez Jaune de manière proactive — plus tôt vous signalez le risque, plus d'options vous avez

Rouge (Hors piste) :

• Significativement en retard sur le plan
• Blocage majeur ou risque sans atténuation claire
• Manquera les engagements sans intervention significative (réduction de portée, ajout de ressources, extension de timeline)
• Utilisez Rouge quand vous avez vraiment besoin d'aide. Ne attendez pas que ce soit trop tard.

Quand changer le statut

• Passez à Jaune au PREMIER signe de risque, pas quand vous êtes sûr que les choses vont mal
• Passez à Rouge quand vous avez épuisé vos propres options et avez besoin d'escalade
• Revenez à Vert uniquement quand le risque est vraiment résolu, pas seulement mis en pause
• Documentez ce qui a changé quand vous changez de statut — « Passé à Jaune parce que [raison] »

Communication des risques

Cadre ROAM pour la gestion des risques

• Résolu : Le risque n'est plus une préoccupation. Documentez comment il a été résolu.
• Propriétaire : Le risque est reconnu et quelqu'un le gère activement. Indiquez le propriétaire et le plan d'atténuation.
• Accepté : Le risque est connu mais nous choisissons de procéder sans atténuation. Documentez la justification.
• Atténué : Les actions ont réduit le risque à un niveau acceptable. Documentez ce qui a été fait.

Communiquer les risques efficacement

1. Énoncez le risque clairement : « Il y a un risque que [chose] se produise parce que [raison] »
2. Quantifiez l'impact : « Si cela se produit, la conséquence est [impact] »
3. Indiquez la probabilité : « C'est [probable/possible/improbable] parce que [évidence] »
4. Présentez l'atténuation : « Nous gérons cela en [actions] »
5. Faites la demande : « Nous avons besoin [d'aide spécifique] pour réduire davantage ce risque »

Erreurs courantes dans la communication des risques

• Enterrer les risques dans les bonnes nouvelles. Commencez par les risques s'ils sont importants.
• Être vague : « Il pourrait y avoir des retards » — spécifiez quoi, combien de temps et pourquoi.
• Présenter les risques sans atténuations. Chaque risque doit venir avec un plan.
• Attendre trop longtemps. Un risque communiqué tôt est une entrée de planification. Un risque communiqué tard est un exercice d'extinction d'incendie.

Documentation des décisions (ADRs)

Format Architecture Decision Record

Documentez les décisions importantes pour référence future :

# [Titre de la décision]

## Statut
[Proposé / Accepté / Déprécié / Remplacé par ADR-XXX]

## Contexte
Quelle est la situation qui nécessite une décision ? Quelles forces sont en jeu ?

## Décision
Qu'avons-nous décidé ? Énoncez la décision clairement et directement.

## Conséquences
Quelles sont les implications de cette décision ?
- Conséquences positives
- Conséquences négatives ou compromis acceptés
- Ce que cela rend possible ou empêche à l'avenir

## Alternatives considérées
Quelles autres options ont été évaluées ?
Pour chacune : qu'était-ce, pourquoi a-t-elle été rejetée ?

Quand écrire une ADR

• Décisions stratégiques de produit (quel segment de marché cibler, quelle plateforme supporter)
• Décisions techniques importantes (choix d'architecture, sélection de fournisseur, construire vs acheter)
• Décisions controversées où les gens n'étaient pas d'accord (documentez la justification pour référence future)
• Décisions qui limitent les options futures (choisir une technologie, signer un partenariat)
• Décisions que vous vous attendez à ce que les gens questionnent plus tard (capturez le contexte tant qu'il est frais)

Conseils pour la documentation des décisions

• Écrivez les ADRs près du moment où la décision est prise, pas des semaines plus tard
• Incluez qui a été impliqué dans la décision et qui a pris l'appel final
• Documentez le contexte généreusement — les futurs lecteurs n'auront pas le contexte d'aujourd'hui
• C'est okay de documenter les décisions qui s'avéraient mauvaises avec le recul — ajoutez un lien « remplacé par »
• Gardez-les courts. Une page est mieux que cinq.

Animation de réunions

Stand-up / Synchronisation quotidienne

Objectif : Mettre en surface les blocages, coordonner le travail, maintenir l'élan. Format : Chaque personne partage :

• Ce qu'elle a réalisé depuis la dernière synchronisation
• Sur quoi elle travaille ensuite
• Ce qui la bloque

Conseils d'animation :

• À garder à 15 minutes. Si des discussions émergent, traitez-les hors ligne.
• Focus sur les blocages — c'est la partie de plus haute valeur du standup
• Suivez les blocages et faites un suivi sur leur résolution
• Annulez le standup s'il n'y a rien à synchroniser. Respectez le temps des gens.

Planification de sprint / itération

Objectif : S'engager sur du travail pour le prochain sprint. Aligner sur les priorités et la portée. Format :

1. Examen : ce qui a été livré le sprint dernier, ce qui a été reporté, ce qui a été coupé
2. Priorités : quelles sont les choses les plus importantes à accomplir ce sprint
3. Capacité : combien peut l'équipe prendre (comptez les congés, les astreintes, les réunions)
4. Engagement : sélectionnez des éléments du backlog qui correspondent à la capacité et aux priorités
5. Dépendances : signalez toute dépendance interéquipes ou externe

Conseils d'animation :

• Venez avec un ordre de priorité proposé. Ne demandez pas à l'équipe de prioriser à partir de zéro.
• Repoussez le surengagement. Il est mieux de s'engager sur moins et de livrer de manière fiable.
• Assurez-vous que chaque élément a un propriétaire clair et des critères d'acceptation clairs.
• Signalez les éléments sous-scopés ou ayant une complexité cachée.

Rétrospective

Objectif : Réfléchir à ce qui a bien fonctionné, ce qui n'a pas fonctionné et ce qu'il faut changer. Format :

1. Établir le contexte : rappelez à l'équipe l'objectif et créez la sécurité psychologique
2. Recueillir des données : ce qui a bien fonctionné, ce qui n'a pas bien fonctionné, ce qui était confus
3. Générer des insights : identifier les patterns et les causes racines
4. Décider des actions : choisissez 1-3 améliorations spécifiques à essayer le prochain sprint
5. Clore : remerciez les gens pour leurs retours honnêtes

Conseils d'animation :

• Créez la sécurité psychologique. Les gens doivent se sentir en sécurité pour être honnêtes.
• Focus sur les systèmes et processus, pas sur les individus.
• Limitez à 1-3 éléments d'action. Plus que cela et rien ne change.
• Faites un suivi sur les éléments d'action des rétros précédentes. Si vous ne faites jamais de suivi, les gens arrêtent de s'engager.
• Variez le format rétro occasionnellement pour éviter la staleness.

Revue / Démo des parties prenantes

Objectif : Montrer la progression, recueillir les retours, construire l'alignement. Format :

1. Contexte : rappelez aux parties prenantes l'objectif et ce qu'ils ont vu la dernière fois
2. Démo : montrez ce qui a été construit. Utilisez le vrai produit, pas des diapositives.
3. Métriques : partagez toute donnée précoce ou retour
4. Retours : temps structuré pour les questions et l'input
5. Prochaines étapes : ce qui arrive ensuite et quand la prochaine revue aura lieu

Conseils d'animation :

• Démontrez le vrai produit dès que possible. Les diapositives ne sont pas des démos.
• Cadrez la collecte de retours : « Quel retour avez-vous sur X ? » est mieux que « Des pensées ? »
• Capturez les retours visiblement et engagez-vous à les traiter (ou expliquez pourquoi pas)
• Définissez les attentes sur quel type de retour est actionnable à ce stade

Format de sortie

Gardez les mises à jour faciles à scanner. Utilisez le gras pour les points clés, les puces pour les listes. Les mises à jour exécutives doivent être sous 300 mots. Les mises à jour d'ingénierie peuvent être plus longues mais doivent quand même être structurées pour un survol rapide.

Conseils

• L'erreur la plus courante dans les mises à jour des parties prenantes est d'enterrer le lead. Commencez par la chose la plus importante.
• Les indicateurs de statut (Vert/Jaune/Rouge) doivent refléter la réalité, pas l'optimisme. Le jaune n'est pas un échec — c'est une bonne communication des risques.
• Les demandes doivent être spécifiques et actionnables. « Nous avons besoin d'aide » n'est pas une demande. « Nous avons besoin d'une décision sur X vendredi » en est une.
• Pour les exécutifs, cadrez tout en termes de résultats et d'objectifs, pas d'activités et de tâches.
• S'il y a de mauvaises nouvelles, commencez par elles. Ne les cachez pas après les bonnes nouvelles.
• Adaptez la longueur à l'attention de l'audience. Les exécutifs obtiennent quelques puces. L'ingénierie obtient les détails dont elle a besoin.