Coordonner les signoffs cross-team d'un Tech Breakdown

Ceci est la moitié interfonctionnelle du Modèle de Démonstration Technique de Bitwarden. Elle couvre la Partie 3 (le tableau de validation et la liste de vérification interfonctionnelle) et la liste de vérification de communication à la fermeture de la démonstration. Le contenu technique de la démonstration — Parties 1, 2, 4, 5, 6 — se trouve dans Skill(writing-tech-breakdowns); la machine d'état canonique (IN PLANNING → IN PROGRESS → PROPOSED → ACCEPTED → COMPLETE) y est documentée. Cette skill s'exécute quand la démonstration atteint PROPOSED et s'exécute à nouveau quand l'implémentation est livrée et que la démonstration est prête à passer à COMPLETE.

Quand le modèle canonique est nécessaire, récupérez la page 2920349776 via get_confluence_page.

Identification des équipes affectées

Le tableau de validation n'est utile que dans la mesure où la liste d'équipes qui l'alimente. Deux sources, dans cet ordre :

1. L'Initiative, via l'entonnoir

Si la démonstration se situe sous une Initiative BW, exécutez Skill(navigating-the-initiative-funnel) pour extraire :

La liste d'équipes affectées de l'initiative — le responsable l'a généralement identifiée lors du Scoping & Commitment.
Les épiques des équipes sœurs sous la même initiative — celles-ci deviennent des lignes dans le tableau de validation, et chacune se lie à la démonstration propre de l'équipe sœur dans la colonne « Associated Other Team Breakdown ».
Le responsable lui-même — il détient le contexte de coordination interfonctionnelle autour duquel cette skill est construite. Impliquez-le tôt, surtout si une validation va être contentieuse.

L'approche par entonnoir en premier lieu est le défaut quand une initiative existe. Elle produit une liste de validation qui reflète la même image d'équipes affectées que celle que le responsable rapporte à la direction. Une divergence entre les deux est en soi un signal qui mérite d'être soulevé.

2. La liste de vérification interfonctionnelle, pour le travail limité à une équipe ou les lacunes d'initiative

Quand aucune initiative n'existe, ou quand la liste d'équipes affectées de l'initiative manque des lignes que le travail touche clairement, parcourez directement la liste de vérification interfonctionnelle de la Partie 3. Chaque question correspond à des lignes de validation potentielles :

Y aura-t-il des changements mobiles ? Si oui, l'équipe Mobile est sur la liste — et tout changement mobile doit être défini comme des stories Jira distinctes qui sont déplacées vers le board de l'équipe Mobile. Le travail mobile est structurellement distinct ; ne le repliez pas dans les stories de l'équipe d'origine.
Composants, services ou fichiers en dehors du domaine de l'équipe ? Chaque zone affectée implique que l'équipe propriétaire soit sur la liste. Contactez leur responsable technique et EM via DM pour évaluer l'impact avant de les ajouter — les demandes de validation par surprise ne fonctionnent pas bien. Si une démonstration d'une équipe sœur pour un travail connexe existe déjà, liez-la dans la colonne « Associated Other Team Breakdown ».
Dépendance aux services d'autres équipes ? Une dépendance significative déclenche deux vérifications : la dépendance est-elle stable (aucune dette technique majeure signalée dans cette zone, aucun remplacement à court terme prévu), et l'autre équipe est-elle consciente du volume/de la forme de l'utilisation. L'équipe propriétaire est sur la liste de validation. Si leur dette technique est un risque réel, soulevez-le comme une question ouverte de Partie 5 dans la démonstration.
Construire une API ou un service pour une autre équipe ? Si oui, envisagez de produire l'interface en premier afin que l'équipe consommatrice puisse coder contre celle-ci pendant que l'implémentation est en cours. L'équipe consommatrice doit être consultée deux fois : une fois après que la conception de l'interface est complète (au niveau de la démonstration), et à nouveau au stade de la PR de l'implémentation. Les deux revues vont sur la liste de validation.

Le tableau de validation de la Partie 3

Un exemple travaillé avec les formes en vol et entièrement validées se trouve à ${CLAUDE_PLUGIN_ROOT}/skills/coordinating-cross-team-breakdown/examples/signoff-table.md. Utilisez-le comme référence de forme pour ce que les bonnes cellules ressemblent, la distinction Blocking-vs-advisory, et ce qu'une table saine ressemble à PROPOSED versus ACCEPTED.

Le modèle spécifie cinq colonnes. Traitez chacune comme fondamentale :

Colonne	Ce qui va dedans
Team	Le nom de l'équipe propriétaire. Une ligne par équipe — combinez les sous-interfaces sous une seule ligne de l'équipe dans la cellule « Describe interface ».
Describe interface	Ce que cette démonstration demande à l'autre équipe. « Point de terminaison API qu'ils vont consommer », « service partagé qu'ils possèdent que nous étendons », « extension de bibliothèque de composants », « parité mobile pour nouvelle fonctionnalité ». Suffisamment spécifique pour que le responsable technique de l'autre équipe puisse réagir.
Blocking?	Oui/Non. La validation de cette équipe est-elle une porte dure sur le passage à ACCEPTED, ou est-elle advisory (FYI-level) ? Faites cela correctement — over-marking as Blocking bloque les démonstrations ; under-marking produit des validations qui sont ignorées.
Associated Other Team Breakdown	Lien vers la démonstration sœur si l'autre équipe produit la leur. Vide quand l'autre équipe ne produit pas de démonstration pour cette interface spécifique (les lignes advisory ont souvent pas de démonstration associée).
Signoff	Le humain nommé qui a validé, avec la date. Pas « l'équipe » — un responsable technique spécifique, un ingénieur, ou un EM. Vide jusqu'à ce que la validation soit reçue.

Règle d'or sur Blocking ? : si l'autre équipe possède le code que le changement modifie directement, appelle, ou dépend du contrat de, la validation est Blocking. Si l'autre équipe est informée parce que sa zone est adjacente ou pourrait être affectée incidemment, la validation est advisory.

Chaser les validations

Une fois la table construite, les validations deviennent le travail gating pour passer de PROPOSED à ACCEPTED. Quelques règles :

Contactez directement le humain nommé dans la ligne de validation de l'autre équipe. Un DM à un responsable technique vaut mieux qu'un post @-channel ; un post @-channel vaut mieux que rien. Le lien de la démonstration suffit — ils devraient pouvoir évaluer à partir du doc plus tout artefact lié de Partie 4.
N'acceptez pas « ça a l'air bien » sans un nom et une date dans la colonne signoff. Une démonstration qui se déplace à ACCEPTED avec des cellules signoff vides défait l'artefact.
Traitez les validations blocking comme des blockers. Si une ligne Blocking a été en attente pendant plus d'un sprint, escaladez — au responsable s'il y en a un, à l'EM de l'équipe sinon. Les validations blocking longtemps ouvertes sont généralement un symptôme que l'interface interfonctionnelle est contestée et a besoin d'être renégociée, pas juste d'attendre.
Quand une validation surface un problème, router-le à travers Skill(writing-tech-breakdowns). Les changements de conception matérielle appartiennent au contenu technique, pas aux fils Slack attachés à une demande de validation. Mettez à jour les Parties 1–4 dans la démonstration, re-confirmez avec toute personne qui a déjà validé, puis re-circulez.

Escalade médiée par le responsable

Quand la démonstration se situe sous une initiative et qu'une validation est contestée :

Surface au responsable avant de négocier directement avec le responsable technique de l'autre équipe. La cohérence interfonctionnelle entre une initiative est le travail du responsable — il a vu la même interface du côté de l'autre équipe et a probablement du contexte que l'équipe n'a pas.
Le responsable peut amener l'Architecture Council si l'interface contestée a des implications architecturales. N'escaladez pas à Architecture directement ; router via le responsable.
S'il n'y a pas de responsable (démonstration scoped à une équipe), escaladez à l'EM de l'équipe et à l'EM de l'autre équipe. Les engagements cross-EM ne sont pas pris unilatéralement au niveau IC — c'est une conversation de leadership par conception.

Exécutez Skill(navigating-the-initiative-funnel) pour les chemins d'escalade — ils y sont documentés en détail.

La liste de vérification interfonctionnelle, parcourue une fois

Indépendamment du tableau de validation, la liste de vérification interfonctionnelle de la Partie 3 est aussi une fonction de forçage sur la démonstration elle-même. Parcourez-la explicitement avant de considérer la Partie 3 complète :

Changements mobiles — définis comme des tâches/stories Jira distinctes sur le board de l'équipe Mobile. Ne repliez pas le travail mobile dans les stories de l'équipe d'origine ; l'équipe Mobile possède son sprint et sa codebase.
Composants/services/fichiers en dehors du domaine de l'équipe — déjà comptabilisés dans la liaison « Related breakdowns » de la Partie 1 ? Sinon, contactez le responsable technique et l'EM de l'équipe affectée via DM, puis ajoutez-les à la liste de validation. Ne surfacez pas de dépendances lors de la revue interfonctionnelle pour la première fois.
Utilisation des services d'autres équipes — vérifiez que la dépendance est stable. Vérifiez les indicateurs de dette technique visibles publiquement, les incidents récents, ou les dépréciations prévues. Si des préoccupations existent, soulevez-les comme des questions ouvertes de Partie 5 dans la démonstration.
Construction d'APIs pour une autre équipe — le modèle interface-first. Produisez le contrat tôt, consultez l'équipe consommatrice à la conception et à la PR.

Cette marche est rapide sur une petite démonstration et matérielle sur une grande. Ne la sautez pas pour la seconde.

Passage à ACCEPTED

La démonstration passe de PROPOSED à ACCEPTED quand chaque validation blocking est capturée dans la table de Partie 3 avec un humain nommé et une date. Les validations advisory qui restent ouvertes ne sont pas une porte ; elles devraient être chassées à la fermeture mais ne bloquent pas ACCEPTED.

La machine d'état est définie dans Skill(writing-tech-breakdowns) ; confirmez les règles de transition là. En pratique le passage à ACCEPTED signifie définir le champ status en haut de la démonstration et enregistrer la date de transition.

Une fois ACCEPTED, l'implémentation peut commencer. Les changements matériels après ACCEPTED nécessitent soit de remplacer la démonstration soit de la ramener à PROPOSED et de re-circuler les validations affectées — voir les règles de cycle de vie dans Skill(writing-tech-breakdowns).

La liste de vérification de communication de fermeture

Quand l'implémentation a été livrée et que la démonstration est prête à passer à COMPLETE, exécutez la liste de vérification de fermeture du modèle :

Vérifiez la validation de toutes les équipes impliquées. Re-lisez la Partie 3. Chaque ligne blocking a un humain nommé et une date ; chaque ligne advisory a une note de fermeture. Si quelque chose est encore ouvert, fermez-le avant de marquer COMPLETE.
Postez un lien dans #team-eng-tech-breakdowns pour la visibilité interfonctionnelle. Ceci est l'annonce organisationnelle que la démonstration a été livrée. Les autres équipes parcourent ce canal pour repérer les changements cross-cutting — sauter le post est invisible jusqu'à ce que quelqu'un en aval soit pris de court.
Contactez l'ingénieur QA responsable afin qu'il puisse revoir la démonstration et construire les cas de test contre la conception. QA s'appuie sur la démonstration comme source de vérité pour la couverture de test — impliquez explicitement le bon propriétaire QA. Si un propriétaire QA n'a pas été identifié, postez sur le canal Slack interne de l'équipe pour les surfacer.
Contactez le facilitateur de raffinement de l'équipe pour vous assurer que les tâches résultantes peuvent être incluses dans la prochaine session de raffinement. C'est le pont de la démonstration à la planification de sprint — sans cela, les stories de la démonstration restent dans le backlog au lieu d'être reprises.

Ensuite, définissez le statut à COMPLETE. La démonstration est maintenant un artefact de référence — aucune autre édition sauf les corrections aux erreurs factuelles.

L'état terminal REJECTED

L'alternative terminale à COMPLETE. Utilisez quand la revue interfonctionnelle surface des incompatibilités ou des blockers qui ne peuvent pas être résolus dans la portée de la démonstration. Préservez la démonstration — c'est le dossier historique de pourquoi l'approche n'a pas fonctionné — et produisez une nouvelle démonstration si le travail est en train d'être re-façonné. Communiquez le rejet sur #team-eng-tech-breakdowns afin que les autres équipes sachent de ne pas planifier contre l'original.

Erreurs communes

Construire le tableau de validation sans contexte d'entonnoir. Quand une initiative existe, le responsable a déjà fait le travail d'identification d'équipes. Ignorer cela produit une divergence et des validations dupliquées.
Over-marking les validations comme Blocking. Chaque ligne blocking est une porte dure. Si la moitié de la table est blocking, la démonstration ne se déplacera pas à ACCEPTED. Réservez Blocking aux équipes dont le code le changement touche ou dont le contrat le changement dépend de.
Under-marking les validations comme Blocking. Les validations advisory d'équipes qui possèdent le code modifié produisent des validations qui sont ignorées — et des surprises lors de l'implémentation.
Laisser les validations ouvertes sans escalade. Une ligne blocking en attente pendant un sprint est une interface contestée, pas un problème de patience. Escaladez via le responsable ou les EMs.
Négocier les interfaces interfonctionnelles directement quand il y a un responsable. La cohérence interfonctionnelle est le travail du responsable. La négociation directe responsable-technique-à-responsable-technique minemine cela et produit des conceptions qui divergent à travers les équipes dans la même initiative.
Sauter la liste de vérification de communication de fermeture. Poster sur #team-eng-tech-breakdowns, contacter QA, et boucler le facilitateur de raffinement sont les mécanismes qui traduisent une démonstration finie en travail en aval réel. Les sauter produit des démonstrations qui livrent du code mais ne reaches jamais les équipes qui doivent savoir.
Éditer le tableau de validation pour enregistrer une validation qui n'a pas réellement été donnée. Si une validation est véritablement conditionnelle (« oui, avec ces réserves »), capturez les réserves dans la Partie 5 comme des questions ouvertes avant de passer à ACCEPTED. Ne couvrez pas les validations conditionnelles.

Référence

Modèle de Démonstration Technique (page 2920349776) — canonique. Récupérez via get_confluence_page pour le format complet de la table de Partie 3 et la liste de vérification de communication de fermeture.
Connexe : Skill(writing-tech-breakdowns) — le contenu technique de la démonstration et la machine d'état canonique. Skill(navigating-the-initiative-funnel) — load-bearing quand la démonstration se situe sous une Initiative BW ; fournit le responsable, la liste d'équipes affectées, et les chemins d'escalade utilisés tout au long de cette skill. Skill(architecting-solutions) (dans le plugin bitwarden-tech-lead) — la lentille de jugement architectural pour évaluer les interfaces interfonctionnelles contestées lors de la validation.