关于 roadmap-planning
roadmap-planning 是面向产品团队的路线图规划技能,采用 Now/Next/Later 划分确定性,并要求按问题、成果和证据组织事项,而非列出功能与长期日期。
主要功能
- 01按 Now/Next/Later 划分阶段
- 02以问题和成果定义路线图事项
- 03为事项记录证据与状态
- 04结合 Shape Up 周期安排工作
- 05限制近期事项并定期审查
适用场景
- 01规划产品路线图与优先级
- 02在 Shape Up 周期中选择工作
- 03根据证据审查和修剪待探索事项
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ assimovt/ productskills --skill roadmap-planning安装后在 Claude Code 中输入/roadmap-planning确认已加载。
详细介绍
制定以成果而非功能列表为核心的路线图。路线图要回答“我们要解决什么问题,以及按什么顺序解决?”,而不是“我们将在何时发布哪些功能?”。路线图上超过 6 周的日期都是虚构的。请据此看待它们。
现在 / 接下来 / 以后
三个时间范围,确定性依次降低:
现在(已承诺——本周期)
- 正在进行或即将开始
- 已充分梳理:问题已定义、解决方案范围已确定、投入已设定
- 已分配团队,预计本周期内交付
- 最多 1-3 项
接下来(已梳理——接下来的 1-2 个周期)
- 问题已验证,解决方案已部分梳理
- 尚未分配给团队
- 可能会根据我们从“现在”项目中学到的内容而变化
- 最多 3-5 项
以后(初步想法——值得探索的点子)
- 我们认为问题确实存在,但尚未验证
- 尚未梳理解决方案
- 有证据支持时会晋升为“接下来”,否则就淘汰
- 数量不限,但每季度精简一次
路线图项目应体现成果,而非功能
每个路线图项目都应围绕要解决的问题或要实现的成果来表述:
不佳(以功能列表为核心的路线图):
- 构建团队协作功能
- 添加 CSV 导出
- 重新设计设置页面
良好(以成果为核心的路线图):
- 将团队注册用户获得首次价值的时间从 15 分钟缩短至 5 分钟以内
- 让用户无需联系支持团队即可导出自己的数据
- 将与设置相关的支持工单减少 50%
解决方案应在梳理过程中逐步成形,而不是在规划路线图时确定。
Shape Up 周期规划
对于采用 Shape Up 周期的团队:
- **下注会议:**领导层评审已梳理的提案,并决定下个周期要做什么。并非所有项目都会入选。
- **冷却期:**周期之间留出 1-2 周,用于修复 bug、探索和梳理未来工作。
- **不自动顺延:**未能在一个周期内交付的工作不会自动顺延,必须重新提交提案。
展示路线图
将路线图控制在一页或一个屏幕内。如果需要滚动查看,说明细节太多了。
使用简单的表格:
| 时间范围 | 成果 | 依据 | 状态 |
|---|---|---|---|
| 现在 | 将新用户引导流失率降至 30% 以下 | 5 次访谈,目前流失率为 60% | 进行中,第 2/3 周 |
| 接下来 | 支持用户自助导出数据 | 每月 12 个支持工单 | 已梳理,待分配团队 |
| 以后 | 支持多个工作区 | 3 家企业潜在客户提出需求 | 尚未验证 |
指南
- 重要:路线图项目超过 6 周时,绝不要标注日期。你并不知道实际情况,假装知道只会损害信任。
- 绝不要制定以功能列表为核心的路线图。按成果和问题组织内容。
- 务必将“现在”限制在 1-3 项。如果你同时开展 8 项工作,最终一项也无法完成。
- 绝不要让“以后”项目未经梳理和证据支持就跳到“现在”。
- 务必每季度精简一次“以后”项目。淘汰 3 个月内没有获得新证据的项目。
- 务必在每个周期开始时评审并更新路线图,而不只是每季度更新。
- 绝不要在缺少项目依据的情况下展示路线图。没有依据的路线图只是愿望清单。
基于 Shape Up(Basecamp)周期规划和“现在 / 接下来 / 以后”框架。技巧来自 productskills。
评论
支持 Markdown