coordinating-implementation-across-teams

面向计划推动者的第 5 阶段（实施）深入操作指南。你不负责实施。 你的职责是为团队提供支持、保持一致性、确保计划顺利完成，并在完成后退到一旁。时间投入：日历时间为 2–6 个月，每月投入 10–20 小时推动者时间。本指南在 bitwarden-delivery-tools 中组合使用 Skill(running-work-transitions)，涵盖 工作交接操作指南 中发起方的支持期、脉搏检查、回顾和收尾阶段。

漏斗文档中的思维模型：

推动者应当是：

• 确保各团队与计划愿景保持一致的引导者
• 管理跨团队依赖和沟通的协调者
• 随时解答方案相关问题的主题专家
• 向领导层汇报进展情况的报告者
• 而不是 微观管理日常工作的项目经理
• 也不是 对每个 PR 都进行代码审查的人（除非确实需要验证方案）

建立沟通渠道（实施开始前）

在团队开始工作前，先设置协调机制。漏斗文档规定：

• 可选的专用 Slack 频道（例如，#initiative-typescript-migration）。置顶以下链接：PoC PR、ADR、架构计划、Jira 仪表板。用于各团队之间提问、报告阻碍和分享经验。
• 每两周一次的技术负责人同步会议，邀请所有受影响的技术负责人参加。时长 30–45 分钟。按顺序轮流讨论：进展、阻碍、问题和跨团队依赖。
• 可选的答疑时段（每周 1–2 小时，供大家随时提问），也可以使用公司范围的答疑时段。
• 每月一次的利益相关者同步会议更新，面向工程和架构领导层——15 分钟，汇报状态 / 完成百分比 / 风险 / 待决策事项。

宣布频道时，明确说明响应时间预期：“Slack 中的问题——尽量在 1 个工作日内回复。架构方面的问题——当天回复。”

启动会议

团队准备就绪后（已分配产能，故事已纳入 Sprint 规划），召集所有团队召开 1 小时的启动会议。根据漏斗文档：

• 回顾计划。 说明问题、解决方案和 PoC 结果，帮助未参加交接会议的工程师了解情况。
• 介绍方案和关键模式。PoC PR 是你手上最好的教学材料。
• 审查跨团队依赖。 将依赖关系明确展示出来，让团队知道自己在等谁，以及谁在等自己。
• 介绍沟通渠道和节奏。 说明不同情况应使用哪些渠道，以及预期的响应时间。
• 回答问题并解决疑虑。
• 庆祝启动。

在 Slack 频道中分享一套资源：PoC PR、ADR、架构计划、常见问题解答（初始为空）、你的可用时间和响应时间。

执行期间为团队提供支持

根据漏斗文档，需要开展四项工作：

1. 回答问题

• 在 Slack 频道中尽量于 1 个工作日内回复。
• 文字交流不足以说明问题时，安排 Meets。
• 澄清 PoC 未涵盖的边界情况或场景。
• 提供示例或类似实现的参考资料。

2. 审查一致性（而非详细代码审查）

这是第 5 阶段最常被违反的规则。漏斗文档对此毫不含糊：“详细代码审查要信任各团队——仅在方案问题上介入。”

• 关注与计划相关的 PR。
• 审查每个团队早期 PR 中的方案，确保其与 PoC 模式一致。
• 只针对偏离方案的情况提供反馈，不要评论风格、命名、测试覆盖率或团队审查者负责的其他事项。
• 漏斗文档中的示例模式：“这看起来不错，但使用了回调，而不是 PoC 中的 async/await 模式——这是有意为之吗？”

navigating-the-initiative-funnel 中的“不是团队 PR 的审查者”同样适用于此处：技术负责人希望你不要充当其团队的代码审查者。请尊重这一点。

3. 排查意外问题

当团队遇到规划时未预料到的问题时：

• 协助诊断：是实施问题，还是方案问题？
• 如果是方案问题，且需要进行根本性调整，则上报架构委员会。
• 将解决方案记录在常见问题解答中，供其他团队借鉴。

4. 排除依赖阻塞

• 跟踪哪些团队正在等待其他团队（通过仪表板和每两周一次的同步会）。
• 协调存在依赖关系的团队之间的沟通。
• 如果无法在团队层面解决阻塞，则上报工程领导层。
• 如果原计划被证明存在问题，则调整安排顺序。

保持跨团队一致性

漏斗文档称这是“引导者最重要的职责之一”。包含四项子活动：

• 尽早发现分歧。 留意团队对模式的理解是否不同。区分合理差异与误解。审查每个团队早期的 1–2 个 PR，在问题扩大前及时发现。
• 在团队间分享经验。 某个团队解决了常见问题时，在 Slack 中发布。随着模式逐渐显现，更新常见问题解答。指出优秀示例：“团队 X 的 PR #567 展示了处理此边缘情况的简洁方法。”
• 必要时改进指导。 如果团队持续遇到困难，说明指导可能需要改进。更新架构计划或创建补充指南。如果多个团队遇到相同问题，则临时组织工作会议。
• 判断哪些差异可以接受。 根据具体情况，某些差异是合理的（例如：“由于平台限制，移动应用使用变体 A；Web 应使用标准模式。”）。有些差异则属于偏离，会损害一致性。记录这些判断。

跟踪和报告进度

漏斗文档规定了多种节奏：

每周（内部跟踪）

• 查看 Jira 仪表板：已完成、进行中、受阻。
• 检查 Slack 频道中是否有尚未解决的问题或疑虑。
• 记录风险或趋势（例如，多个团队报告了相同的问题）。

每两周一次的技术负责人同步会

• 与所有受影响团队的技术负责人召开 30–45 分钟会议。
• 依次更新：进度、阻塞、问题。
• 协调依赖事项。
• 确定是否需要架构委员会提供意见。

每月领导层更新

在利益相关方同步会上安排 15 分钟。涵盖：

• 状态： 进展顺利／有风险／受阻。
• 完成百分比（已完成的故事数／故事总数）。
• 修订后的时间表（如有需要）。
• 需要升级处理的事项或需要作出的决定。

漏斗文档中的示例表述：

“TypeScript 迁移已完成 60%，6 个团队中有 3 个已完成各自的史诗任务。由于有优先级更高的安全修复，Vault 团队延迟了 2 周。目前仍可按计划在第三季度完成。”

庆祝里程碑

• 第一个团队完成其史诗任务——在 Slack／团队会议上予以表扬。
• 完成度达到 50%——在公司全员大会上更新进展。
• 最后一个 PR 合并——与所有参与者一起庆祝。

管理文档

文档不应等到最后才开始编写。根据漏斗文档：

• 尽早起草。 在实施开始时创建文档结构（大纲／骨架）。
• 逐步补充内容。 随着模式逐渐稳定、各团队产出实际实现，逐步补充文档。
• 请各团队贡献示例，展示他们自己的实现。

根据 Documentation Patterns，文档分为两个存放位置。具体安排如下：

靠近代码（与团队代码一起存放在代码库中）：

• 框架／模式 README.md：随着模式在各团队中逐渐稳定而更新。PoC 的初始框架 README 会随着团队在推广过程中不断积累的发现而演进。
• 文件夹级说明：在各团队采用的目录中添加说明，并指向框架 README 和 ADR。
• 内联文档：根据 Documentation Patterns 中各技术栈的标准编写（TypeScript／Angular／.NET 使用 JSDoc／XML 注释；Rust 使用 rustdoc）。
• CLAUDE.md 更新：在根目录及相关文件夹层级更新新模式会改变工程师（以及 Claude 工具）工作方式的内容。使用 @ 语法链接到包含规范模式的 README.md 文件。

集中存放（位于 bitwarden/contributing-docs，并发布在 contributing.bitwarden.com）：

• ADR 更新——更新最终状态（如果编号方案采用 Implemented，则从 Accepted 改为 Implemented）、经验教训，以及实际时间线与预测时间线的对比。编辑 PoC 期间创建的同一个 ADR 文件；不要新建文件。
• 迁移指南——说明如何从旧模式迁移到新模式。这是关于流程和操作方法的内容，应集中存放，以便在各代码库中查找。
• 贡献指南更新——添加今后应适用于本倡议之外代码的新标准或模式。
• 运行手册——如果本倡议涉及运营或基础设施变更，相关运行手册通常也存放在这里（或视情况存放在 SRE 的文档库中）。

根据漏斗文档安排时间：

• 在 2–3 个团队完成实施后，起草技术指南。
• 在宣布本倡议完成前，完成所有文档。
• 计划在最终 PR 合并前 1–2 周准备好文档。

知识传递

根据漏斗文档，确保本倡议的成果不会随着你的离开而消失。在最后几周：

• 面向整个工程组织举办技术分享或午餐交流会（45–60 分钟），也可安排在开放答疑时段或架构委员会会议上。
• 为新工程师准备入职材料。
• 使用新模式更新团队运行手册。
• 考虑录制视频讲解。

技术分享结构（漏斗文档）：

时间	内容
5 分钟	我们采用的方法及原因
10 分钟	演示或代码讲解
5 分钟	结果和指标
5 分钟	经验教训
5 分钟	问答

30 天回访（Work Transition Playbook 第 4 阶段）

从发起方的角度编写工作交接手册——这是关键检查点，可防止“我们已经交接”变成“从未有人接手”。Work Transition Playbook 明确指出：无论其他部分如何调整，都不应跳过 30 天回访这一阶段。

进行一次 15–30 分钟的谈话，或在异步讨论串中交流。讨论以下内容：

• 团队是否已开始使用交接的材料？如果没有，是什么在阻碍？
• 是否还有未解答的问题，或文档不足的地方？
• 团队是否认可这种做法，还是在绕开它？
• 是否需要调整支持期限？

如果团队完全还没开始，请与接收团队共同升级处理，而不是惩罚对方。是能力不足、优先级冲突，还是交接缺口？先了解情况，再作判断。

中途调整方向

漏斗文档中的示例：实施过程中发现 GraphQL 解析器存在性能问题。负责协调的人员采取了以下措施：

• 立即提交架构委员会。
• 调查期间暂停受影响团队的工作。
• 与一个团队合作，测试修订后的方案。
• 根据新发现更新指南。
• 清晰沟通：“暂停，不要放弃，我们正在解决这个问题。”
• 如有需要，延长时间线。

经验是：善于协调也意味着懂得何时暂停、调整并沟通，而不是一味推进。

完成与收尾

退出标准

根据漏斗文档，满足以下条件时，计划即告完成：

• 所有用户故事均已完成并合并到 main。
• 所有团队的史诗均已在 Jira 中标记为完成。
• 文档已编写、审阅并发布。
• 知识转移已完成。
• 已开展回顾。

回顾（工作交接手册第 5 阶段，约 90 天）

在完成后的 2 周内安排回顾，趁记忆犹新时进行。时长为 1.5 小时，由你和所有受影响团队的技术负责人参加。根据漏斗文档中的议程：

• 哪些方面进展顺利？ 有效的流程、成功的协调、值得重复的做法。
• 哪些方面本可以做得更好？ 摩擦点、延误、错误假设，以及今后应采取哪些不同做法。
• 流程改进。 沟通调整、范围界定或估算变更。
• 对工作的理解是否充分，足以支持执行？ 哪些团队的估算比较准确？哪些偏差较大？是什么导致了差异？

记录发现和待办事项。根据经验教训更新漏斗流程文档——负责协调的人员补充所学内容后，Bitwarden 的漏斗流程会变得更好。

收尾（工作交接手册第 6 阶段）

• 在 Jira 中将 BW 计划标记为完成。
• 归档 Slack 频道（或将其设为只读，以供参考）。
• 确保所有文档都易于查找。
• 更新相关运行手册或入职材料。
• 根据经验教训提交任何漏斗流程改进建议。
• 在 JPD 中将 ARCH 创意状态更新为最终完成状态。

公开表彰贡献者（全员大会、Slack），在绩效评估中予以认可；如适合，还可发布案例研究文章。

工作交接手册中关于收尾的原则同样适用于此处：收尾后不要以“以防万一”的名义继续留任审查者——这是一种不愿放手的委婉表现。

影响衡量（完成后 3–6 个月）

根据漏斗文档，重新审视范围界定期间确定的成功指标：

• 定量指标（如有定义）：前后 Bug 数量变化、性能提升、节省的时间。文档中的示例：“预计错误处理 Bug 减少 30%；实际减少 42%。”
• 定性反馈： 调查各团队——新模式是否优于旧模式？哪些方面有效，哪些无效？
• 采用情况跟踪： 新代码是否遵循该模式？各团队是否默认采用新方案？是否又转回旧模式？

记录结果：

• 更新 ADR，注明实际结果与预测结果的对比。
• 在架构计划中添加影响摘要。
• 与工程部门分享结果。

BW 计划的更新

在实施期间（参见基于创意的计划）：

• 状态跟踪主要通过子史诗及其用户故事进行——无需频繁更新计划本身的字段。
• 评论： 记录重要的协调事件——跨团队依赖关系的解决、中途调整、里程碑达成、升级处理。评论会形成叙事时间线，供回顾时使用。
• 链接： 随着新工作出现，添加相关工作链接——运维工单、Bug 报告、文档页面、相关计划。
• 描述： 仅在范围或方案发生实质性变化时更新。
• ARCH 创意状态： 启动时更新为“5️⃣ 实施”，完成时再更新为最终状态。

常见错误

• 进行详细的代码审查。 你不是团队的审查者，只需确保方案方向一致。
• 任由偏差累积。 在每个团队的第 1–2 个 PR 中发现偏差，而不是等到第 10–20 个 PR。
• 跳过 30 天脉搏检查。《工作交接手册》明确指出，这是承重检查点。跳过它，隐性的失败模式就会变得不可见。
• 把文档当作收尾阶段的产物。 实施过程中，模式与文档记录之间会出现偏差。应逐步编写文档。
• 因为团队没有接手，就悄悄恢复工作。 根据手册，这需要通过领导层沟通解决，而不是展现个人英雄主义的机会。
• 在工作结束后迟迟不离场。 将工作交还给团队的常规节奏，然后退出。这个信号很重要。
• 跳过回顾。 这是唯一能改进整个流程的机制。

参考资料

• 软件计划漏斗 §5 — 阶段的权威说明，以及成功、遇到问题和调整方向的实施示例。
• 工作交接手册 — 六阶段交接流程的权威说明；漏斗的第 5 阶段对应发起方在支持期内直至工作结束的部分。
• 文档模式 — 贴近代码与集中式 contributing-docs 的做法、针对不同技术栈的最佳实践，以及 CLAUDE.md 约定。
• 基于想法的计划 — 如何在实施过程中更新 BW 计划。
• 相关内容：Skill(shepherding-an-initiative)，涵盖整体手册；Skill(running-work-transitions)（位于 bitwarden-delivery-tools），提供发起方支持期指南；Skill(scoping-and-handing-off-to-teams)，介绍将工作交接到本阶段的前置阶段。