roadmap-update

路线图更新

如果你看到不熟悉的占位符，或需要检查已连接哪些工具，请参阅 CONNECTORS.md。

更新、创建或重新排列产品路线图的优先级。

用法

/roadmap-update $ARGUMENTS

工作流

1. 了解当前状态

如果已连接 ~~项目跟踪工具：

• 拉取当前路线图条目及其状态、负责人和日期
• 找出已逾期、有风险或最近已完成的条目
• 标出没有明确负责人或日期的条目

如果未连接任何项目管理工具：

• 请用户描述当前路线图，或粘贴/上传该路线图
• 接受任何格式：列表、表格、电子表格、截图或文字描述

2. 确定操作类型

询问用户想要做什么：

添加条目：将新功能、计划或工作项加入路线图

• 收集：名称、描述、优先级、预估工作量、目标时间范围、负责人、依赖项
• 根据当前优先级和产能，建议其所处位置

更新状态：更改现有条目的状态

• 可选项：未开始、进行中、有风险、受阻、已完成、已取消
• 对于“有风险”或“受阻”，询问阻碍因素和缓解方案

重新排序优先级：更改条目的顺序或优先级

• 询问发生了什么变化（新信息、战略调整、资源变动、客户反馈）
• 如有帮助，应用优先级框架 — 参见下文 优先级框架，包括 RICE、MoSCoW、ICE 和价值与成本矩阵
• 展示调整前后的对比

调整时间线：移动条目的日期

• 询问原因（范围变更、依赖延期、资源限制）
• 识别对相关依赖条目的下游影响
• 标记超过硬性截止日期的条目

创建新路线图：从零开始构建路线图

• 询问时间范围（季度、半年、一年）
• 询问格式偏好（Now/Next/Later、按季度分列、与 OKR 对齐）— 参见下文 路线图框架
• 收集需要纳入的计划清单

3. 生成路线图摘要

生成路线图视图，包含：

状态概览

快速汇总：X 项进行中，本期已完成 Y 项，Z 项有风险。

路线图条目

对于每个条目，展示：

• 名称及一行描述
• 状态标识（按计划进行 / 有风险 / 受阻 / 已完成 / 未开始）
• 目标时间范围或日期
• 负责人
• 关键依赖项

按以下方式对条目分组：

• 时间范围（Now / Next / Later）或季度，取决于所用格式
• 或者，如果用户偏好，按主题/目标分组

风险与依赖

• 受阻或有风险的条目及其详情
• 跨团队依赖及其状态
• 临近硬性截止日期的条目

本次更新的变化

如果这是对现有路线图的更新，请总结所做的变更：

• 新增、移除或重新排序的条目
• 时间线调整
• 状态变更

4. 后续跟进

生成路线图后：

• 提议为特定受众调整格式（管理层摘要、工程细节、面向客户）
• 提议起草关于路线图变更的沟通内容
• 如果已连接项目管理工具，提议更新工单状态

路线图框架

Now / Next / Later

最简单、通常也最有效的路线图格式：

• Now（当前迭代/当月）：已承诺的工作。对范围和时间线有高度把握。这些是团队正在积极构建的内容。
• Next（未来 1-3 个月）：已规划的工作。对内容有较好把握，但对具体时间把握较弱。已划定范围并排好优先级，但尚未开始。
• Later（3-6 个月以上）：方向性规划。这些是我们打算推进的战略性尝试和机会，但范围和时机较为灵活。

适用场景：大多数团队、大多数时候。尤其适合对外或向管理层沟通，因为它避免了对日期的虚假精确。

季度主题

围绕每个季度 2-3 个主题组织路线图：

• 每个主题代表一个战略投入方向（例如"企业级就绪"、"激活体验改进"、"平台可扩展性"）
• 在每个主题下，列出计划中的具体举措
• 主题应与公司或团队的 OKR 对应
• 这种格式便于解释你们为什么要做这些事情

适用场景：需要展示战略一致性时。适合规划会议和向管理层汇报。

OKR 对齐路线图

将路线图条目直接映射到目标（Objectives）和关键结果（Key Results）：

• 从团队本阶段的 OKR 开始
• 在每个关键结果下，列出将推动该指标的举措
• 写明每项举措对关键结果的预期影响
• 这样可以在"做什么"与"衡量什么"之间建立清晰的责任关系

适用场景：以 OKR 运作的组织。适合确保每项举措都有与可衡量结果挂钩的明确"为什么"。

时间线 / 甘特图视图

以日历为基础，将条目放在时间轴上：

• 展示开始日期、结束日期和持续时长
• 可视化并行与先后顺序
• 有助于发现资源冲突
• 展示条目之间的依赖关系

适用场景：与工程团队进行执行规划、识别排期冲突。不适合对外沟通（容易造成精确度的错误预期）。

优先级排序框架

RICE 评分

从四个维度为每项举措打分，然后计算 RICE =（Reach × Impact × Confidence）/ Effort：

• Reach（覆盖面）：在特定时间段内，这项举措会影响多少用户或客户？请使用具体数字（例如"每季度 500 名用户"）。
• Impact（影响力）：对每个被覆盖的人，这项举措能带来多大的改变？按以下量表打分：3 = 巨大，2 = 高，1 = 中等，0.5 = 低，0.25 = 极小。
• Confidence（置信度）：我们对覆盖面和影响力的估计有多大把握？100% = 高置信度（有数据支撑），80% = 中等（有一定证据），50% = 低（凭直觉判断）。
• Effort（投入）：需要多少人月的工作量？需包含工程、设计以及其他所有职能的投入。

适用场景：需要量化、有据可依的优先级排序时。适合比较大量待办举措。对于影响难以估计的战略性押注，效果较差。

MoSCoW

将条目分为 Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have（这次不做）四类：

• Must have（必须有）：没有这些，路线图就是失败的。是不可妥协的承诺。
• Should have（应该有）：重要且有预期，但没有它们也能顺利交付。
• Could have（可以有）：值得拥有，但优先级明显较低。仅在有余力时纳入。
• Won't have（这次不做）：本阶段明确排除在范围之外。列出来有助于澄清边界。

适用场景：划定版本或季度范围时，与利益相关方协商哪些内容可以纳入时，以及推动艰难的优先级讨论时。

ICE 评分

比 RICE 更简单。在三个维度上为每项条目打 1-10 分：

• Impact（影响力）：这项举措能在多大程度上推动目标指标？
• Confidence（置信度）：我们对影响力的估计有多大把握？
• Ease（易实施性）：这项举措实现起来有多容易？（与投入相反，分数越高越容易）

ICE 分数 = Impact × Confidence × Ease

适用场景：对功能待办列表进行快速排序。适合早期产品，或数据不足以支撑 RICE 评估的情况。

价值-投入矩阵

将举措放在 2x2 矩阵中：

• 高价值、低投入（快速见效）：优先去做。
• 高价值、高投入（大赌注）：谨慎规划。值得投入，但需要充分的范围界定。
• 低价值、低投入（填充项）：在有闲置产能时去做。
• 低价值、高投入（无底洞）：不要做。从待办列表中移除。

适用场景：团队规划会议中的可视化优先级排序。有助于建立对取舍的共同理解。

依赖关系映射

识别依赖

请从以下类别中查找依赖关系：

• 技术依赖：功能 B 需要功能 A 先完成基础设施工作
• 团队依赖：功能需要其他团队（设计、平台、数据）的工作配合
• 外部依赖：等待供应商、合作伙伴或第三方集成
• 知识依赖：开始之前需要先完成调研或调查得出结果
• 顺序依赖：必须先发布功能 A，才能开始功能 B（共享代码、用户流程）

管理依赖

• 在路线图中明确列出所有依赖
• 为每个依赖指定负责人（由谁负责解决）
• 设定“需要完成时间”：依赖它的事项最晚需要在何时拿到结果
• 为依赖预留缓冲时间，它们是路线图上风险最高的事项
• 尽早标记跨团队边界的依赖，这些依赖需要协调
• 制定应急方案：如果依赖延期，你会怎么做？

减少依赖

• 能否构建一个不依赖该项的简化版本？
• 能否通过接口契约或模拟（mock）实现并行开发？
• 能否调整顺序，让依赖项更早完成？
• 能否由你的团队承接这部分工作，从而免去跨团队协调？

产能规划

评估产能

• 从工程师人数和时间周期开始计算
• 扣除已知的开销：会议、值班轮换、面试、节假日、带薪休假
• 一个常用的经验法则：工程师大约把 60-70% 的时间用于计划内的功能开发
• 考虑新成员的团队磨合时间

分配产能

对大多数产品团队而言，较为健康的分配比例为：

• 70% 计划内功能：推进战略目标的路线图事项
• 20% 技术健康度：技术债务、可靠性、性能、开发者体验
• 10% 计划外：用于应对紧急问题、快速见效的改进，以及其他团队的请求

根据团队情况调整比例：

• 新产品：更多投入功能开发，减少技术债务工作
• 成熟产品：更多投入技术债务和可靠性建设
• 事故之后：更多投入可靠性，减少功能开发
• 快速增长期：更多投入可扩展性和性能

产能与目标

• 如果路线图承诺超出产能，必然要有所取舍
• 不要通过假设人们能做更多来解决产能问题，应通过削减范围来解决
• 每当向路线图添加内容时，始终要问：“什么要移出去？”
• 承诺较少但能可靠交付，好过承诺过多而令人失望

沟通路线图变更

路线图何时变更

路线图变更的常见触发因素：

• 管理层提出新的战略优先级
• 客户反馈或研究结论改变了优先级
• 技术调研发现改变了工作量估算
• 其他团队的依赖延期
• 资源变化（团队扩编或缩减、关键人员离职）
• 竞争对手的动作需要做出回应

如何沟通变更

1. 告知变更：直接说明什么在变、为什么变
2. 解释原因：哪些新信息促成了这一决定？
3. 展示取舍：为腾出空间，哪些事项被降低了优先级？或者哪些事项将会延期？
4. 展示新计划：呈现反映这些变更的更新路线图
5. 说明影响：谁会受到影响，影响如何？原本期待被降级事项的利益相关方需要直接听到这一消息。

避免路线图反复无常

• 不要因为每一条新信息就修改路线图，应设定变更的门槛。
• 除非情况确实紧急，否则应按自然节奏（每月、每季度）批量更新路线图。
• 区分“路线图变更”（战略层面的重新排序）和“范围调整”（执行过程中的正常细化）。
• 追踪路线图变更的频率。频繁变更可能说明战略不清晰，而非响应迅速。

输出格式

使用清晰、便于快速浏览的格式。表格适合用于路线图事项。使用文字状态标签：已完成、按计划进行、有风险、受阻、未开始。

提示

• 路线图是一种沟通工具，而不是项目计划。请把它保持在合适的抽象层级：关注主题和成果，而不是具体任务。
• 重新排定优先级时，务必先问清楚什么发生了变化。优先级的调整应当由新信息驱动，而不是一时兴起。
• 尽早标记产能问题。如果路线图中的工作量超出团队的承载能力，请直接指出。
• 依赖关系是路线图面临的最大风险。请明确将其呈现出来。
• 如果用户要求新增某项内容，务必询问哪些内容需要移除或推迟。路线图与产能之间是零和关系。