shepherding-an-initiative

面向全流程的总括性操作手册，供倡议负责人使用，涵盖 软件倡议漏斗 的全部五个阶段：识别 → 研究 → 概念验证 → 范围界定与承诺 → 实施。说明每个阶段的投入、交付物和决策关卡；明确负责人产出什么，以及哪些工作要移交给团队。需要查询准入／退出标准或完整模板详情时，通过 get_confluence_page 获取规范漏斗页面。

所有权规则（全程遵守）

倡议由你负责。每个接手团队负责如何执行各自的工作。

每个阶段都有一句需要牢记的话：当你开始编写团队的用户故事时，这项工作就不再由团队负责。停止协调团队之间的工作时，倡议就会偏离方向。这两种情况都由你负责防止。

如需了解同一边界的中立于 Agent、面向团队的视角（技术负责人阅读的版本），请在 bitwarden-delivery-tools 中调用 Skill(navigating-the-initiative-funnel)。阅读这两种视角，有助于你准确把握界限。

时间与投入预期

漏斗页面设定了以下基准。这些并非理想化目标，而是领导层询问“负责推进这项倡议要花多少成本？”时进行容量规划的依据。

阶段	时长	负责人投入	决策者
1 — 识别	~1 周	4–8 小时	全局工程领导层
2 — 研究	3–5 周	40–80 小时	工程领导层 + 架构委员会
3 — 概念验证	2–4 周	40–80 小时	工程领导层 + 架构委员会
4 — 范围界定与承诺	2–4 周	30–50 小时	工程领导层（总监级及以上）
5 — 实施	2–6 个月	每月 10–20 小时	团队负责执行；负责人负责协调

总计：一项中型倡议需要在 4–9 个月内投入 150–300 小时的负责人时间——约占一人工作时间的 5–10%，且投入主要集中在研究和概念验证阶段。

分阶段说明：负责人的工作

阶段 1 — 识别

目的： 收集足够的背景信息以便进行有意义的评估，同时避免过早承诺资源。

你负责产出：

• 在 Bitwarden Company（BW）项目下创建一个 BW Initiative 工单。类型：Initiative。经办人：你（拟任负责人）。报告人：提出问题的人。优先级：占位值（“TBD - Awaiting Research”或 Medium）。
• 将上游 ARCH 创意（如果存在）提炼成便于管理层阅读的摘要，而不是照搬完整的 TSI 模板。基于创意的倡议 中提供了模式、链接清单和逐字段指南。
• 在 Jira Product Discovery 中，将 ARCH 创意与 BW 倡议建立一个工作项链接。这是基础性的可追溯链接——每个基于创意的倡议都必须有此链接。
• 添加初始“Relates to”链接：先前尝试、相关的 SRE／BRE／TSD／PM 工单，以及 ARCH 创意自身研究中发现的任何相关内容。
• 在 JPD 中将 ARCH 创意状态更新为“1️⃣ Identification”。

决策关卡： 全局工程领导层决定继续／暂缓／拒绝。

你不应做的事： 预先界定解决方案范围。研究尚未开展。不要急于带着答案入场。

阶段 2 — 调研

目的： 深入了解问题领域，并在确定方向前探索潜在解决方案。

交付成果：

• 3–5 次利益相关方访谈（受影响团队的技术负责人可能是访谈对象）。
• 对代码库中现有实现的现状分析——包括不一致之处、变通方案和技术债务，并尽可能量化其影响。
• 2–4 种有记录的解决方案，并明确说明权衡。
• 在 Confluence 的 EN 空间 assessments 文件夹下创建一份 架构评估，并根据利益相关方的意见进行完善。
• 重大计划可选择在架构委员会预览。
• 将 ARCH 想法状态更新为“2️⃣ 调研”。

决策关卡： 工程领导层根据架构委员会的意见，决定继续进行 PoC / 继续调研 / 暂缓 / 拒绝。

深入技能： Skill(running-an-architectural-assessment)，用于了解利益相关方访谈结构、现状分析、方案生成和架构评估模板。

阶段 3 — 概念验证

目的： 在承诺全面实施前，在 Bitwarden 代码库中验证推荐的解决方案能否在实践中奏效。通过亲自动手试验来降低风险。

交付成果：

• 与负责团队的技术负责人协调选择 PoC 区域——具有代表性，但范围有限（约 1–5 个文件或一个模块）。
• 更大范围推广将复用的框架或基础，以及 1–3 个达到生产质量标准的示例实现。
• 一个或多个 PR（不一定要合并；如果未合并，请在标题中标注“PoC”）。
• 一次架构委员会演示——时长 15–30 分钟，内容包括 PoC PR、研究结果（哪些有效、哪些无效、需要做哪些更改）以及拟议方向。
• 按照 Bitwarden ADR 模板编写一份ADR 草案（状态：Proposed）。ADR 存放在集中管理的 bitwarden/contributing-docs 仓库的 docs/architecture/adr/ 下——各仓库没有单独的 ADR 目录。
• 为框架和示例实现编写邻近代码的文档（遵循文档模式）——在框架代码旁放置 README.md，在示例附近添加文件夹级说明，并在引入新模式时更新 CLAUDE.md。深入技能会说明各类文档的位置（邻近代码 vs. 集中管理的 contributing-docs）分别适用于何种用途。
• 将 ARCH 想法状态更新为“3️⃣ 概念验证”。

决策关卡： 工程领导层根据架构委员会的建议，决定继续进行范围界定 / 修改 PoC / 返回调研 / 拒绝。

深入技能： Skill(running-a-proof-of-concept)，用于了解 PoC 区域选择、框架构建、架构委员会准备工作和 ADR 起草。

阶段 4 — 范围界定与承诺

目的： 将经过验证的 PoC 转化为具体的实施计划，包括工作量估算、团队分配和管理层承诺。

你需要产出：

• 在 Confluence 的 EN-space 规划文件夹中创建高层架构计划：范围、方案（分阶段实施、迁移路径）、团队对齐、依赖项、风险缓解、成功指标、文档计划。
• 在 BW 计划下创建子史诗——通常每个团队或主要模块一个。每个史诗需注明其负责的代码库范围、PoC PR 参考、预期成果和成功标准。
• 为每个接收团队安排一次交接会议（每个团队 1 小时，按 20/15/15/10 分钟安排）：20 分钟介绍，15 分钟问答，15 分钟由团队初步思考任务拆分，10 分钟承诺确定任务拆分日期。
• 在架构计划中记录成本效益分析。
• 在 BW 计划上更新计划优先级（Critical / High / Medium / Low）。
• 向领导层进行演示，寻求明确的继续/停止决定及产能承诺。
• 与工程领导层进行运营优先级排序：目标开始日期、季度、相对于团队其他承诺的优先级、Sprint 产能分配。
• 完成 ADR 定稿（状态：Accepted），并注明时间线。
• 将 ARCH idea 状态更新为“4️⃣ Scoping & Commitment”。

决策关卡： VP of Engineering / CTO。继续实施 / 重新界定范围 / 延后 / 拒绝。

关键反模式： 由你来编写团队的故事。任务拆分应由团队完成，而不是你。你要审查任务拆分是否符合计划的愿景，而不是重写故事。

进阶技能： Skill(scoping-and-handing-off-to-teams)。阶段 4→5 的交接是发起方的工作转换；该技能组合使用 bitwarden-delivery-tools 中的 Skill(running-work-transitions)，处理转换机制。

阶段 5 — 实施

目的： 协调多个团队执行。你负责协调、支持并保持一致性，而不是亲自实施。

你需要产出 / 维护：

• 沟通渠道：可选的 #initiative-<name> Slack 频道，并置顶 PoC PR / ADR / 架构计划 / Jira 仪表板；每两周一次的技术负责人同步会（30–45 分钟）；可选的办公时间；每月一次的利益相关者同步更新。
• 与所有团队召开启动会议（1 小时），回顾问题、解决方案、PoC 结果、依赖项和沟通渠道。
• 提供方案支持——在 Slack 中答疑；文字沟通不够时，安排 Meet；澄清 PoC 未涵盖的边缘情况。
• 对各团队提交的早期 PR 进行一致性审查，而非详细代码审查。团队的 PR 审查仍在团队内部进行。
• 跨团队一致性：尽早发现偏差，判断合理差异与损害一致性的偏离，并维护 FAQ，记录常见问题及解决方案。
• 每周跟踪进度（仪表板 + Slack 频道），每两周召开技术负责人同步会，每月向领导层汇报。
• 逐步编写文档（完成 40% 时起草，完成 90% 时定稿）：技术指南、迁移指南、ADR 最终更新、贡献指南更新，以及适用的运行手册。
• 知识转移——在最后几周安排技术分享或午餐交流会（45–60 分钟）。
• 在完成后的 2 周内进行一次回顾（负责人和所有受影响团队的技术负责人参加，1.5 小时）。
• 在 3–6 个月后，根据范围界定阶段定义的成功指标衡量影响。
• 将 ARCH idea 状态更新为“5️⃣ Implementation”，完成时再更新为最终状态。

进阶技能： Skill(coordinating-implementation-across-teams)。对于阶段 4→5 转换的后续阶段（发起方工作转换手册的阶段 3–6——约 30 天时进行状态检查、约 90 天时进行回顾、关闭），该技能组合使用 bitwarden-delivery-tools 中的 Skill(running-work-transitions)。

跨阶段实践

以下做法适用于所有阶段：

• 保持 ARCH idea 状态同步。 漏斗阶段状态（1️⃣–5️⃣）是架构和工程领导层在 JPD 视图中查看你所负责事项的方式。只更新 BW 事项会导致项目组合层面的信息过时。
• 在 BW 事项上积极添加关联。 关联 SRE/BRE/PM 工单、以往尝试的工单、相关事项，以及出现的运营工单。这份关联清单是你维护的最有价值的成果之一。
• 用 Jira 评论记录时间线。 重要决策、利益相关方反馈、过程中调整方向、跨团队依赖项的解决情况，都应记录在事项评论中。这些内容在回顾时，以及未来负责类似工作的负责人开展工作时，会极具价值。
• 随着方案演进更新事项描述。 它是持续更新的摘要，而非研究文档。详细研究内容应放在架构评估中，实现细节应放在史诗和用户故事中，决策依据则应放在 ADR 中。

当事项的规模小于漏斗的设计范围时

这个漏斗是为真正涉及多个团队的事项设计的。对于主要属于一个团队或一个相邻团队职责范围的事项，技术负责人可以直接通过 bitwarden-tech-lead 牵头，而不必使用此插件。如果你要牵头一个范围较小的事项，可以采用精简版流程：简化架构评估、缩小 PoC、只召开一次交接会议，并在实施期间减少正式的跨团队协调。阶段仍然适用，但产出物可以更精简。

无论范围大小，都必须满足以下最低要求：记录问题、记录决策、在实施开始前明确承诺投入产能，并在结束时进行回顾。

常见错误

• 因为方案看起来显而易见，就直接跳到 PoC。 架构评估能展现团队的专业知识，并明确指出阻力所在。跳过这一步，可能会导致方案在推广时停滞不前。
• 在范围界定阶段编写团队的用户故事。 这样当下会更快，但团队不会真正承担自己没有编写的工作。应坚持完成交接，并由团队拆解工作。
• 进入第 5 阶段，却没有进行运营优先级排序。 高管承诺（“是的，就做这个”）是必要条件，但并不充分。如果没有目标季度、产能分配，以及团队待办事项中的相对优先级，史诗就会搁置。
• 审查每个 PR。 你不是团队的审查者。尽早审查 PR，确认方案方向一致；代码质量则应信任团队。
• 任由 ARCH idea 状态过时。 项目组合视图依赖此状态。每次阶段转换时都要更新。
• 跳过回顾。 这是唯一能改进漏斗本身的机制。每个事项的经验教训要么反馈到流程中，要么就会被重新摸索一遍。

参考资料

• 软件项目漏斗 — 各阶段的权威文档。需要完整模板、进入/退出标准或示例时间线表时，通过 get_confluence_page 获取。
• 基于想法的项目 — BW Initiative 架构、描述模板、链接约定和各阶段项目演进的权威参考。
• 工作交接手册 — 六阶段交接的权威参考；Phase 4→5 的交接由发起方负责。
• 架构 / 工程运营模式 — 介绍如何传达 Architecture 的项目组合（Architecture Initiative Review、Architecture/Platform sync）。
• 相关内容：Skill(running-an-architectural-assessment)、Skill(running-a-proof-of-concept)、Skill(scoping-and-handing-off-to-teams)、Skill(coordinating-implementation-across-teams)、Skill(curating-the-strategy-ideas-backlog)；来自 bitwarden-delivery-tools：Skill(navigating-the-initiative-funnel)、Skill(running-work-transitions)。