需要新增/重排/更新产品路线图时，用框架整理优先级、依赖…

适用于从零创建或更新产品路线图、增删 initiative、调整优先级/时间线，并生成风险、依赖与变更说明的场景。

适用场景

解决思路

1. 入口命令：使用 /roadmap-update $ARGUMENTS 启动产品路线图更新、创建或重排流程。
2. 理解当前状态：若已连接项目跟踪器，拉取当前路线图条目及其状态、负责人、日期；识别逾期、有风险、最近完成的事项；标出没有明确负责人或日期的事项。
3. 理解当前状态：若未连接项目管理工具，要求用户描述当前路线图或粘贴/上传；接受列表、表格、电子表格、截图或文字描述等任意格式。
4. 确定操作：询问用户要做什么，并在以下操作中选择：新增事项、更新状态、重排优先级、移动时间线、创建新路线图。
5. 新增事项：收集名称、描述、优先级、预估工作量、目标时间段、负责人、依赖；根据当前优先级和容量建议放在哪里。
6. 更新状态：支持未开始、进行中、有风险、阻塞、已完成、砍掉；对“有风险”或“阻塞”追问阻塞原因和缓解计划。
7. 重排优先级：询问发生了什么变化（新信息、战略转向、资源变化、客户反馈）；必要时应用优先级框架（RICE、MoSCoW、ICE、价值-工作量矩阵）；展示调整前后对比。
8. 移动时间线：询问原因（范围变化、依赖延期、资源约束）；识别对下游依赖事项的影响；标记会越过硬性截止日期的事项。
9. 创建新路线图：询问时间范围（季度、半年、一年）；询问格式偏好（Now/Next/Later、季度列、OKR 对齐）；收集要纳入的 initiative 列表。
10. 生成路线图摘要：输出状态概览，快速总结进行中 X 项、本周期完成 Y 项、有风险 Z 项。
11. 生成路线图摘要：对每个事项展示名称和一句话描述、状态指示（on track/at risk/blocked/completed/not started）、目标时间段或日期、负责人、关键依赖。
12. 生成路线图摘要：按时间段（Now/Next/Later）或季度分组，取决于格式；若用户偏好，也可按主题/目标分组。
13. 生成路线图摘要：列出风险与依赖，包括阻塞或有风险事项及细节、跨团队依赖及其状态、接近硬性截止日期的事项。
14. 生成路线图摘要：如果是对现有路线图的更新，总结本次变更：新增/移除/重排的事项、时间线变动、状态变化。
15. 后续跟进：生成路线图后，提出可为特定受众排版（高管摘要、工程细节、面向客户）。
16. 后续跟进：提出可起草关于路线图变更的沟通内容。
17. 后续跟进：如果连接了项目管理工具，提出可更新 ticket 状态。
18. Roadmap 框架 Now/Next/Later：Now 对应当前 sprint/月，是承诺工作，范围和时间的信心高，是团队正在构建的内容。
19. Roadmap 框架 Now/Next/Later：Next 对应未来 1-3 个月，是计划工作，对“做什么”信心高、对“具体何时”信心较低，已定范围并排序但尚未开始。
20. Roadmap 框架 Now/Next/Later：Later 对应 3-6+ 个月，是方向性内容，是打算追求的战略赌注和机会，但范围和时间灵活。
21. Roadmap 框架 Now/Next/Later：大多数团队大多数时候使用；尤其适合对外或对领导层沟通，因为避免日期上的虚假精确。
22. Roadmap 框架 Quarterly Themes：每季度围绕 2-3 个主题组织路线图；每个主题代表一个战略投资领域，例如 Enterprise readiness、Activation improvements、Platform extensibility。
23. Roadmap 框架 Quarterly Themes：在每个主题下列出计划的具体 initiative；主题应映射到公司或团队 OKR；便于解释为什么构建这些东西。
24. Roadmap 框架 Quarterly Themes：当需要展示战略对齐时使用；适合规划会议和高管沟通。
25. Roadmap 框架 OKR-Aligned：从团队该周期的 OKR 开始；在每个 Key Result 下列出会推动该指标的 initiative；包含每个 initiative 对 KR 的预期影响。
26. Roadmap 框架 OKR-Aligned：在构建内容和衡量指标之间建立清晰问责；适合运行 OKR 的组织，确保每个 initiative 都有可衡量的“为什么”。
27. Roadmap 框架 Timeline/Gantt View：使用基于日历的时间线视图，显示开始日期、结束日期和持续时间；可视化并行和顺序；识别资源冲突；显示事项间依赖。
28. Roadmap 框架 Timeline/Gantt View：用于与工程做执行规划、识别排期冲突；不要用于对外沟通，因为会制造虚假精确预期。
29. 优先级框架 RICE Score：对每个 initiative 从四个维度评分，计算 RICE = (Reach x Impact x Confidence) / Effort。
30. 优先级框架 RICE Score：Reach 是在给定时间段会影响多少用户/客户，用具体数字，例如 500 users per quarter。
31. 优先级框架 RICE Score：Impact 是对每个触达对象的影响程度，采用 3 = massive、2 = high、1 = medium、0.5 = low、0.25 = minimal。
32. 优先级框架 RICE Score：Confidence 是对 Reach 和 Impact 估计的信心，100% = 高信心（有数据支持）、80% = 中等（有一些证据）、50% = 低（凭直觉）。
33. 优先级框架 RICE Score：Effort 是所需人月，包含工程、设计和其他职能。
34. 优先级框架 RICE Score：当需要量化、可辩护的优先级排序时使用；适合比较大量 backlog；对影响难以估计的战略赌注不太适合。
35. 优先级框架 MoSCoW：将事项分类为 Must have、Should have、Could have、Won't have。
36. 优先级框架 MoSCoW：Must have 是缺少则路线图失败，不可谈判的承诺；Should have 是重要且被期待，但缺少也可交付；Could have 是想要但优先级明显更低，只有容量允许才纳入；Won't have 是本周期明确不在范围内，为清晰起见也重要。
37. 优先级框架 MoSCoW：用于界定一个发布或季度的范围；与利益相关者谈判什么能放进；有助于强制进行优先级讨论。
38. 优先级框架 ICE Score：比 RICE 更简单，对每个事项在三个维度按 1-10 评分：Impact、Confidence、Ease。
39. 优先级框架 ICE Score：Impact 是多大程度推动目标指标；Confidence 是对影响估计的信心；Ease 是实现容易程度（工作量的反比，越高越容易）；ICE Score = Impact x Confidence x Ease。
40. 优先级框架 ICE Score：用于快速排序功能 backlog；适合早期产品，或没有足够数据做 RICE 时。
41. 优先级框架 Value vs Effort Matrix：把 initiative 画在 2x2 矩阵上。
42. 优先级框架 Value vs Effort Matrix：High value, Low effort（Quick wins）先做；High value, High effort（Big bets）仔细规划，值得投资但需要正确界定范围；Low value, Low effort（Fill-ins）有余量时做；Low value, High effort（Money pits）不要做，从 backlog 移除。
43. 优先级框架 Value vs Effort Matrix：用于团队规划会中的可视化优先级排序；有助于建立对取舍的共同理解。
44. 依赖映射：识别技术依赖（Feature B 需要 Feature A 的基础设施工作）、团队依赖（需要设计、平台、数据等其他团队工作）、外部依赖（等待供应商、伙伴或第三方集成）、知识依赖（开始前需要研究或调查结果）、顺序依赖（必须先发布 Feature A 才能开始 Feature B，因共享代码或用户流程）。
45. 依赖管理：在路线图中显式列出所有依赖；为每个依赖分配负责人（谁负责解决）；设置 need by 日期，即依赖事项何时需要该依赖解决。
46. 依赖管理：在依赖周围留缓冲，因为它们是路线图中风险最高的项目；尽早标记跨团队边界的依赖，这些需要协调；准备应急计划，想清楚依赖滑期怎么办。
47. 减少依赖：能否构建一个更简单、避开该依赖的版本；能否通过接口契约或 mock 并行推进；能否重新排序以把依赖提前；能否把工作吸收到本团队，以消除跨团队协调。
48. 容量规划估算：从工程师人数和时间段开始；减去已知开销，如会议、on-call 轮值、面试、假期、PTO；常用经验法则是工程师 60-70% 时间用于计划内功能工作；新成员加入要计入团队上手时间。
49. 容量分配：多数产品团队的健康分配是 70% 计划内功能、20% 技术健康（技术债、可靠性、性能、开发者体验）、10% 计划外（紧急问题、快速收益、其他团队请求的缓冲）。
50. 容量分配：按团队情境调整比例：新产品更多功能工作、更少技术债；成熟产品更多技术债和可靠性投资；事故后更多可靠性、更少功能；快速增长期更多可扩展性和性能。
51. 容量与野心：如果路线图承诺超过容量，必须有东西让步；不要通过假装大家能做更多来解决容量问题，而要通过砍范围解决；新增路线图内容时总要问：什么会拿掉？
52. 容量与野心：宁可承诺更少并可靠交付，也不要过度承诺并让人失望。
53. 沟通路线图变更：常见触发包括领导层新战略优先级、改变优先级的客户反馈或研究、改变估算的技术发现、其他团队依赖滑期、资源变化（团队扩大/缩小、关键人员离开）、需要响应的竞争动作。
54. 沟通路线图变更：1）承认变化，直接说明什么在变以及为什么；2）解释原因，什么新信息驱动了该决定；3）展示取舍，为腾出空间什么被降优先级，或什么在滑期；4）展示新计划，即更新后的路线图；5）承认影响，谁受影响以及如何受影响；原本期待被降优先级事项的利益相关者需要直接听到。
55. 避免路线图 whiplash：不要因为每条新信息都改变路线图，要有变更阈值；除非真正紧急，否则按自然节奏（每月、每季度）批量更新路线图。
56. 避免路线图 whiplash：区分“路线图变更”（战略重排）和“范围调整”（正常执行细化）；跟踪路线图变更频率，频繁变更可能说明战略不清，而不是响应力好。
57. 输出格式：使用清晰、可扫读的格式；路线图条目适合用表格；使用文字状态标签：**Done**、**On Track**、**At Risk**、**Blocked**、**Not Started**。
58. 技巧：路线图是沟通工具，不是项目计划；保持在正确高度——主题和结果，而不是任务。
59. 技巧：重排优先级时总要问发生了什么变化；优先级变化应由新信息驱动，而不是一时兴起。
60. 技巧：尽早标记容量问题；如果路线图的工作量超过团队能处理的量，直接说出来。
61. 技巧：依赖是路线图最大风险，显式暴露它们。
62. 技巧：如果用户要求新增内容，总要问什么会被拿掉或移动；路线图相对容量是零和的。

适用边界 · 注意事项

• 当你只需要任务级项目计划或精确甘特排期用于执行跟踪时，不要把它当作路线图；路线图应保持主题/结果高度。
• 当缺少负责人、容量、依赖或产品上下文且无法补充时，不要强行排期或承诺；否则只是猜测。
• 当每次新信息出现都想立即重排时，不要频繁改路线图；应设阈值并按月/季度批量更新，避免路线图 whiplash。