路线图更新

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

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

用法

/roadmap-update $ARGUMENTS

工作流程

1. 了解当前状态

如果 ~~项目跟踪器 已连接：

提取当前的路线图项目及其状态、负责人和日期
识别已逾期、有风险或最近完成的项目
找出任何没有明确负责人或日期的项目

如果没有连接项目管理工具：

要求用户描述他们当前的路线图，或粘贴/上传
接受任何格式：列表、表格、电子表格、截图或文字描述

2. 确定操作

询问用户想要做什么：

添加项目：在路线图中添加新功能、新举措或工作任务

收集：名称、描述、优先级、预估工作量、目标时间范围、负责人、依赖关系
根据当前优先级和容量建议其适合的位置

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

选项：未开始、进行中、有风险、受阻、已完成、已取消
对于"有风险"或"受阻"：询问阻碍因素和缓解计划

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

询问发生了什么变化（新信息、战略转变、资源变化、客户反馈）
如有帮助，应用优先级排序框架——参见下面的优先级排序框架了解 RICE、MoSCoW、ICE 和价值 vs 工作量

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

询问原因（范围变更、依赖延迟、资源约束）
识别对依赖项的下游影响
标记超过硬性截止日期的项目

创建新路线图：从头构建路线图

询问时间范围（季度、半年、年度）
询问格式偏好（现在/下一步/将来、季度列、OKR 对齐）——参见下面的路线图框架
收集要包含的举措列表

3. 生成路线图摘要

生成包含以下内容的路线图视图：

状态概览

快速摘要：X 个项目进行中，Y 个在本期完成，Z 个有风险。

路线图项目

对每个项目，显示：

名称和一行描述
状态指示器（正常 / 有风险 / 受阻 / 已完成 / 未开始）
目标时间范围或日期
负责人
关键依赖关系

按以下方式分组：

时间范围（现在 / 下一步 / 将来）或季度，取决于格式
或按主题/目标（如果用户偏好）

风险与依赖

受阻或有风险的项目及详情
跨团队依赖关系及其状态
接近硬性截止日期的项目

本次更新的变更

如果这是对现有路线图的更新，总结变更内容：

添加、移除或重新排序的项目
时间线调整
状态变更

4. 后续跟进

生成路线图后：

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

路线图框架

现在 / 下一步 / 将来

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

现在（当前冲刺/本月）：已承诺的工作。对范围和时间线有高信心。这些是团队正在积极构建的内容。
下一步（未来 1-3 个月）：已计划的工作。对做什么有较好信心，对具体时间信心不足。已确定范围和优先级但尚未开始。
将来（3-6 个月以上）：方向性的。这些是我们打算追求的战略赌注和机会，但范围和时间灵活。

何时使用：大多数团队，大多数时候。特别适合对外部或领导层沟通，因为它避免了在日期上虚假的精确性。

季度主题

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

每个主题代表一个战略投资领域（例如"企业级就绪"、"激活改进"、"平台可扩展性"）
在每个主题下，列出计划的特定举措
主题应映射到公司或团队的 OKR
这种格式便于解释为什么你正在构建你正在构建的内容

何时使用：当需要展示战略一致性时。适合规划会议和高管沟通。

OKR 对齐路线图

将路线图项目直接映射到目标和关键结果：

从该期间团队的目标和关键结果开始
在每个关键结果下，列出将推动该指标的举措
包括每个举措对关键结果的预期影响
这在你构建的内容和衡量的内容之间建立了清晰的问责关系

何时使用：使用 OKR 的组织中。适合确保每个举措都有与可衡量结果相关的明确"为什么"。

时间线 / 甘特图视图

基于日历的视图，项目在时间线上展示：

显示开始日期、结束日期和持续时间
可视化并行和顺序关系
适合识别资源冲突
显示项目之间的依赖关系

何时使用：与工程团队进行执行规划时。识别排期冲突。不适合对外沟通（会产生虚假的精确性预期）。

优先级排序框架

RICE 评分

从四个维度对每个举措评分，然后计算 RICE = (触达人数 x 影响 x 信心) / 工作量

触达人数：在给定时间段内这将影响多少用户/客户？使用具体数字（例如"每季度 500 个用户"）。
影响：这对每个触达的人有多大推动作用？按等级评分：3 = 巨大，2 = 高，1 = 中等，0.5 = 低，0.25 = 极小。
信心：我们对触达人数和影响的估计有多大信心？100% = 高信心（有数据支持），80% = 中等（有一些证据），50% = 低（直觉）。
工作量：需要多少人月的工作？包括工程、设计和任何其他职能。

何时使用：当需要定量、可辩护的优先级排序时。适合比较大量积压的举措。不太适合影响难以估计的战略赌注。

MoSCoW

将项目分类为必须有、应该有、可以有、不会有：

必须有：没有这些路线图就是失败的。不可商议的承诺。
应该有：重要且被期待，但没有它们也能交付。
可以有：可取但明显优先级较低。仅在容量允许时包含。
不会有：明确排在这期范围之外。列出以便清晰。

何时使用：确定发布或季度范围时。与利益相关者协商什么能放进去时。适合推动优先级排序对话。

ICE 评分

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

影响：这将在多大程度上推动目标指标？
信心：我们对影响估计有多大信心？
容易程度：实现这个有多容易？（工作量的倒数——越高越容易）

ICE 评分 = 影响 x 信心 x 容易程度

何时使用：对功能积压进行快速优先级排序。适合早期产品或在没有足够数据使用 RICE 时。

价值 vs 工作量矩阵

将举措绘制在 2x2 矩阵上：

高价值、低工作量（速赢）：先做这些。
高价值、高工作量（重大赌注）：仔细规划。值得投入，但需要适当的范围界定。
低价值、低工作量（填充项）：有空余容量时再做这些。
低价值、高工作量（无底洞）：不要做这些。从积压中移除。

何时使用：在团队规划会议中进行可视化优先级排序。适合建立对权衡的共同理解。

依赖关系映射

识别依赖关系

查找以下类别的依赖关系：

技术依赖：功能 B 需要功能 A 的基础设施工作
团队依赖：功能需要另一个团队的工作（设计、平台、数据）
外部依赖：等待供应商、合作伙伴或第三方集成
知识依赖：在开始之前需要研究或调查结果
顺序依赖：必须在功能 B 开始之前交付功能 A（共享代码、用户流程）

管理依赖关系

在路线图中明确列出所有依赖关系
为每个依赖关系指定负责人（谁负责解决它）
设定"需要日期"：依赖项需要何时解决
围绕依赖关系建立缓冲——它们是任何路线图上风险最高的项目
尽早标记跨越团队边界的依赖关系——这些需要协调
制定应急计划：如果依赖关系延迟，你该怎么办？

减少依赖关系

能否构建一个避免依赖关系的简化版本？
能否通过使用接口契约或模拟来并行化？
能否以不同的方式排序以将依赖关系提前？
能否将工作吸收到你的团队中以消除跨团队协调？

容量规划

估算容量

从工程师数量和时间段开始
减去已知的开销：会议、值班轮换、面试、假期、带薪休假
一个常见的经验法则：工程师将 60-70% 的时间花在计划的功能工作上
考虑新成员的团队磨合时间

分配容量

大多数产品团队的合理分配：

70% 计划功能：推进战略目标的路线图项目
20% 技术健康：技术债务、可靠性、性能、开发者体验
10% 未计划：为紧急问题、速赢和其他团队的请求预留缓冲

根据团队情况调整比例：

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

容量 vs 雄心

如果路线图承诺超过容量，必须有取舍
不要通过假装人们可以做更多来解决容量问题——通过削减范围来解决
当向路线图添加内容时，始终问："什么被拿掉？"
承诺更少并可靠交付，好过过度承诺然后令人失望

沟通路线图变更

路线图何时变更

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

领导层的新战略优先级
改变优先级的客户反馈或研究
改变估算的技术发现
另一个团队的依赖延迟
资源变化（团队扩大或缩小、关键人员离职）
需要回应的竞争动态

如何沟通变更

承认变化：直接说明什么在变化以及为什么
解释原因：什么新信息推动了这一决策？
展示权衡：为了腾出空间，什么被降级了？或者什么在延迟？
展示新计划：反映变更后的更新路线图
承认影响：谁受到影响以及如何影响？期待被降级项目的利益相关者需要直接听到。

避免路线图反复

不要为每一条新信息改变路线图。设定一个变更阈值。
按自然节奏（月度、季度）批量进行路线图更新，除非有真正紧急的事项。
区分"路线图变更"（战略性的重新排优先级）和"范围调整"（正常的执行优化）。
跟踪路线图变更的频率。频繁变更可能表明战略不清晰，而不是良好的响应能力。

输出格式

使用清晰、可扫描的格式。表格适合路线图项目。使用文本状态标签：已完成、正常、有风险、受阻、未开始。

提示

路线图是沟通工具，不是项目计划。保持合适的抽象层级——主题和成果，而不是任务。
重新排列优先级时，始终问什么发生了变化。优先级调整应基于新信息，而非一时兴起。
尽早标记容量问题。如果路线图的工作量超出团队处理能力，要明确指出来。
依赖关系是路线图的最大风险。明确地呈现它们。
如果用户要求添加内容，始终问什么被移除或推迟。路线图相对于容量是零和的。