championing-a-strategy-idea

负责推动 技术战略构想（TSI）通过 Architecture 预漏斗评估的主要负责人手册。内容涵盖提交 ARCH 构想、与同行评审者配对、完成利益相关方与参与度地图（包括已知摩擦点）、在 Architecture Council 上进行陈述、应对季度优先级排序，以及在移交实施时开展采纳回顾。时间跨度：由季度评审节奏决定，而非固定时长。

同行评审者／组合策展人请使用 Skill(curating-the-strategy-ideas-backlog)；团队技术负责人作为贡献者（妥善提交构想，并推动各阶段交接给 Staff+ 负责人）的角色定位，请在 bitwarden-tech-lead 中使用 Skill(contributing-to-technical-strategy)。

推进构想的模式

根据 TSI 页面，每个处于活跃状态的构想都会分配两个 Architecture 侧角色：

• 主要负责人。 推动构想通过整个流程。撰写问题陈述、开展研究、在 Architecture Council 上进行陈述，并推动其过渡到漏斗。对进展负责。调用此技能时，你就是这个角色。
• 同行评审者。 第二位 Architecture 工程师，作为讨论对象，随时了解构想进展，并提出建设性的质疑。他们不是共同负责人——他们的职责是提出尖锐问题、发现跨项目冲突，并确保利益相关方参与全面到位。

这种配对很重要。TSI 页面明确指出：“任何一位工程师承担的活跃评审任务（主要负责人或同行评审者）都不应超过两项。”如果你准备担任主要负责人，但已经承担了两项活跃任务，请说明这一点——评审任务超负荷会失去其意义，也会拖慢那些你名义上承担了、实际却无力推动的构想。

从战略构想到漏斗接纳的流程

大致如下：

1. 记录。 以轻量的初步内容提交 ARCH 构想——问题／机会陈述、战略一致性、粗略的 RICE 评估、主题、客户细分和路线图安排。
2. 配对。 确定一位同行评审者。在每两周一次的架构工作会议上，开始与其分享进展。
3. 通过同行评审完善构想。 在构想从 Backlog 转入 Research 之前，共同完成利益相关方与参与度地图。这是关卡。
4. 研究。 完善问题陈述，按照承诺的参与方式开展利益相关方访谈，并梳理研究发现。
5. 在 Architecture Council 上进行陈述。 同行评审者以知情盟友的身份出席。
6. 在季度优先级排序中争取接纳。 工程领导层决定该构想是否进入漏斗，以及安排在路线图的哪个时间点。
7. 转入漏斗。 创建 BW Initiative，将其链接回 ARCH 构想，更新状态，并移交给 Skill(shepherding-an-initiative)，以推进漏斗阶段的流程。

漏斗侧的实施完成后，你和同行评审者将开展一次以影响力成效为重点的采纳回顾。这部分内容归于此处，而非漏斗技能——请参阅此技能末尾。

提交构想（捕获）

TSI 模板位于 JPD 的 ARCH 项目中。对主要负责人而言，最关键的部分包括：

• 问题／机会陈述。 具体说明当前状况、痛点和机会。TSI 页面中的示例标准是：“客户端之间存在五种不同的错误处理模式，导致调试困难、用户困惑”，而不是“错误处理不一致”。尽可能量化。
• 战略对齐。 这项工作支持哪些 OKR、主题或架构原则？它依赖哪些其他举措，或能为哪些举措提供支持？
• 拟议方向。 只说明概念性方法。不要设计解决方案——那是漏斗研究阶段的工作。粗略判断是自建、购买还是集成。
• 运维与质量考量。 关键指标／SLI、性能限制、可测试性、自托管还是云端、合规相关事项。
• 验证方法。 最小化 PoC 的样子、成功信号、需要验证的假设。
• 粗略估算。 T 恤尺码、预计时长、复杂度因素。
• RICE。 务必诚实。信心如何就如实填写——夸大信心会让待办列表失去可信度。TSI 页面的 RICE 评分页面记录了评分标准。

你可以在 bitwarden-tech-lead 中参考 Skill(contributing-to-technical-strategy)，了解模板的使用方式。该技能提供的是贡献者视角的指导；提交之后的一切——配对、梳理、完善、展示、排序——都属于本技能的范围。

利益相关者与参与方式图（研究关卡）

这是本技能最能发挥作用、杠杆效应最大的一环。根据 TSI 页面，构想要从待办列表进入研究阶段，必须先由主要负责人和同行评审者共同完成一份完整的参与方式图。该图包含五个字段：

• 决策者。 明确具体人员或角色，而不只是团队名称，并说明各自有权决定的事项。“工程副总裁负责资源分配；SRE 负责人负责运维归属。”
• 必须征询意见的人。 具备相关专业知识或背景，且其意见会_实质性影响方向_的人。在研究期间征求意见，而不是事后再问清楚。区分必须征询意见的人与必须告知的人，才能避免在真空中塑造构想。
• 必须告知的人。 会受到结果影响、需要及时了解情况的人。相关举措推进到他们面前时，不应让他们感到意外。
• 已知摩擦点。 可能出现分歧、阻力或优先级冲突的地方。要诚实、明确，并在研究开始_之前_指出。TSI 页面明确写道：“提前指出摩擦，是避免好构想变成技术上合理、却在落地时停滞的提案的关键。” 这是主要负责人最容易淡化的字段。不要回避。
• 参与方式。 说明如何让各方参与。TSI 页面列出了可选方式：一对一交流、RFC 风格的 Confluence 评审、在架构委员会上演示、参加团队冲刺评审、异步 Confluence 评审。根据利益相关者的沟通风格和议题的敏感度，选择合适的方式。

同行评审者应该追问以下两个问题；你也应该先问问自己：

• 我们是否指出了已经知道的摩擦？ “我们预计团队 X 会因为 Y 而抵制”比只谈好处的构想更可信。
• 参与方式是否如实反映了影响力？ 如果图上写着“请平台团队通过 RFC 评审”，但实际上在 RFC 有机会得到评审之前，你需要先与平台技术负责人一对一沟通，那就应该明确写出来。

这份图也是一份持续更新的文档。随着研究发现新的利益相关者或摩擦点，应及时更新。整个推进过程结束时的采纳回顾会询问这份图是否准确——请确保日后可以据此核验。

通过研究完善构想（进入漏斗前）

TSI 研究阶段比漏斗中的研究阶段更轻量——此时你还不会编写架构评估。你要做的是加深理解，让构想做好展示和优先级排序的准备。

• 完善问题／机会陈述。 随着证据逐渐累积，持续更新。提交给架构委员会的版本应比最初登记的版本更加清晰。
• 执行你承诺的沟通方式。 进行一对一交流、RFC 评审、参加团队冲刺评审。每次交流通常都会发现地图未能预料到的情况——相应更新地图。
• 在每两周一次的架构工作会议上向同行评审者分享进展。 同行评审者在此阶段的职责，是提出那些你已经不再问自己的问题。
• 更新 RICE。 随着信心度逐渐明确，评分也应随之变化。信心度如实下降，往往意味着“承诺之前需要先做 PoC”——这完全没问题；这正是研究阶段和后续 PoC 的目的。

在架构委员会上展示

当构想准备就绪时——地图完整、问题陈述清晰、已承认阻力，且沟通方式已通过一些早期交流得到验证——就可以提交给架构委员会。

• 同行评审者以知情盟友的身份参会。 他们可以协助回答问题并支持讨论。TSI 页面指出：“架构团队会在每两周一次的工作会议上于会前进行内部对齐”——请善用这一机制。
• 围绕核心论点组织展示。 先介绍问题和战略契合度，而不是提出解决方案。委员会的职责是确认这个构想是否值得投入资源，而不是为它设计方案。
• 一并说明阻力。 委员会会提出相关问题。主动说明真实情况，胜过在提问中被动透露。
• 认真对待反馈。 如果委员会发现了跨计划冲突，或指出你尚未纳入地图的利益相关方，就应将这些内容补充到地图中。

在此阶段，架构委员会可以提供：跨计划情况认知、战略契合度验证、对时机或冲突的顾虑，有时还会建议沟通方式。

架构委员会不会提供：独立于后续工程领导层优先级排序的绿灯。委员会提出建议；领导层确定优先级；两者共同决定构想是否进入漏斗。

季度优先级评审中的价值漏斗接收流程

根据架构 / 工程运营模型，架构团队每季度向工程领导层提交经过优先级排序的想法（60 分钟，深入评审），并在此期间每月进行简短更新（15–20 分钟）。

季度评审前，你需要：

• 确保想法列入议程。 由架构团队决定展示哪些想法；请在双周工作会议上与架构团队负责人协调。
• 做好陈述 Now / Next / Later 方案的准备。 运营模型采用这些阶段。你认为这个想法属于哪个阶段？为什么？如果推迟一个季度，会有什么变化？
• 如实说明资源需求。 如果获批，由谁负责推进（你还是其他人）？可能会影响哪些团队？大致时间安排是什么？
• 提前说明可能产生摩擦的地方。 与隐瞒分歧相比，领导层更可能承诺推进一个明确指出分歧可能出现在哪里的想法。

如果获批，该想法将进入价值漏斗的 Phase 1 Identification 阶段。根据 TSI 页面和 Idea-Based Initiatives：

• 在 Jira 的 BW 项目中创建一个新的 BW Initiative。
• 建立从 BW initiative 指向 ARCH idea 的工作项链接，这是基础的可追溯性链接。
• 指派一名推进负责人（通常是你；有时会由具备相应领域专业知识的其他 Staff+ 工程师担任——请表达偏好，不要想当然）。
• 为整个漏斗流程指派一名同行评审者（通常由同一位同行评审者负责，有时会轮换以拓宽视角）。
• 如果尚未完成，则定稿利益相关者与参与计划。
• 在 JPD 中将 ARCH idea 状态更新为“1️⃣ Identification”。

接下来，将工作交接给 Skill(shepherding-an-initiative)，以获取涵盖整个漏斗流程的总指南。你刚刚推进的流程将成为后续工作的上游背景。

想法被拒绝或暂缓时

根据 TSI 页面，拒绝原因需要明确记录：

• 与战略不一致。
• 价值不足（即使考虑不同方案，成本仍高于收益）。
• 更适合由其他方式处理（团队级工作、产品流程或其他渠道）。
• 时机不合适（外部因素、依赖项）。
• 已被相关想法或现有计划取代。
• 已通过其他方式解决。

将想法移至 Declined 之前，先在 JPD 中记录理由。组织记忆很重要——六个月后，可能有人会提出相同的模式；了解此前的结论会对他们有所帮助。

暂缓的想法不同于被拒绝的想法。如果时机不合适，但论点仍然成立，应争取标记为“Later”，而不是 Declined，并在下一次季度评审时重新审议。

采纳回顾（实施交接后）

这是倡导历程的收尾，应归于此处，而非漏斗技能。根据 TSI 页面，当计划进入实施阶段并开始进行工作交接手册交接时，主要负责人和同行评审人会进行简短回顾，重点关注影响力的有效性，而非交付机制。

四个问题，全部围绕架构团队如何运用影响力来推动这一主张：

• 哪些沟通方式有助于推动采纳？ 哪些一对一沟通改变了立场？哪些 RFC 评审真正推动了工作？哪些委员会演示赢得了支持？
• 哪些地方我们的授权不足，我们又是如何应对的？ 架构团队无权给团队分派工作；沟通方式正是影响力替代授权的手段。了解这种替代何时有效、何时无效，有助于推进下一个想法。
• 哪些分歧是我们发现得太晚、原本应该更早提出的？ 这是对利益相关者与沟通图中“已知摩擦点”字段的事后复盘。我们早早发现并提出的摩擦，是我们已经设法应对的摩擦。实施期间才发现的摩擦，则是图中遗漏的摩擦。
• 下一个计划中，我们会有哪些不同做法？ 实用、可迁移的经验。

TSI 页面要求将结果“在架构工作会议上分享，并作为评论记录在原始想法下，以便留作组织记忆”。这两个渠道都很重要：工作会议能改进架构团队的集体实践；评论则确保下一个找到这个想法的人能了解回顾背景。

这不同于 Skill(coordinating-implementation-across-teams) 中漏斗流程的实施结束回顾；后者由推进负责人和接收方技术负责人参加，重点关注执行。采纳回顾则在架构团队内部进行（主要负责人 + 同行评审人），重点关注影响力。

常见错误

• 提交想法后便放任不管。 提交不等于倡导。请认真履行主要负责人的职责：结对、绘制图谱、演示、确定优先级。否则想法就会停滞在待办事项中。
• 淡化已知摩擦点。 图谱决定了想法是变得可信，还是停留在理论阶段。同行评审人的职责就是对此提出质疑；如果你发现自己在弱化他们的质疑，这就是一个信号。
• 把架构委员会当作必须通过的关卡。 委员会提供意见。请带着真正的问题来，而不是做推介。大多数有力的想法经过委员会讨论后，都会调整方向。
• 跳过采纳回顾。 漏斗回顾关注交付；这项回顾关注影响力。没有它，架构团队就无法改进其最需要精进的集体实践。
• 让同行评审人承担过多工作。 TSI 页面规定：每位架构工程师最多只能同时承担两项评审任务。如果评审人负担过重，其质疑作用就会减弱。请及时提出。
• 在倡导阶段就提前确定范围。 拟议方向只是概念。详细的解决方案设计属于漏斗研究阶段的工作，现在还不是你的职责。过早确定范围会封闭委员会原本可能拓展的选项。

参考资料

• 技术战略构想 — TSI 标准模板、引导模型（主要负责人／同行评审人）、利益相关方与参与地图、采纳回顾。
• 基于构想的计划 — 说明获批的 ARCH 构想如何在漏斗的第 1 阶段转化为 BW 计划。
• 架构／工程运营模型 — 季度优先级评审和 Now/Next/Later 组合，由此决定哪些构想进入漏斗。
• 软件计划漏斗 — 获批构想的后续流程（从识别阶段开始）。
• 架构委员会 — 在倡导阶段以及漏斗的研究／PoC 阶段进行汇报的场所。
• 相关内容：Skill(curating-the-strategy-ideas-backlog) 介绍同一引导模型中同行评审人／组合策展人的职责；Skill(shepherding-an-initiative) 介绍构想获准进入漏斗后会发生什么；Skill(contributing-to-technical-strategy)（位于 bitwarden-tech-lead 中）介绍团队技术负责人的贡献者视角。