running-work-transitions

Bitwarden 使用 Work Transition Playbook 在团队之间移交逻辑、模式、工具或流程的所有权。最常见的触发时机是一项计划的第 4 阶段 → 第 5 阶段：负责引导的人员完成了范围界定与承诺阶段，而某个团队即将负责实施。但此手册适用于各种情况——Platform 可能会将框架移交给产品团队，SRE 可能会移交运行手册，另一个产品团队也可能会转交不再由其负责的集成。无论移交方向如何，都适用同一套手册。

此技能涵盖移交的双方。它与 Skill(navigating-the-initiative-funnel) 互为补充，后者更全面地介绍了漏斗流程。

“移交”的真正含义

阅读手册中的这句话，并确保双方团队都据此行动：成功的移交并非分享文档或召开会议的时刻，而是接收团队能够充满信心地独立开展所移交工作之时。

下面六个阶段的所有内容都是为了实现这一结果。沟通会议、文档和进度检查都是手段，而非目标。

你属于哪一方？

• 接收方。 另一个团队正在移交工作。接收团队通常由一位指定的主要联系人代表（手册明确指出，这通常是技术负责人或高级工程师）。其职责是评估移交内容、为团队做好接手准备，并确保支持期高效开展。
• 移交方。 某个团队正在向另一个团队移交工作。例如，团队构建了旨在供其他团队采用的框架或模式；团队引导了一项范围较小的计划，直至由另一个团队实施；或者运营职责发生了转移。其职责是准备相关材料，让接收团队能够独立开展工作，并在接收团队接手后提供支持，而不是主导工作。

双方经历的阶段相同，但职责不同。如果参与者在同一项工作中的不同阶段分别属于双方（在引导与单个团队关系密切的计划时很常见），请阅读两部分内容。

接收方视角下的六个阶段

阶段 1 — 准备

在安排任何交接会议之前，发起团队要准备好材料。接收团队的职责是在接受交接前评估这些材料。

需要确认：

• 文档足够完善。 接收团队的一名合格工程师应能依据文档独立处理相关内容。如果文档过于简略，应提出异议——不要接受团队无法持续维护的交接。
• Jira 内容清晰易懂。 史诗的摘要应具有描述性。用户故事的详细程度应足以供接收团队进一步细化——不能具体到团队只是接手一份预先编写好的冲刺计划，也不能模糊到团队必须重新研究范围。
• 已确定利益相关者和联系人。 接收团队知道发起方中哪些人掌握着支持期内可能需要的背景信息。接收团队也知道哪些相关利益方（领导层、PM、其他团队）会关注进展。
• 接收方已指定一名主要联系人（POC）（通常是技术负责人，有时是高级工程师）。工程经理（EM）知情并表示支持。
• 如实评估交接后的工作量。 只考虑“采用新事物”的交接会低估实际成本。请明确评估以下三个方面：
  • 实施与集成。 要在接收团队的领域内落实交接内容，需要投入多少工作？包括调整模式、接入集成、编写测试、更新工作流。
  • 逐步淘汰旧流程和代码。 如果新工作会替代现有内容，淘汰旧内容本身也属于工作范围。接收团队通常最了解旧方案在实际运作中的情况——请利用这一点。
  • 持续维护和缺陷修复。 支持期结束后，哪些内容由谁负责？对于大多数交接，接收团队负责维护所有已采用的内容。对于共享框架或库，发起团队可能仍负责部分维护——请明确确认所有权边界。

如果其中任何一点不清楚，现在就提出来。准备阶段是填补空缺成本最低的时候。

阶段 2 — 交接会议

至少安排两次会议，间隔 1–2 周。接收团队的职责是做好准备参加会议，并在第二次会议时带着更有针对性的问题回来。

• 会议 1（背景和方法）。 会前查看文档——最好提前几个工作日。在会议中：了解要解决的问题、选择这种方法的原因、了解 PoC 或框架，并弄清这项工作如何融入更广泛的计划。开放问答。本次会议以倾听为主。
• 会议 2（实践操作和规划）。 到这时，接收团队应该已经花时间了解代码或工具。带上只有在阅读实际实现后才会产生的问题。讨论团队将如何集成、扩展或安排这项工作。指出文档中的缺漏。就支持期的安排达成一致。

对于复杂或影响重大的交接，应安排更多会议。第二次会议结束时，双方共同决定是否需要继续安排会议。

阶段 3 — 支持期

会议结束后，原团队仍会随时提供支持，但角色从主导转为支持。典型时长：4–8 周，视复杂程度而定。

原团队可以提供哪些帮助：

• 解答方法、意图以及文档未涵盖的边缘情况相关的问题。
• 审阅早期 PR，确保方向一致——趁修正成本还低时，及时发现与预期模式不符之处。
• 如果生产环境的实际情况表明原方案需要调整，帮助评估可选方案。

哪些事情不应由原团队承担：

• 把关接收团队的工作。原团队是顾问，而非审批者。
• 替接收团队完成工作。交接是转移，而非借调。

手册中的一个关键表述：交接完成并不意味着接收团队会立即开始工作。转移过来的工作需要与团队现有优先事项竞争，包括产品路线图承诺、其他计划、Bug 和技术债务。交接与正式开展工作之间存在延迟是正常且可预期的。

**不正常的情况：**接收团队尚未将其列为优先事项，原团队却悄悄重新接手工作。这需要由两个团队与工程领导层共同讨论，而不是通过变通方式解决。在漏斗的“范围界定与承诺”阶段会分配管理层的资源；如果这项承诺没有转化为优先工作，就应该升级处理，而不是让原团队填补空缺。

阶段 4 — 跟进检查（交接后约 30 天）

进行一次 15–30 分钟的沟通，或在异步讨论串中交流。这是至关重要的检查点，可以避免“我们已经交接了”演变成“接收团队从未接手”。

需要讨论的问题：

• 接收团队是否已开始使用转移过来的材料？如果没有，是什么在阻碍团队？
• 是否还有未解答的问题，或文档不足以覆盖的领域？
• 团队是否认可这一方法，还是在绕开它，而这可能表明双方的预期不一致？
• 支持期是否需要调整——延长或缩短？

如果团队完全没有开始，就应该升级处理，而不是追究责任。了解原因究竟是资源不足、优先级冲突，还是交接中确有缺漏。如果不加以处理，计划工作就可能在此处夭折。

阶段 5 — 回顾会议（交接后约 90 天）

召开一次 45–60 分钟的正式会议，由两个团队共同参加。目标：评估采纳情况、收集对交接流程的反馈，并为后续交接总结经验。

讨论主题：

• 采纳情况评估。 工作是否按预期使用？接收团队是否在此基础上进行了扩展？是否存在偏离或未采纳的部分？
• 交接流程反馈。 哪些环节有效？文档、会议或支持期还缺少什么？怎样做会更顺畅？
• 后续交接的经验教训。 手册本身有哪些内容应该调整？
• 未解决的缺口。 尚未解决的问题、需要补充的文档以及需要进一步提供的支持。

记录总结结果。如果回顾中发现流程有待改进，就将改进内容补充到手册中——Bitwarden 的交接会随着团队总结并补充经验而不断完善。

阶段 6 — 收尾

满足以下条件时，交接即告完成：

• 接收团队能够独立开展转移过来的工作。
• 支持期已结束（或经双方明确同意提前结束）。
• 已召开回顾会议并记录总结结果。
• 未完成的行动项均已明确负责人和时间安排。

收尾时，应正式确认交接完成。两个团队都需要收到这一信号：接收团队已能自主开展工作；除非原团队被明确要求重新参与，否则不再承担相关责任。

原团队视角下的六个阶段

阶段 1 — 准备

交接团队准备接收团队将要依赖的材料。标准不是“任何人知道的一切都写在了某处”，而是“接收团队中一位称职的工程师可以独立上手并开展工作”。

需要准备的材料：

• 说明方案、模式和关键决策的技术文档。 尽量引用现有 ADR、架构规划和 PoC 拉取请求，而不是重复编写；但要确认引用内容是最新的且可以访问。
• 清晰说明交接内容，以及接收团队预期达到的最终状态。 不要让他们从一堆资料中反向推断范围。
• 明确记录已知限制、边缘情况和有意做出的权衡。 这些内容最值得记录，因为日后最难还原。谨慎的读者可能会感到意外的内容都应写在这里。
• Jira 组织。 Epic 的摘要应清楚说明接收团队负责领域的范围和预期成果。Story 的粒度应便于接收团队进一步细化——不要预先写好冲刺计划，也不要只写模糊的占位内容。在 Epic 描述中链接 PoC PR、ADR 和辅助文档。
• 利益相关者名单。 在交接团队一侧，列出参与制定方案的人（负责人、架构委员会评审者、领域专家）以及他们掌握的背景信息。还要列出关心进展的利益相关者（工程管理层、依赖此工作的 PM、相邻团队）。告知这些人员交接正在进行，并通过进度检查和回顾持续让他们了解情况。

然后，与接收团队一起诚实评估交接后的工作量——不要替他们评估。手册指出，交接团队最适合根据 PoC 经验估算以下三个方面，但接收团队必须结合自身系统的实际情况进行验证：

• 在接收团队的领域中进行实现和集成。
• 逐步淘汰新工作所取代的旧流程和代码——隐藏成本往往就在这里。
• 支持期结束后的持续维护责任。默认情况下，接收团队负责维护其采用的一切。对于共享框架，交接团队可能会继续承担部分维护责任——务必明确确认责任边界。

在准备阶段、过渡会议开始前就明确这些成本，可以让双方以切合实际的预期进入交接流程。这也有助于接收团队的 EM 规划产能，避免到了冲刺中途才发现交接工作比预想的更多。

阶段 2 — 过渡会议

由交接团队主持会议。至少举行两次，间隔 1–2 周。

• 会议 1（背景和方案）。 至少提前几个工作日分享材料，让接收团队能够独立审阅。会议中：介绍要解决的问题以及选择该方案的原因（原因和内容同样重要），讲解 PoC 或框架，说明这项工作如何融入更广泛的计划或战略，列明约束和权衡，并留出时间进行开放问答。
• 会议 2（动手实践和规划）。 此时接收团队已经花时间熟悉了代码。预计他们会提出更深入的问题。解决他们独立审阅时发现的空缺，讨论他们计划如何集成或安排这项工作，找出需要补充文档的地方，并商定支持期的安排。

在会议 2 结束时共同决定是否需要增加会议。对于复杂或影响重大的工作，通常确实需要。

第 3 阶段 — 支持期

原团队从主导转为提供支持。典型时长：4–8 周，具体时长与复杂程度相称。核心理念：随时可以联系，但不承担具体任务。

支持期内原团队的工作：

• 保持异步可联系——通过 Slack、PR 评论等方式，解答有关方案、意图或边缘情况的问题。
• 审查接收团队提交的 1–2 个早期 PR，确认其与预期模式一致。**不是充当把关人。**趁偏差还容易纠正时及时发现。
• 如果生产环境中的实际情况暴露出原方案未预料到的问题，帮助评估可选方案。不能让接收团队只能靠猜测来判断原意。
• 如果需要延长或缩短支持期，坦诚沟通。需要更多时间并不代表失败。

原团队不应该做的事：

• 因为接收团队尚未将其列为优先事项，就悄悄重新接手这项工作。本手册对此有明确说明：交接后到正式开始工作之间出现延迟很正常。如果出现明显延迟，正确做法是由原团队、接收团队和工程领导层共同讨论优先级是否一致，而不是悄悄重新接手，从而让最初的所有权归属卷土重来。漏斗中的范围界定与承诺阶段已确立高管层的承诺；如果这项承诺没有转化为优先安排的工作，就应该作为领导层议题进行讨论，而不是成为逞英雄的机会。
• 把关代码合并。详细的代码审查应由接收团队负责，就像他们领域中的其他代码一样。
• 增加范围。交接是转移已确定范围内的工作，不是邀请对其进行扩展。

关于交接时机的一点实用建议：如果原团队知道接收团队要过一段时间才会开展这项工作，可以考虑将正式会议推迟到接收团队准备就绪前，因为上下文会逐渐淡化。但一般建议是在工作准备好交接时举行会议（此时上下文最鲜活），并将接收团队开始积极开展工作时视为支持期的起点。如果间隔时间较长，在接收团队开始工作时安排一次简短的重新介绍，就能恢复上下文，也不必让原团队持续参与。

第 4 阶段 — 进展检查（交接后约 30 天）

原团队参与。与接收方要回答的问题相同——工作是否已经开始、文档是否充分、支持期时长是否合适、团队是否在以一些可能表明方案不匹配的方式绕过方案开展工作。

如果进展检查发现工作完全没有启动，此时应与接收团队共同升级处理——不是为了追责，而是为了了解问题出在产能、优先级冲突，还是交接本身存在不足。如果不加以处理，主动发起的工作就会在此处夭折。

第 5 阶段 — 回顾总结（交接后约 90 天）

原团队参与。两支团队共同进行，时长为 45–60 分钟。目标：评估采纳情况，收集对交接过程的反馈，并总结未来交接的经验教训。

原团队最有价值的产出，是坦诚承认文档、会议或支持中有哪些未能涵盖的内容。流程改进应反馈到手册本身——各团队补充经验后，Bitwarden 的交接流程就会不断完善。

第 6 阶段 — 收尾

原团队确认交接已完成，并退出参与。这个信号很重要：接收团队已具备自主能力，除非明确再次邀请原团队参与，否则原团队的参与已结束。收尾后不要以“以防万一”为由继续担任审查者——这是一种委婉的不肯放手。

调整操作手册

六个阶段描述的是一个通用流程。请根据工作规模调整——这对交接双方都适用：

• 较小的交接（单一模式、范围有限）：压缩时间线。脉搏检查可以采用 Slack 讨论串；回顾可以并入常规团队回顾。
• 较大的交接（涉及多个团队、复杂度较高）：预计需要两场以上会议、更长的支持期，以及更正式的回顾。
• 紧急交接（离职、重组）：必要时压缩准备时间，但不要跳过支持期或后续检查点。大部分价值都体现在这些环节中。

无论规模如何，有一件事不应跳过，那就是 30 天脉搏检查。其他环节都可以按规模调整；这项检查能防止问题悄无声息地发生。

常见错误

接收方：

• 在文档不充分时接受交接。 接收团队会在实施过程中为此付出代价。应在准备阶段提出异议。
• 把会议当作目标。 会议只是手段。如果 90 天后接收团队仍无法独立运作，那么无论开了多少场会，交接都算失败。
• 对产能问题不作回应。 “有空时我们会接手”就是交接失败的原因。如果没有分配产能，应在交接前与领导层沟通，而不是事后再谈。
• 悄悄绕开已移交的方法。 在脉搏检查中发现偏离，比在生产事故中发现更容易解决。应及时指出。
• 让原团队重新接手工作。 如果接收团队无法确定优先级，应向领导层升级。不要接受会让原所有权模式重现的帮助。

发起方：

• 文档尚未准备好就开始开会。 为弥补文档不足而召开的会议，最终只会产生一份待办清单。先准备材料，再安排会议。
• 填补本应由接收团队升级处理的产能缺口。 如果接收团队没有优先处理这项工作，正确做法是与领导层沟通对这项工作的承诺，而不是悄悄继续投入。这会削弱所有权的转移。
• 跳过退役成本评估。 相比原团队，接收团队往往更了解旧事物在实际中究竟发挥什么作用。应明确规划停用工作。
• 把支持期当作所有权延续。 在此阶段，原团队是顾问。评审是为了保持一致，而不是为了审批。合并工作不由原团队负责。
• 结束后仍迟迟不退场。 “再观察一阵子”是拒绝放手的委婉说法。应让接收团队明确知道何时可以自主运作。
• 跳过回顾。 这是改进操作手册的唯一机制。如果某些环节进展不顺，应在回顾中提出，以便后续交接受益。

参考资料

• 工作交接操作手册 — 权威版本。通过 get_confluence_page 获取完整的逐阶段详情、汇总表和调整指南。
• 相关内容：Skill(navigating-the-initiative-funnel)，了解经常触发交接的计划背景；Skill(architecting-solutions)，了解评估移交内容时（无论方向如何）应采用的架构判断。