Sky-Cube 版本规划Skill
适用场景
需求池中积累了一批待做需求,需要按版本切分迭代范围、定义每个版本的目标与验收口径、安排合理的发布节奏。
执行步骤
- 明确版本目标:每个版本先定「要达成什么业务结果」(如"跑通核心交易链路"),再选需求,禁止先堆需求再凑目标。
- 按依赖排范围:技术依赖(登录先行)、业务依赖(支付先行)、数据依赖逐一识别,把强依赖需求排入同版本或前序版本。
- 切分版本边界:每个版本控制功能数量(建议核心功能 3-5 个),标注哪些是「必须完成」哪些是「视进度裁剪」。
- 排定节奏:固定节拍(如双周迭代)与固定范围(如按月发版)二选一并说明理由,标注关键节点(需求冻结/提测/发布)。
- 定义验收口径:每个版本写「发布标准」(如"P0 用例 100% 通过、无未关闭的阻塞缺陷")。
- 留缓冲:版本容量按研发产能的 70-80% 排,预留缺陷修复与需求变更空间。
规范要点
- 版本目标可验证:写「上线后 X 指标达到 Y」或「流程 X 可完整走通」,禁止"提升用户体验"这类不可验证目标。
- 范围必须显式裁剪:写清哪些需求进、哪些出、出的是推迟还是放弃,防止范围蔓延。
- 依赖关系以表格管理:需求 A 依赖 B,列出「被依赖方 + 依赖原因 + 排期约束」。
- 每个版本留痕:版本号、目标、范围、发布标准、实际完成情况,与 PRD 变更历史打通。
输出模板
# [产品名] 版本规划
1. 版本总览表(版本号/目标/核心功能/计划时间/发布标准)
2. 依赖关系表(需求/被依赖方/依赖原因/排期约束)
3. 各版本范围明细(必须完成 / 视进度裁剪 / 明确不做)
4. 节奏与关键节点(需求冻结/提测/发布)
5. 容量评估(产能 × 缓冲系数)
自检清单
- 每个版本目标可验证
- 依赖关系表覆盖全部强依赖
- 范围含「必须/裁剪/不做」三态
- 发布标准量化可判定
- 版本容量预留 20-30% 缓冲