navigating-the-initiative-funnel

Bitwarden 通过软件计划漏斗开展跨领域技术工作。每项计划都由一位高级工程师负责推进——跨团队计划通常由 Staff 级别及以上的工程师担任，小范围工作（大部分限于一个团队的领域内）有时由技术负责人担任——依次经过五个阶段：识别、调研、概念验证、范围界定与承诺，以及实施。技术负责人全程参与，但主要投入在范围界定与承诺、实施这两个阶段。本技能是这项工作的实用指南，视角是一位与另一位独立的推进负责人合作的技术负责人；如果技术负责人同时也是计划的推进负责人，请阅读两个角色对应的阶段说明并同时履行两个角色。需要查阅权威参考资料时，请通过 get_confluence_page MCP 工具获取漏斗页面；本文档是实际操作摘要。

职责归属原则

每个阶段都有一句需要牢记的话：推进负责人对计划负责；技术负责人对团队如何执行自身部分负责。一旦这条界线变得模糊，就会出现两种失败模式之一——要么推进负责人开始编写团队的工作项（团队因而不再对工作负责），要么技术负责人开始做不属于自己的跨团队决策（计划因此偏离方向）。

按阶段划分：各自的职责

阶段 1 — 识别

推进负责人创建一个 BW Initiative issue，记录问题，并获得工程领导层的继续／停止决定。

技术负责人的职责较轻。 如果推进负责人因团队领域受到影响而联系你，请提供背景信息、已知历史和相关方信息。指出此前的尝试。不要预先界定范围——调研尚未开始。

阶段 2 — 调研

推进负责人访谈相关方（技术负责人很可能是其中之一）、调查代码库，并编写一份包含 2–4 个解决方案选项的架构评估。

技术负责人的职责： 做好访谈。分享团队的痛点、变通方案，以及推进负责人从外部看不到的限制条件。尽可能量化（“这会导致每个迭代大约出现 3 个 bug”）。如果推进负责人提出的方向会与团队路线图上已有的工作冲突，现在就指出来——不要等到承诺之后才提。

阶段 3 — 概念验证

推进负责人选择一个 PoC 领域（有时位于团队的代码库中）、构建一个框架或示例、向架构委员会演示，并起草一份 ADR。

如果 PoC 位于团队的代码库中，技术负责人的职责： 指定一位团队成员作为联系人，与推进负责人结对合作或审查其 PR。做协作者，而不是守门人。PoC 的目的是在真实代码中验证可行性——如果实现有所取巧，这是值得指出的信号，但不要把 PoC PR 当作生产代码评审来对待。直接向推进负责人指出对方案的顾虑；不要悄悄上线变通方案。

阶段 4 — 范围界定与承诺

这是最依赖技术负责人参与的阶段。引导人会在 BW 计划下创建子史诗（通常每个团队或主要模块一个），撰写史诗描述，并安排交接会议。之后，由团队负责拆解工作。

交接时，引导人会带上：PoC 的调查结果、架构计划中与团队相关的部分、成功标准，以及用于问答的时间。技术负责人会带上：问题、对这项工作如何融入团队现有路线图的现实判断，以及完成拆解的承诺日期。

交接后，安排一次团队拆解会议。由团队创建故事，而不是引导人。遵循漏斗的故事质量规则：

• 具体明确。 “将 user-service 错误处理迁移到新模式”胜过“更新错误处理”。
• 编写验收标准，明确什么算完成。技术方案可参考 PoC PR 或架构计划。
• 注明依赖关系，尤其是跨团队依赖。这些信息应反馈给引导人，以便协调。
• 分配给团队，而不是个人。 个人分配应在冲刺规划时进行。
• 添加标签以便筛选（例如 initiative-typescript-migration），这样引导人的仪表板就能跟踪进度。
• 按团队的常规流程估算规模。 不要为计划工作另创一套估算方法。

拆解完成后，将结果分享给引导人。他们会检查拆解是否符合计划愿景，而不是重写故事或事无巨细地管理。可能会问：“看起来不错，但用的是回调，而不是 PoC 中的 async/await 模式——这是有意为之吗？”这就是引导人在履行职责。技术负责人的职责是给出有说服力的答复。

技术拆解模板是本阶段的权威文档。 漏斗会向团队移交一份史诗；团队则据此产出一份技术拆解。拆解文档存放在 bitwarden/tech-breakdowns 仓库中，该仓库顶层的 README.md 介绍了各团队文件夹的约定。模板文件有两个：templates/breakdown.md 及其配套文件 templates/tasks.md。可从现有的本地克隆读取（如果路径不明显，请询问用户文件夹的位置），也可以克隆仓库来获取：

git clone https://github.com/bitwarden/tech-breakdowns.git

如果克隆失败（该仓库是私有的，因此未经身份验证的克隆会返回 404），请让用户使用其凭据克隆仓库，并分享本地路径。根据仓库 README 中的约定，将两个模板文件复制到团队文件夹中，并填写模板定义的各个部分。引导人在上文提到的“分享拆解结果”时，会审核这份拆解文档。

在计划进入实施阶段之前，工程领导层必须明确承诺投入产能——具体分配到具体冲刺。没有这项承诺，就不要将史诗纳入待办列表。 只有高层承诺而没有实际优先级安排，就是导致史诗滞留在待办列表中、始终无法进入冲刺的失败模式。

阶段 5 — 实施

团队开始执行。协调人负责跨团队协调、解答方案相关问题、审核 1–2 个早期 PR 以确保方向一致（而非进行详细代码审查），并向领导层汇报进展。

技术负责人的持续职责：

• 每两周与技术负责人同步，参与者包括协调人和其他受影响的团队。轮流汇报进度、阻碍、跨团队依赖和新出现的问题。时长为 30–45 分钟。
• 留意团队内部是否偏离方向。 如果工程师在不同 PR 中对模式的理解不一致，就要完善指导，不要等协调人来发现。
• 标记新出现的问题。 如果团队遇到的问题表明 PoC 没有覆盖实际生产环境中的问题形态，就要提出。协调人可以将问题升级至 Architecture Council，并协调暂停或调整方向。最糟糕的结果是三个团队悄悄各自实现不同的变通方案。
• 使用 FAQ 文档。 如果有 #initiative-foo Slack 频道，或协调人正在维护的 FAQ Confluence 页面，就把团队得出的答案发上去，其他团队也会遇到同样的问题。
• 不要停止代码审查。 协调人不会审查团队的 PR。团队仍需在内部进行详细的代码审查。

团队的史诗任务完成后，将其标记为已完成，参与协调人主持的回顾，然后恢复团队的常规节奏。

牢记的两份清单

技术负责人负责、协调人不负责的事项：

• 故事拆分、验收标准和估算。
• 团队内部的详细代码审查。
• 团队的 PR 合并节奏。
• 冲刺规划和人员任务分配。
• 完全处于团队代码库边界内的决策。

协调人负责、技术负责人不负责的事项：

• 计划 ADR 和架构方案。
• 跨团队一致性以及暂停或调整方向的决策。
• 在 Architecture Council 中代表团队。
• 面向领导层的进展说明。
• 就共享依赖与其他团队的负责人沟通。

不属于任一清单的事项，通常是跨团队依赖——这意味着由协调人负责，直到他们明确范围和背景后再将其交回团队。

升级路径

• 产能冲突（团队无法按计划时间表承接史诗任务）：向团队的 EM 和协调人升级。漏斗的范围界定与承诺阶段明确规定应在此协商产能——这才是合适的时机，而不是实施进行到一半时。
• PoC 方案不适用于团队的实际情况： 提交给协调人。如果这是根本性问题，协调人会将其提交至 Architecture Council。
• 其他团队偏离模式，且会影响本团队的工作： 提交给协调人。跨团队一致性是他们的职责；技术负责人不应直接与其他团队协商其实施方案。
• 协调人缺席或没有回应： 漏斗指出，协调人应为长期缺席指定备份人选。如果没有，就向工程领导层升级，不要悄悄自行填补空缺。

常见错误

• 照单全收协调人编写的故事。 如果团队没有进行自己的拆分会议，就不算真正负责这项工作。即使感觉重复，也要重新进行拆分。
• 把交接当作走形式。 交接会议是提出棘手问题的时机。如果 PoC 模式看起来有问题，交接时处理代价低，合并后处理代价高。
• 任由偏差不断累积。 微小差异会不断叠加。要在最初的 1–2 个 PR 中发现，而不是等到最后 10 个。
• 在分配产能前就开始工作。 没有明确冲刺安排、直接进入待办列表的史诗任务，往往会就此搁置。这需要与领导层沟通，而不是靠个人逞强解决。
• 过度依赖协调人。 他们要协调 5 个以上的团队。团队详细的代码质量、冲刺纪律和内部决策仍由团队负责。

参考

• 软件倡议漏斗 — 按阶段编写的权威文档。需要完整模板、继续／停止标准或示例时间线表时，请通过 get_confluence_page 获取。
• 相关内容：bitwarden/tech-breakdowns，其中包含团队用于起草第 4 阶段产出内容的技术拆解模板（如何使用该模板，请参阅上文的第 4 阶段）；Skill(running-work-transitions)，介绍交接双方第 4 阶段到第 5 阶段的过渡机制；Skill(architecting-solutions)，介绍拆解工作中需要运用的架构判断。