围绕单版本目标安排版本容量，核心是让目标、容量、发布间隔和版本间衔接互相约束：先把版本目标拆成可验收的范围，再用团队历史吞吐量折算容量，由容量反推发布间隔下限，最后用未完成项去向、依赖前置和下一版本预置规则把相邻版本串起来。这套方法适合正在建立稳定发布节奏的产品团队，ONES可在工作项与版本视图中承载版本目标、范围与容量安排。
要点总览（TL;DR）
- 先写清版本目标的业务结果、用户对象与验收口径，再把目标拆成标注必做与可延后的范围清单，容量才有可计量的对象。
- 容量以团队历史完成量的中位数为基准，扣除会议、支持、缺陷处理等固定开销，再按团队波动预留缓冲，承诺量不作为测算基准。
- 发布间隔由容量决定下限：必做范围的工作量除以单位时间有效容量得到最短周期，间隔短于下限时优先削减范围而非压缩缓冲。
- 版本间衔接用三类规则处理：未完成项按顺延、拆分、移出登记去向，跨版本依赖在规划阶段前置排入前一版本，下一版本预置范围设进入条件与上限。
- 规划生效前按目标、容量、间隔、衔接四类逐项核对，出现必做范围超出可用额度、间隔短于下限或未完成项无去向规则时阻断生效。
先定单版本目标，再谈容量
版本容量讨论之所以容易变成“能塞多少塞多少”，往往是因为目标还停留在方向描述。容量需要一个可计量的对象，而版本目标正是这个对象的来源。先写清目标，再拆出范围，容量才有测算基准。
版本目标的三要素写法
一个可用于规划的版本目标，建议包含三项内容：业务结果（这个版本上线后改变什么）、用户对象（面向哪类用户或哪条业务链路）、验收口径（用什么指标或可观察现象判断达成）。例如“让新注册用户在一周内完成首次关键操作的比例提升”，比“优化新手引导”更能约束范围，因为它明确了对象和判断标准。
从目标拆出版本范围清单
把目标拆成需求项或工作项后，逐项标注“必做”与“可延后”。必做项指缺少它目标就无法验收的内容；可延后项指对目标有贡献但可以放到后续版本的内容。拆分时同步记录每项的验收方式，避免范围清单变成需求标题的堆叠。完成标志是：每一项都能对应到目标三要素中的至少一项，且必做项集合单独拿出来就能支撑目标验收。
确认角色与完成标志
产品负责人牵头撰写目标与范围清单，研发负责人参与确认技术可行性与粗粒度工作量，项目管理记录确认结论。确认完成的标志是三方对“必做项清单”达成一致，可延后项有明确去向，而不是留在清单里悬空。
用历史吞吐量折算版本容量
容量测算的常见错误是用承诺量当基准——把团队说“能做多少”直接当成容量。更可靠的口径是历史完成量：过去若干个周期里团队实际交付并验收的工作量。承诺量反映意愿，完成量反映约束。
容量测算步骤
- 选取统计周期：取最近若干次迭代或发布周期的实际完成数据，周期口径保持一致。
- 取中位数：用完成量的中位数作为基准值，避免个别高产或低产周期拉偏结果。
- 扣除固定开销：从周期总时长中扣除会议、线上支持、缺陷处理等非版本工作占用的部分，得到可用于版本范围的有效容量。
- 对照范围清单：把必做项的工作量估算与有效容量比较，得出初步结论。
缓冲比例与超载判断
在有效容量基础上预留缓冲，用于吸收估算偏差和临时插入事项。缓冲比例结合团队历史波动设定：波动大的团队留高一些，稳定的团队可适当降低。超载判断的完成标志是：必做项估算总量不超过“有效容量减去缓冲”后的可用额度；若超出，先削减可延后项或调整范围，而不是压缩缓冲。
| 测算项 | 口径说明 | 输出 |
|---|---|---|
| 历史完成量 | 最近若干周期实际验收的工作量，取中位数 | 基准吞吐量 |
| 固定开销 | 会议、支持、缺陷处理等非版本工作占用 | 有效容量 |
| 缓冲额度 | 按团队波动情况设定的预留比例 | 可用额度 |
| 范围对照 | 必做项估算与可用额度比较 | 容量结论：可承载/需削减 |
确定发布间隔与节奏基线
发布间隔由容量决定下限：用必做范围的工作量除以团队单位时间的有效容量，得到完成该范围所需的最短周期，这就是间隔下限。间隔短于下限，要么范围缩水，要么缓冲被吃掉，节奏会逐渐失控。
固定节奏与弹性节奏的取舍
固定节奏指按周或按月定期发布，适合需求波动较小、上下游协作方较多、对外承诺需要稳定预期的场景；弹性节奏指按版本内容完成情况决定发布时点，适合需求不确定性高、外部依赖少的场景。取舍时看两个条件：协作方是否依赖固定时点安排工作，以及需求进入版本的可预测程度。两者都偏向稳定时，固定节奏更合适；不确定性主要来自需求侧时，可保留弹性窗口，但仍应设定最长间隔上限。
节奏基线的确认与沟通
节奏基线包括发布间隔、版本起止时点和范围冻结时点。由项目管理汇总容量结论与间隔测算，产品负责人和研发负责人共同确认，形成对外沟通口径：对协作方说明发布时点与范围冻结时间，对团队说明范围变更的截止点。完成标志是基线写入版本计划，且相关方在同一份口径上对齐。
设计版本间衔接机制
版本间衔接处理的是“这个版本没做完的、依赖下一个版本的、以及下一个版本提前准备的内容”如何流转。衔接规则缺失时，未完成项会悄悄挤占下一版本容量，节奏基线随之失效。
未完成项的三种去向
- 顺延：整项移入下一版本，适用于仍符合下一版本目标且工作量完整的内容，需记录顺延理由。
- 拆分：把未完成项拆成可独立交付的部分，已完成部分随当前版本收尾，剩余部分进入下一版本，适用于部分完成且可分割的内容。
- 移出：退出近期版本范围，回到待规划池，适用于目标已变化或优先级下降的内容。
三种去向都应在版本收尾时逐项登记，由产品负责人决定去向、项目管理记录，避免未完成项默认顺延。
跨版本依赖的前置识别
规划阶段就应识别哪些工作依赖前一版本的产出（接口、数据、基础能力），并把前置部分排入前一版本的必做范围。依赖识别在范围确认时同步完成，排期时标注依赖关系，下一版本的相关工作项在依赖未就绪前不进入开发。
下一版本预置范围的进入条件
预置范围指提前为下一版本准备的内容，用于缩短版本启动空窗。进入条件建议包括：与下一版本目标相关、不占用当前版本必做容量、依赖已识别。预置范围设上限，避免提前塞满导致下一版本失去调整空间。
角色分工与各环节交付物
目标、容量、节奏、衔接四类工作各有主责人，边界清晰才能避免规划会上反复拉扯。下表给出职责与交付物的对照。
| 环节 | 主责角色 | 协作角色 | 交付物 | 评审节点 |
|---|---|---|---|---|
| 版本目标与范围 | 产品负责人 | 研发负责人确认可行性 | 目标与范围清单（必做/可延后） | 版本规划评审 |
| 容量测算 | 研发负责人 | 项目管理提供历史数据 | 容量测算表与缓冲规则 | 容量确认会 |
| 发布间隔与节奏 | 项目管理 | 产品、研发共同确认 | 节奏基线说明 | 版本计划发布 |
| 版本间衔接 | 产品负责人 | 项目管理记录去向 | 衔接规则与交接清单 | 版本收尾复盘 |
| 变更记录 | 项目管理 | 各角色提交变更 | 变更日志 | 随版本计划同步 |
信息同步的责任人是项目管理：范围冻结、容量调整、节奏变更都通过同一渠道发布，变更记录保留原因与影响范围。产品负责人对目标与范围变更负责，研发负责人对容量与技术依赖变更负责。
在工具层面，版本目标、范围清单与容量安排可以放在同一版本视图中管理，工作项标注必做与可延后，未完成项的去向在收尾时更新状态，使衔接规则有可追溯的记录。ONES的版本与工作项视图可承载这类信息，具体配置按团队实际流程设定。
一个版本节奏规划的示例
以下为演示情景，团队规模、周期与缓冲比例均为假设，实际使用时按团队数据替换。
示例背景与假设
假设一个产品团队按双周迭代推进，最近六个迭代的实际完成量中位数为40点，每个迭代约有20%时间用于会议、支持与缺陷处理，缓冲比例设为15%。当前版本目标为“提升新用户首次关键操作完成率”，拆出必做项合计32点，可延后项合计18点。
从目标到容量到间隔的推演
- 有效容量：40点扣除20%固定开销，约32点。
- 可用额度：32点再扣除15%缓冲，约27点。
- 范围对照：必做项32点超过可用额度27点，需削减约5点，或把部分必做项降级为可延后。
- 间隔测算：若维持32点必做范围，按有效容量32点/迭代计算需一个完整迭代加部分缓冲，间隔下限约一个半迭代；若削减到27点，可在一个迭代内完成并保留缓冲。
衔接处理与最终排期
团队选择削减5点可延后项，使必做范围落在可用额度内，发布间隔定为双周固定节奏。版本收尾时，一项未完成的必做项因部分完成被拆分：已完成部分随本版本验收，剩余部分顺延至下一版本并记录理由；下一版本的一项接口依赖被前置识别，排入本版本收尾阶段完成。下一版本预置范围控制在可用额度的两成以内，待依赖就绪后进入开发。
规划完成前的检查项
规划是否可用，可按四类逐项核对。任一关键项不通过，应阻断规划生效，先修正再发布。
| 类别 | 检查项 | 通过标准 |
|---|---|---|
| 目标 | 目标是否包含业务结果、用户对象、验收口径 | 三项齐全，必做项可支撑验收 |
| 容量 | 是否以历史完成量为基准并扣除固定开销 | 必做项估算不超过可用额度 |
| 间隔 | 发布间隔是否不低于容量测算的间隔下限 | 间隔与容量匹配，缓冲未被挤占 |
| 衔接 | 未完成项去向、跨版本依赖、预置范围是否有规则 | 三类规则明确且有人负责记录 |
阻断项包括：必做范围明显超出可用额度、发布间隔短于间隔下限、未完成项无去向规则。规划生效后设定复盘与调整触发条件，例如连续两个版本出现超载、范围在冻结后频繁变更、或跨版本依赖多次未按期就绪，出现任一情况即重新测算容量与间隔。
常见问题
版本目标写好了，但必做项还是越拆越多，怎么控制？
必做项膨胀通常是因为判定标准太宽。建议把必做项限定为“缺少它目标就无法验收”的内容，拆分时逐项对照目标三要素：业务结果、用户对象、验收口径。对每一项追问一句“去掉它，验收还能不能通过”，通不过的才留在必做集合。可延后项单独列一栏并写明去向，不要与必做项混在同一清单里反复讨论。确认完成的标志是必做项集合单独拿出来就能支撑目标验收，且三方对这份清单达成一致。
团队历史数据不足或波动很大，容量还能怎么测算？
历史周期太少时，可以先用现有周期的完成量取中位数作为起点，并适当提高缓冲比例，用几个版本的实际数据逐步校准。波动大的团队重点看两件事：固定开销占比是否稳定，以及临时插入事项的频率。若临时事项长期占比较高，应先把这部分从容量中显性扣除，再讨论版本范围，而不是让缓冲反复被吃掉。校准期间发布间隔可保留弹性窗口，但设定最长间隔上限，避免节奏失去约束。
固定节奏和弹性节奏可以混用吗？
可以，常见做法是固定发布时点、弹性调整范围。协作方依赖稳定时点时，发布间隔保持固定，版本内容按容量在冻结时点前调整；需求不确定性主要来自需求侧时，可在固定间隔内保留范围调整窗口。混用的前提是范围冻结时点和变更截止点对外说清楚，否则协作方仍会按旧范围安排工作。若连续多个版本都靠缩范围才按时发布，说明间隔下限测算偏乐观，应重新核算容量与间隔。
未完成项默认顺延到下一版本，会带来什么问题？
默认顺延会让下一版本的可用容量在规划前就被占用，节奏基线随之失效。建议在版本收尾时逐项登记去向：仍符合下一版本目标且工作量完整的整项顺延并记录理由；部分完成且可分割的拆成已完成与剩余两部分，已完成部分随当前版本验收；目标已变化或优先级下降的移出近期范围，回到待规划池。去向由产品负责人决定、项目管理记录，下一版本规划时先扣除已顺延项再测算容量。
规划生效后，什么情况下需要重新测算容量和间隔？
建议设定明确的调整触发条件，例如连续两个版本出现超载、范围在冻结后频繁变更、跨版本依赖多次未按期就绪，或固定开销占比明显上升。出现任一情况时，重新统计最近若干周期的完成量、取中位数、扣除固定开销并复核缓冲比例，再对照间隔下限判断节奏是否需要调整。调整结论与原因记入变更记录，与版本计划同步发布，避免各角色按不同口径排期。
