scoping-and-handing-off-to-teams

Phase 4 (Scoping & Commitment) — guide approfondi pour un responsable d'initiative, dernière porte de décision avant allocation importante de ressources. Le responsable passe du pilotage du travail au soutien des équipes qui l'exécuteront. Livrables : le plan d'architecture de haut niveau, les épics enfants, les réunions de passation par équipe, l'analyse coûts-bénéfices, la présentation go/no-go au leadership, la priorisation opérationnelle, l'allocation de capacité et l'ADR finalisée. Budget temps : 2–4 semaines, 30–50 heures de temps du responsable. Compose Skill(running-work-transitions) dans bitwarden-delivery-tools pour les phases de préparation et transition du côté d'origine du Work Transition Playbook.

L'anti-pattern à rejeter d'abord

Avant tout : l'équipe possède la décomposition — pas le responsable. Le plus grand mode de défaillance à cette phase est que le responsable rédige les stories de l'équipe.

Le document funnel est sans ambiguïté : « Après la passation, menez une session de décomposition d'équipe. L'équipe crée les stories — pas le responsable. » Les stories que l'équipe n'a pas écrites sont des stories que l'équipe ne possédera pas. Une fois que cela arrive, la défaillance en aval se manifeste par « nous sommes en retard d'horaire parce que les stories ne correspondent pas à la façon dont l'équipe travaille réellement » et il n'y a pas de récupération claire.

Tenez bon. Votre travail est de donner à chaque équipe assez de contexte, de portée et de schéma pour bien décomposer le travail — pas de le décomposer pour eux.

Ce que vous produisez

Phase 4 produit huit artefacts, dans cet ordre approximatif : le plan d'architecture de haut niveau, les épics enfants dans Jira, les réunions de passation par équipe, une analyse coûts/bénéfices, la priorité d'initiative assignée, la présentation au leadership pour go/no-go, la priorisation opérationnelle avec allocation de capacité, et l'ADR finalisée. Chacun suit ci-dessous comme sa propre section.

Le plan d'architecture de haut niveau

Une page Confluence placée sous le dossier architecture-planning de l'espace EN, suivant le modèle « High-Level Architecture Planning ». Le document funnel spécifie son contenu :

• Portée. Ce qui sera changé — dépôts, modules, fichiers. Soyez précis. Une portée vague à ce stade signifie re-scoping lors de l'implémentation.
• Approche. Comment le changement se déploie. Phasage, chemin de migration, ce qui arrive au ancien schéma pendant et après la migration.
• Alignement d'équipe. Quelles équipes possèdent quelles portions. Une équipe par epic si possible.
• Dépendances. Ce qui doit arriver d'abord. Ce qui peut arriver en parallèle. Où les équipes se bloqueront mutuellement.
• Atténuation des risques. Modes de défaillance, plan de retour, quels indicateurs déclenchent une pause/pivot.
• Métriques de succès. Comment vous saurez que l'initiative a réussi. Définissez celles-ci maintenant — elles deviennent la base de la mesure d'impact 3–6 mois après la fin de l'implémentation.
• Besoins de documentation. Ce qui doit être créé ou mis à jour au fur et à mesure du déploiement (guide technique, guide de migration, mises à jour ADR, changements de guide contributeur, runbooks).

Le plan d'architecture est le document que le responsable technique de chaque équipe lit avant la réunion de passation. Écrivez-le pour ce lecteur.

Épics enfants dans Jira

Créez des épics sous l'initiative BW — généralement un par équipe ou module majeur. Chaque epic porte :

• Résumé. Court et concret (p. ex., « Migrer Browser Extension vers le nouveau pattern d'erreur »).
• Assignation d'équipe. Assignez à l'équipe, pas un individu.
• Description. Quelle zone du codebase est affectée ; quel schéma est adopté (lien vers PoC PR) ; résultats attendus pour cet epic ; critères de succès ; dépendances inter-équipes que l'équipe doit connaître.
• Label / component pour filtrer (p. ex., initiative-typescript-migration). C'est ainsi que le tableau de bord de chacun agrège la progression plus tard.

Exemple de forme epic du document funnel :

Epic : Migrer Browser Extension vers le nouveau pattern d'erreur Équipe : Browser Extension Team Description :

• Adopter le pattern de middleware d'erreur prouvé dans PoC (PR #1234)
• Appliquer aux scripts de fond, scripts de contenu et popup
• Doit maintenir le reporting d'erreur existant vers Sentry
• Succès : Tout le traitement d'erreur de l'extension suit le nouveau pattern, zéro régressions

Ce qui ne va pas dans l'epic : les stories implémentées. Celles-ci proviennent de la propre session de décomposition de l'équipe.

Réunions de passation par équipe

Planifiez une réunion de passation par équipe, 1 heure chacune. Selon le document funnel, la structure est :

C'est aussi la Phase 2 du Work Transition Playbook du côté d'origine. Le document funnel référence explicitement le playbook ; les deux perspectives s'appliquent.

Avant la réunion :

• Envoyez le plan d'architecture et le lien PoC PR quelques jours ouvrables à l'avance. Les équipes qui lisent les matériaux à l'avance posent des questions plus pertinentes.
• Confirmez que le responsable technique et l'EM de l'équipe assisteront.

Pendant la réunion :

• Commencez par le pourquoi (le problème et les résultats PoC) avant le quoi (le plan d'architecture). Les équipes réagissent mieux au contexte qu'à la spécification.
• Prenez les questions au sérieux, surtout celles qui exposent des conflits de roadmap. La passation est le bon endroit pour celles-ci — l'implémentation est le mauvais.
• Ne partez pas sans un engagement de date pour la décomposition. « Nous nous en chargerons » est comment les épics se désagrègent dans les backlogs.

Après la réunion :

• L'équipe mène sa propre session de décomposition (vous n'êtes pas présent).
• Le responsable technique de l'équipe vous partage la décomposition complétée.
• Vous révisez pour cohérence avec la vision de l'initiative — pas pour réécrire les stories ou micromanager. Le document funnel nomme le motif de question : « c'est bon mais utilise les callbacks au lieu du pattern async/await du PoC — était-ce intentionnel ? »

Analyse coûts/bénéfices

Documentez dans le plan d'architecture. Le cadrage du document funnel :

• Coût : Taille générale de l'effort entre les équipes (somme des estimations d'équipe, plus votre temps de responsable et le temps du Conseil d'architecture).
• Bénéfices :
  • Quantitatifs : bugs réduits, temps gagné, performance améliorée, pages on-call réduites.
  • Qualitatifs : expérience développeur, maintenabilité, cohérence, posture de sécurité, flexibilité future.
• Comparaison. Honnête. Si les bénéfices qualitatifs dominent, dites-le — le leadership peut peser cela. Prétendre avoir un cas quantitatif quand ce n'est pas le cas endommage la crédibilité de la prochaine initiative.

Priorité d'initiative

Selon le document funnel, travaillez avec le leadership en ingénierie pour définir la priorité par rapport aux autres initiatives et au portfolio du Architecture / Engineering Operating Model :

• Critique : Bloque un travail produit majeur ou crée un risque significatif — démarrer immédiatement.
• Élevée : Amélioration substantielle de la qualité de vie ou réduction des risques — programmer dans le trimestre.
• Moyenne : Amélioration significative, peut être programmée flexiblement — dans 2 trimestres.
• Basse : Agréable à avoir, le fera quand la capacité le permet — programmation opportuniste.

Mettez à jour la priorité sur l'initiative BW dans Jira.

Présentation au leadership

Présentez le plan au leadership en ingénierie lors d'une synchronisation des stakeholders. Selon le document funnel, incluez :

• Récapitulatif du problème et approche de solution.
• Résultats de validation PoC.
• Estimations d'effort et chronologie (à partir des décompositions d'équipe — agrégées).
• Analyse coûts/bénéfices.
• Évaluation des risques.
• Priorité d'initiative.
• Demande de ressources — quelles équipes, combien de capacité, sur quel délai.

Cherchez une décision go/no-go explicite. L'engagement exécutif signifie : « Oui, nous allouons des ressources pour compléter cette initiative. »

Priorisation opérationnelle

C'est l'étape que le document funnel distingue explicitement de l'engagement exécutif. L'engagement exécutif dit « oui, éventuellement ». La priorisation opérationnelle dit « commençant à ces dates avec autant de capacité ».

Coordonnez avec le leadership en ingénierie :

• Date de démarrage cible. Basée sur la priorité d'initiative et les autres engagements d'équipe.
• Trimestre(s) d'exécution.
• Priorité relative de chaque epic par rapport à l'autre travail de l'équipe (fonctionnalités roadmap produit, autres initiatives, bugs, dette technique).

Le leadership en ingénierie travaille avec les responsables d'équipe et les EMs pour :

• Communiquer l'importance et la chronologie de l'initiative.
• Allouer la capacité (p. ex., « 15 % de la capacité sprint pour les 3 prochains sprints »).
• Ajuster les roadmaps d'équipe.
• Résoudre les conflits si les équipes sont sur-engagées.
• Placer les épics dans les backlogs d'équipe avec la priorité appropriée.

Résultats de cette étape (selon le document funnel) :

• Une chronologie claire (p. ex., « L'implémentation commence Q2 2026, fin attendue Q3 2026 »).
• Chaque équipe impliquée consciente qu'elle doit allouer de la capacité.
• Priorité epic définie dans Jira pour le backlog de chaque équipe.
• Les équipes reconnaissent que le travail est dans leur roadmap.

Le document funnel nomme ce mode de défaillance explicitement : une initiative avec engagement exécutif mais sans priorisation opérationnelle s'enlise dans les backlogs indéfiniment. N'avancez pas vers l'implémentation sans priorisation opérationnelle.

Finaliser l'ADR

• Mettez à jour le statut ADR à « Accepted » si ce n'est pas déjà fait.
• Ajoutez la chronologie d'implémentation et la portée finale.
• Incluez la date de démarrage et la date d'achèvement attendue.

Mises à jour de l'initiative BW

Pendant le Scoping (voir Idea-Based Initiatives) :

• Champ Priorité : Définissez à la priorité finale assignée par le leadership.
• Épics enfants : Créez comme enfants Jira de l'initiative, un par équipe ou module.
• Commentaires : Documentez l'engagement exécutif — qui a approuvé, quelle capacité a été allouée, quelle chronologie a été convenue. C'est un enregistrement vérifiable de l'engagement.
• Description : Liez le plan d'architecture de haut niveau dans la description ou via un commentaire.
• Statut idée ARCH : Mettez à jour à « 4️⃣ Scoping & Commitment ».

Critères de sortie

Selon le document funnel :

• Livrables : Plan d'architecture de haut niveau ; épics créés avec portée et approche claires ; les équipes ont complété la décomposition et l'estimation des stories ; les estimations d'équipe agrégées dans la chronologie et l'effort globaux ; priorité d'initiative assignée ; analyse coûts/bénéfices complétée ; engagement exécutif sécurisé ; épics priorisés dans les backlogs d'équipe avec chronologie et allocation de capacité claires.
• Décideur : VP of Engineering / CTO avec accord de synchronisation des stakeholders.
• Décisions possibles : Procéder à l'implémentation / Re-scoper (portée plus petite, re-estimer) / Reporter (conflit de timing, programmer pour trimestre futur) / Décliner.

Les cinq facteurs clés de succès que le document funnel nomme :

1. Le leadership en ingénierie doit explicitement dire « oui, nous faisons cela ».
2. Les équipes doivent avoir de la capacité allouée avec des dates de démarrage/fin claires.
3. La chronologie doit être réaliste compte tenu de la capacité et des dépendances.
4. Les épics doivent être priorisés dans les backlogs d'équipe pour que les équipes sachent quand extraire les stories dans les sprints.
5. Les équipes doivent posséder leur décomposition de stories.

Ce que cette phase transmet à la Phase 5

Quand vous passez à l'implémentation (via Skill(coordinating-implementation-across-teams)), la phase de période de soutien du Work Transition Playbook commence. Les conseils du côté d'origine — comment nous vous utiliser et comment ne pas vous utiliser — sont dans Skill(running-work-transitions). Lisez-le avant que l'implémentation commence ; c'est le même playbook que les équipes réceptrices lisent.

Erreurs courantes

• Écrire les stories de l'équipe. Déjà nommé ; nommé à nouveau car c'est le mode de défaillance.
• Traiter l'engagement exécutif comme la fin du Scoping. Sans priorisation opérationnelle, l'engagement exécutif est théorique.
• Accepter des réunions de passation qui sont raccourcies. La passation est le lieu pour les questions inconfortables. Plus court que 1 heure signifie que quelque chose n'a pas été dit.
• Gonfler le cas coûts/bénéfices. Le leadership en ingénierie le détectera, et la prochaine initiative paiera pour la perte de crédibilité.
• Ignorer la section « documentation needs » du plan d'architecture. Alors la documentation est écrite à la fin, quand les schémas ont déjà dévié.
• Agréger les estimations d'équipe sans adhésion d'équipe. Si une équipe ne croyait pas son estimation quand elle l'a donnée, elle ne livrera pas non plus.

Référence

• Software Initiative Funnel §4 — description de phase canonique, structure de réunion de passation, priorisation opérationnelle.
• Work Transition Playbook — processus de passation canonique ; cette phase est le côté d'origine des phases 1–2.
• Idea-Based Initiatives — comment mettre à jour l'initiative BW à travers le Scoping.
• Architecture / Engineering Operating Model — comment le portfolio d'initiatives est priorisé par rapport à d'autres travaux d'architecture.
• Connexes : Skill(shepherding-an-initiative) pour le playbook parapluie ; Skill(running-work-transitions) (dans bitwarden-delivery-tools) pour la mécanique de passation du côté d'origine ; Skill(coordinating-implementation-across-teams) pour ce que le Scoping alimente.