curating-the-strategy-ideas-backlog

Bitwarden Technical Strategy Ideas（TSI）待办库的同级评审与组合管理指南——这是上游的构想阶段系统，为处于识别阶段的软件计划漏斗提供输入。内容涵盖如何为他人的构想提供建设性的质疑、管理待办库（每周分诊、每月更新 RICE、安排至 Now/Next/Later）、与工程领导层进行季度优先级评审，以及将获批构想移交至漏斗。

每个进行中的构想对应两个角色

每项处于进行中状态（Research 至 Implementation）的 TSI 都会分配两名架构团队成员。TSI 页面对此有明确说明：

• 主要负责人。 推动构想通过流程：撰写问题陈述、开展研究、在 Architecture Council 上进行介绍，并推动其转入漏斗。对进度负责。主要负责人的指南是 Skill(championing-a-strategy-idea)。
• 同级评审者。 第二位架构工程师，作为讨论对象，了解进展并提供建设性的质疑。不是共同负责人。他们的职责是提出尖锐问题、发现跨计划冲突，并确保利益相关方参与充分。调用此技能时，你承担的就是这一角色——同时还要践行本技能其余部分所述的组合管理工作。

同级评审如何进行

根据 TSI 页面：

• 每项构想都会指定同级评审者。随着构想在生命周期中推进、新构想加入，配对会随之调整，让团队在整个组合中积累广度。
• 主要负责人会持续向同级评审者同步进展和决策节点。双周一次的架构工作会议是主要沟通场合；对于时效性较强的决策，也应安排临时沟通。
• 构想从 Backlog 转入 Research 之前，主要负责人和同级评审者必须共同完成模板中的 Stakeholder & Engagement Map 部分。这是一个关卡。
• 在 Architecture Council 上介绍构想时，同级评审者应以知情盟友的身份出席，协助回答问题并支持讨论。
• **任何工程师同时承担的进行中评审任务（主要负责人或同级评审者）都不应超过两项。**评审负担过重会使其失去意义。

将 Stakeholder & Engagement Map 设为关卡

构想必须通过此关卡，才能从 Backlog 进入 Research。该图包含五个字段——Decision makers、Must consult、Must inform、Known friction points、Engagement approach——其详细说明见 Skill(championing-a-strategy-idea)，这是主要负责人视角下说明该图如何运作的权威指南。此图由主要负责人和同级评审者协作完成；未完成此图的构想不得进入 Research。

作为同级评审者，你的具体职责是审视此图，尤其是 Known friction points。这是最常被轻描淡写的字段，而 TSI 页面明确指出，正是在这里，“技术上合理的提案会因采用受阻而停滞”。在分诊准备从 Backlog → Research 推进的构想时，要问：此图是否完整且如实？如果摩擦被含糊带过、决策者描述模糊（例如写“Vault 团队”，而非注明具体职位及其权限），或者参与方式与利益相关方的沟通风格不符，就要提出异议。

RICE 评分规范

每个想法都有一个 RICE 分数：覆盖范围 × 影响力 × 信心 / 投入。根据 TSI 页面，评分指南见 Idea RICE Scoring。

策展实践：

• 每月更新分数。 随着对某个想法了解得更多——通过同行评审、利益相关方交流，或相关计划取得进展——分数也会逐步完善。
• 每周对新想法进行分类，确保待办事项保持最新；季度中期的待办事项管理则会根据当前项目组合重新审视分数。
• 避免虚高评分。覆盖范围就是实际情况；信心反映的是当前的实际认知水平。坦诚标注“信心较低”的 RICE 分数，比虚高分数更有价值，因为后者会掩盖 PoC 能够解答的问题。

主题、路线图安排、客户细分

根据 TSI 页面，除 RICE 外，想法还包含标准化的优先级字段：

• 主题。 架构 / 运营 / SDLC / 产品 / 应用安全。决定该想法会显示在哪个项目组合视图中。
• 路线图安排。 Now / Next / Later。根据 Architecture / Engineering Operating Model，这些是 Now/Next/Later 项目组合中使用的阶段，并会向工程领导层传达。
• 客户细分。 个人 / 团队 / 企业 / 自托管 / 内部。记录哪些群体会从中受益。

Operating Model 明确区分了 Now、Next 和 Later——特别指出，Later 是方向性信号，而非承诺。与工程领导层交流时，请保留这一表述；在 Later 阶段承诺季度日期会造成虚假的精确感。

季度优先级评审周期

根据 TSI 页面：

活动	频率	参与者
新想法分类	每周	架构
分数更新	每月	架构
待办事项管理	季度中期	架构 + 感兴趣的 Staff+ 工程师
优先级评审	每季度	架构 + 工程领导层
采用情况回顾	每项计划在交接时进行	主要负责人 + 同行评审者，在工作会议上分享

季度优先级评审是架构团队向工程领导层提交优先候选项、申请将其纳入流程的时机。Operating Model 将此描述为每季度一次、时长 60 分钟的深入评审，并在此期间通过利益相关方同步会，每月进行一次时长 15–20 分钟的轻量更新。

季度评审的策展实践：

• 逐项审视 Now / Next / Later 项目组合。重点说明自上次评审以来发生了哪些变化，以及变化原因。
• 深入讨论“Now”事项：当前所处流程阶段、哪些团队已经或将会参与、架构团队需要这些团队提供什么，以及预计的协作时间线。这是团队提前了解即将到来的工作的机会。
• 讨论“Next”事项：征求对排序和优先级的意见。哪些事项应该提前或推后？有哪些依赖关系未体现在数据中？哪些由团队提出的想法应该纳入流程？
• 开放讨论，让工程团队提出议题、提问，或指出对架构方向的担忧。

将获批创意转入漏斗

当领导层批准某个创意进入漏斗受理流程（通常在季度评审时），该创意会转为一个处于第 1 阶段“识别”的 BW Initiative。根据 TSI 页面，这一过程包括：

• 创建 Initiative。 在 BW 项目下新建 Jira Initiative。
• 关联创意。 在 BW Initiative 和 ARCH 创意（位于 JPD）之间创建工作项链接。这是基础的可追溯性链接。
• 指定引导人。 指定一位 Staff+ 工程师，负责引导 Initiative 通过漏斗。通常由主要负责人担任；有时会指定另一位具备相应领域专业知识的 Staff+ 工程师。
• 指定同行评审人。 指定另一位架构工程师，为漏斗工作提供意见并发挥质疑作用（通常是创意阶段的同一位同行评审人，有时会轮换）。
• 完成 Stakeholder & Engagement Map。 如果尚未完成，引导人和同行评审人应在进入 Research 前共同完成。
• 进入 Identification。 Initiative 从漏斗第 1 阶段开始。
• 将 ARCH 创意状态更新为 JPD 中的“1️⃣ Identification”。

接下来，引导人使用 Skill(shepherding-an-initiative) 和深入各阶段的引导技能推动 Initiative 前进。同行评审人会继续了解进展并发挥质疑作用。

未继续推进的创意

根据 TSI 页面，拒绝原因包括：

• 与战略不一致。
• 价值不足——即使考虑不同的方法，成本仍超过收益。
• 更适合在其他地方处理——团队级工作、产品流程或其他渠道。
• 时机不合适——外部因素或依赖关系使其在可预见的未来难以实施。
• 被相关创意或现有 Initiative 取代。
• 通过其他方式解决（团队工作、外部变化）。

被拒绝的创意仍会保留在 JPD 中，并记录理由。创意管理员应遵守的原则是：始终记录理由，始终保留组织记忆。如果没有记录原因，同一个创意 6 个月后就会从头重新评估。

采纳回顾（漏斗交接时）

根据 TSI 页面，当 Initiative 进入 Implementation 并开始执行 Work Transition Playbook 交接时，主要负责人和同行评审人会进行一次简短回顾，重点评估影响力是否有效——哪些参与方式有效、哪些方面缺乏授权、哪些分歧到后期才浮现，以及下次应如何改进。

如果你是该创意的同行评审人，请参与回顾。规范的回顾手册——包含四个问题、需要关注的事项以及结果的记录位置——位于 Skill(championing-a-strategy-idea)，这是主要负责人的技能。该回顾仅限架构团队内部（主要负责人 + 同行评审人），重点在于架构团队如何发挥影响力；它不同于漏斗在 Implementation 结束时进行的回顾（由引导人与接手的技术负责人参与，重点关注执行情况）。

策展人在审核新想法时的做法

当技术负责人或 Staff+ 工程师提交新想法时，策展方通常会进行以下初步筛选：

• 问题是否真正具有跨领域影响？ 如果问题仅涉及一个团队的代码库，则应说明理由并拒绝（“问题仅限于团队内部——有关何时不应提交，请参阅 Skill(contributing-to-technical-strategy)。”）。不要将团队范围内的工作纳入 Architecture 的项目组合。
• 问题／机会陈述是否具体？ 如果内容是“错误处理不一致”，应要求补充：“请说明各种模式之间的差异及其影响。”可参考 TSI 页面中关于具体性的指导。
• 是否明确指出了摩擦？ 如果缺少 Stakeholder & Engagement Map，或对“已知摩擦点”字段含糊其辞，就应退回。要进入 Research 阶段，必须预先明确指出摩擦，不能妥协。
• 此想法是否已被取代？ 搜索 ARCH 待办列表，查找相近或重复的想法。如果有关联，请明确添加链接；如果重复，则标记为已被取代。
• 此想法在架构层面是否足够重要，值得提交给 Architecture Council？ 有些想法——例如新模式、重大技术选择、跨领域安全问题——需要在进入漏斗之前征求 Council 的意见。

常见错误

• 放宽对 Stakeholder & Engagement Map 的要求。 这道门槛的存在自有原因。未诚实指出摩擦就进入 Research 阶段的想法，最终会在采用阶段停滞。
• 夸大评分。 凭空编造 Confidence 数值、夸大 Reach 值，会导致待办列表无法真实反映现状。季度审核依赖诚实的评分。
• 安排过多同行评审。 每位 Architecture 工程师同时承担的任务超过 2 项，会削弱质疑功能。TSI 页面中“不超过两项”的规定至关重要。
• 把拒绝视为失败。 记录了理由的被拒想法是宝贵的组织知识。真正的问题是悄无声息地搁置，而不是明确拒绝。
• 交接时跳过采用回顾。 只有检视 Architecture 的运作模式，才能提升其影响力。请参与回顾——相关执行手册见 Skill(championing-a-strategy-idea)。
• 脱离 Operating Model 进行策展。 Now/Next/Later 项目组合会在季度审核时向工程领导层传达，并在月度同步会上向 Platform 传达——策展时应考虑这些受众。

参考资料

• 技术战略想法 — TSI 标准模板、同行评审模式、优先级排序周期及治理。
• Architecture / Engineering Operating Model — Now/Next/Later 项目组合沟通、Architecture Initiative Review、Architecture/Platform 同步会。
• 基于想法的计划 — ARCH 想法过渡到漏斗后会成为何种计划。
• 软件计划漏斗 — 已批准的想法在 Phase 1 Identification 阶段的去向。
• 想法 RICE 评分 — 评分参考指南。
• 相关资料：Skill(championing-a-strategy-idea) 介绍同一 Shepherding Model 中 Primary Owner 一侧的职责（推动自己负责的具体想法）；Skill(contributing-to-technical-strategy)（位于 bitwarden-tech-lead 中）介绍团队技术负责人以贡献者身份提交想法；Skill(shepherding-an-initiative) 介绍想法获批并进入漏斗后会发生什么。