contributing-to-technical-strategy

Bitwarden 的技术战略呈纵向分布：构想位于顶层，计划位于中间，团队级史诗和用户故事位于底层。技术负责人是贯穿这一纵向结构的角色——发现底层值得提升到顶层的模式，并将顶层的工作转化为团队能够交付的用户故事。

本技能涵盖这一完整纵向结构：

• 识别值得记录的构想。
• 将构想阐述得足够清晰，以便架构团队进行评估。
• 了解获批的构想如何转化为 BW 计划。
• 从计划向下定义史诗级和用户故事级工作。

权威参考资料是 Technical Strategy Ideas 和 Idea-Based Initiatives。需要完整模板或字段定义时，请通过 get_confluence_page 获取。

漏斗顶端：技术战略构想

技术战略构想（TSI）是 Bitwarden 的构想待办事项——由架构团队在 Jira Product Discovery 的 ARCH 项目中维护、经过筛选的技术改进机会集合。构想会按 RICE 进行评分、按主题分类，并列入 Now / Next / Later 路线图。获得优先级的构想会进入软件计划漏斗的识别阶段。

识别值得记录的构想

出现以下模式时，请创建 TSI：

• 多个团队面临的共同痛点。 五个团队各自用不同方式解决同一个错误处理问题。这不是五个团队级问题，而是一个跨团队构想。
• 影响广泛的架构缺口或技术债务。 问题存在于共享代码中，或者缺少相关能力阻碍了其他团队。
• **有机会改善开发者体验或运营可靠性，**且单个团队无法负责到底。
• 值得 Bitwarden 评估的技术趋势——不是“GraphQL 很先进，所以我们应该使用它”，而是“REST 的往返开销在这里和这里可以量化，因此值得评估其他方案”。
• 涉及多个系统的安全改进。

以下情况应留在团队内部处理（不创建任何内容）：

• 问题仅限于单个团队的代码库，且该团队可以在日常工作中解决。
• 问题紧急，需要立即采取行动——此类问题应绕过此流程，直接联系领导层。
• 这是由产品驱动的功能请求——应归入产品待办事项，而不是 TSI。

Staff+ 工程师是 TSI 的主要贡献者，但技术负责人完全可以、也应该提交源自团队经验的构想。每个冲刺中显现的模式是重要信号，而架构团队往往无法直接获知这些情况。

如何清晰地阐述想法

TSI 不需要完整的架构提案，但需要提供足够的背景信息，让架构团队评估是否值得研究。TSI 模板包含几个部分，其中最重要的是：

• 问题／机会陈述。 具体说明当前情况、痛点，以及解决问题后带来的机会。“错误处理不一致”过于笼统；“客户端中存在五种不同的错误处理模式，导致调试困难、用户困惑”则更具可操作性。尽可能量化影响，例如“每季度约有 3 个漏洞与此相关”或“每个迭代周期因此损失约 4 小时”，让影响更加具体。
• 战略契合度。 这项工作支持哪些 OKR、战略主题或架构原则？它依赖于哪些其他计划，或能助力哪些计划？
• 目标受众／利益相关方。 从中受益的团队、用户或系统；受影响的其他对象；可咨询专业意见的团队。
• 利益相关方与协作关系图。 如果处理不当，想法往往会在这里停滞。明确列出决策者的姓名或角色（不能只写团队名称）、必须咨询的利益相关方、必须告知的利益相关方，以及——这个问题可能令人不太舒服——已知的摩擦点：分歧或阻力会来自哪里，原因是什么？提前说明摩擦点，才能避免好想法变成技术上合理、却在推广时停滞的提案。承认摩擦点的想法，比只强调优势的想法更能赢得信任。
• 拟议方向。 只需高层次描述，不要设计解决方案。方案设计属于漏斗研究阶段。简要说明概念性方案、值得考虑的技术，以及构建／购买／集成方面的思路。
• 运维与质量考量。 关键指标或 SLI、性能限制、可测试性方面的影响、自托管与云端方面的影响，以及合规事项（SOC 2、ISO 27001）。
• 验证方法。 最小化概念验证应是什么样；哪些信号表明值得继续推进；哪些假设需要测试。
• 粗略估算。 T 恤尺码、预期时长、复杂性因素。
• 用于确定优先级的 RICE 评分，以及客户细分群体和主题。

首次填写时，不需要把每个字段都填写得尽善尽美。尤其是“利益相关方与协作关系图”，需要由主要负责人和同行评审者协作完成，之后想法才能从 Backlog 进入 Research。团队提交想法时，架构团队会为提交者配对一名评审者，以此完善关系图。

提交后会发生什么

架构团队每周对新想法进行分流，每月更新 RICE 评分，在季度中期管理积压事项，并与工程领导层开展季度优先级评审。获准推进的想法会在识别阶段进入 Software Initiative Funnel。

未获推进的想法会转为 Declined，并记录理由。所有被否决的想法都会保留可见，以便组织留存经验，避免在缺少背景信息的情况下重复评估同一个想法。

漏斗中段：从创意到计划

当一个 ARCH 创意获准进入漏斗时，会创建一条独立记录：Jira 的 Bitwarden Company 项目中的一个 BW Initiative 议题。这是两条用途不同的记录（参见基于创意的计划）：

• ARCH 创意保留在 Jira Product Discovery 中。它继续承载 RICE、主题、路线图位置、完整的 TSI 模板，以及至关重要的漏斗阶段状态（1️⃣ 识别至 5️⃣ 实施）。
• BW Initiative 是执行层面的记录。其中包含战略摘要、作为经办人的牵头人、每个团队对应的子 Epic、指向跨项目相关工作的议题链接，以及记录决策和协调事件的 Jira 评论。

两者通过一个工作项链接关联：BW Initiative“实施”ARCH 创意。借助此链接，JPD 中的人员可以追踪执行状态，Jira 中的人员则可以追溯战略依据。

技术负责人通常不会创建 BW Initiative——这项工作由牵头人在识别阶段完成。但大家经常会查看计划：当某项计划影响团队时、想了解牵头人为何提出某种具体方案时，或检查相邻团队是否有相关工作时。一条关联完善的计划能让人一眼看清三个问题：

1. 这项工作从何而来？ ARCH 创意链接提供战略依据。
2. 正在开展哪些工作？ 子 Epic 展示各团队当前的执行情况。
3. 还有哪些相关事项？“Relates to”链接记录之前的尝试、依赖项、运营工单和跨项目协调事项。

收到计划中的 Epic 时，花五分钟阅读其父级 BW Initiative，并沿链接追溯到 ARCH 创意。了解这些背景几乎总是值得花时间的。

漏斗底部：将追溯链连接到团队工作

技术负责人专属的工作就在这里。在范围界定与承诺阶段，牵头人会在 BW Initiative 下创建子 Epic——通常每个团队或主要模块对应一个。团队随后负责拆解自己的 Epic。

拆解的具体方法——故事质量规则、应包含和应避免的内容，以及如何将结果分享给牵头人——详见 Skill(navigating-the-initiative-funnel)。该技能是拆解实践的权威指南。在此技能中，重要的是可追溯性，它能确保拆解结果与上游的源头创意保持关联：

• 在开展团队拆解会议之前，沿链接清单向上追溯：阅读 BW Initiative 的描述，然后通过工作项链接查看 ARCH 创意。TSI 包含战略依据、利益相关者地图和已知摩擦点——这些都应指导团队如何理解 Epic。提前花五分钟阅读，可以避免之后数小时的故事范围界定偏差。
• 如果拆解过程中发现 TSI 或计划描述中未提及的模糊之处，有两种处理方式：如果模糊之处属于团队范围内的问题，就由团队决定并继续推进；如果涉及跨团队影响，则将问题连同足够的背景信息提交给牵头人，以便其无需从头开始就能解决。“利益相关者与参与地图”这一 TSI 章节通常会说明应采用哪种方式。
• 如果团队在实施过程中遇到 TSI“已知摩擦点”章节中预见的摩擦点，请附上该章节的引用并告知牵头人。这表明摩擦在预期的位置出现了——这不是新问题，而是需要主动应对的计划内问题。

保持追踪链路畅通

随着工作推进，积极为 BW Initiative 添加关联：

• **“关联”**触及这项工作的 SRE/BRE/TSD/PM 工单。
• 实施过程中发现的先前尝试工单。
• 与这项工作有交集的相邻计划。
• 推出过程中出现的运营工单。

计划的关联清单是它最有价值的内容之一——它完整呈现了所有项目中与这项工作相关的内容。如有疑问，就添加关联。如果某个团队的拆解暴露出会影响其他团队的模糊之处，应提交给负责协调的人，而不要自行解决。

常见错误

• **因为觉得提交想法很麻烦，就让跨团队模式停留在团队范围内。**麻烦确实存在；五个团队各自绕过同一个缺口所付出的代价也确实存在。
• **提交想法时没有说明摩擦点。**架构团队可以帮助协调分歧，但前提是先在问题发生的地方明确指出摩擦点。
• **把 ARCH 想法与 BW Initiative 混为一谈。**这是两个产物，面向不同受众，彼此关联但相互独立。随着计划推进，两者都要保持同步。
• **跳过关联清单。**没有“关联”链接的计划，会让所有人在下次遇到类似问题时重新梳理背景。
• **未阅读 TSI 就开展团队拆解。**想法中包含计划描述省略的背景信息——战略依据、利益相关者地图和已知摩擦点。花五分钟阅读上游内容，可以为下游节省数小时。

参考资料

• 技术战略想法 — 官方 TSI 模板和待办事项模型。
• 基于想法的计划 — 官方 BW Initiative 结构及其逐阶段演进方式。
• 相关内容：Skill(navigating-the-initiative-funnel) 介绍想法进入漏斗后的阶段机制；Skill(architecting-solutions)（位于 bitwarden-delivery-tools 中）介绍在构思想法和团队拆解时应运用的架构判断；Skill(running-work-transitions) 介绍此拆解所衔接的第 4 阶段 → 第 5 阶段交接——无论处于过渡的哪一侧。