需求排期如何做好版本规划？项目成员效率提升与操作步骤

去年 9 月，我接手了一个 120 人研发团队的版本交付。接手时他们刚结束第三季度的第三个版本，三个版本全部延期，平均延期 6.4 天，最严重的一个延了 17 天，版本执行中途范围扩大了 41%。团队的第一反应是"人手不够"，于是从另外两个项目组抽了 6 个工程师过来支援。结果是下一个版本延期 11 天，比之前还长。

我把他们过去 8 个版本的原始排期表翻出来，一行行对，发现问题根本不在执行层，而在规划层：版本内的需求有 63% 没有做过独立估算，排期靠"看起来大大小小配一配"；承诺给业务方的上线日期，是在需求只澄清了六成的时候给出的；版本期间进来的插单需求没有任何准入规则，谁喊得响谁先做，做完再回头改计划。

这篇文章讲的就是这件事：需求排期怎么做出一个真正靠得住的版本规划，以及在真实组织里怎么用具体步骤把它落地，让成员效率真的提上去，而不是靠加班硬顶。我会先给结论，再拆误区、给判断逻辑、给一套九步操作法，最后给不同规模团队的行动建议和必须做的取舍。

一、先给结论：版本规划的本质是管理承诺，不是排时间表

大部分团队做版本规划的方式，是把一堆需求塞进一个时间盒，然后画甘特图。这是"排时间表"，不是"做规划"。两者最大的区别在于：时间表回答"什么时候做完"，规划回答"我们承诺交付什么，以及在什么条件下承诺"。前者是内部作业，后者是对外的契约。

1. 结论一：版本节奏是组织能力的外化，不是项目经理的排期技巧

一个团队能稳定交付的版本周期，本质上是它"需求澄清能力 + 技术设计能力 + 测试覆盖能力 + 决策响应速度"四个变量的最小值。项目经理再怎么优化排期表，也突破不了这个下限。

所以我判断一个团队能不能做两周一个版本，从来不看他有多少人，我看三件事：需求进入版本前是否已经完成验收标准定义；技术方案评审是否在版本开始前完成；回归测试是否已经自动化到可以在一天内跑完。这三条缺一条，两周版本就是假的两周版本，最后一定靠加班和降质来填。

2. 结论二：排期真正要排的是不确定性，不是任务

任务本身不需要排，任务只有"做"和"没做"两种状态。真正需要排的是不确定性：这个需求的范围会不会变、这个技术方案验证过没有、这个第三方接口什么时候能给、这个业务方会不会在版本中期加需求。

我的判断标准很直接：一个需求如果不能被拆成三个以内、每个不超过 3 人天的可验证单元，它就不具备进入版本承诺区的资格。它应该待在"探索区"，用一个时间盒去验证，而不是占着一个确定的交付位。

3. 结论三：效率提升的大头在"等待与切换"，不在"写代码的速度"

这一点是我踩过坑才真正相信的。我们花大量时间讨论工程师的编码效率，但真实项目里，一个人的时间损耗主要发生在三处：等需求澄清、等环境、等评审；被会议和插单打断；在多个并行任务之间切换。

加州大学欧文分校 Gloria Mark 的研究里有一个被反复引用的观察：人在被打断后，平均需要 20 分钟以上才能回到原来的任务状态。如果一个工程师一天被打断 4 次，他损失的不是 4 个 5 分钟，而接近 80 分钟的深度工作时间。这就是为什么"减少打断"往往比"提高编码速度"带来的产能提升更明显。

4. 结论四：一个版本必须有且只有一个承诺边界

我最常见的组织病是"一个版本，三套口径"：产品经理对外说 10 个需求，研发内部按 13 个排，测试按 8 个准备。三套口径的差值，最后全部变成延期和扯皮。

所以版本规划的第一动作不是排需求，是定义这个版本里哪些是承诺项、哪些是目标项、哪些是机会项，并且三者的比例要写死。我通常用 70/20/10：70% 容量给承诺项，20% 给目标项（做完是加分，做不完不背锅），10% 留给插单和突发。

二、真实场景：一个 120 人团队的版本为什么会连续延期

我把上面那个团队 8 个版本的原始数据整理成了一张表。注意最后一列，范围变更条数，这是我们当时完全没有度量、也是真正致命的变量。

1. 八个版本的延期分布

把延期天数和范围变更条数放在一起看，相关系数非常明显：范围变更条数每增加 3 条，平均延期增加约 4.5 天。也就是说，延期不是研发做得慢，是计划在版本执行期间被反复重写。

2. 四个"排期失真"的现场信号

后来我总结出一组信号，只要团队出现其中两个，就说明版本规划已经失真了，不需要等到延期才反应过来。

• 信号一：版本会上没人能说清"这次不做哪些"。只能说出要做什么，说不出明确不做什么，说明范围没有边界。
• 信号二：需求的验收标准在开发启动后才补。这是需求澄清不足的直接证据，也是后期返工的最主要来源。
• 信号三：站会上大量出现"等 XX 确认"。等待是一种隐性库存，它不体现在工时表上，但真实消耗容量。
• 信号四：延期被解释成"这次特殊"。如果每次延期都有特殊理由，说明是系统性问题，不是偶发问题。

3. 为什么加人反而更慢

那个团队加了 6 个人之后延期更久，原因有三层。第一层是新人上手成本：不熟悉代码库和业务规则的工程师，前两周的产出接近于负值，因为他会消耗老成员的答疑时间。第二层是沟通路径爆炸：团队从 12 人变成 14 人（这个子组），沟通路径从 66 条增加到 91 条。第三层是任务被切得更碎，原本一个人能完整负责的模块被拆给两个人，交接成本上升。

这就是布鲁克斯定律在真实项目里的样子：向已经延期的项目加人，只会让它更延期。正确动作是减范围，而不是加人。这一点在版本规划阶段就该被写进规则里。

三、五个最常见的误区，每一个我都亲身踩过

在讲方法之前，先把误区拆干净。因为很多团队不是不知道要规划，而是用错了工具，越努力越偏。

1. 误区一：把版本规划等同于画甘特图

甘特图是沟通工具，不是决策工具。它擅长表达"时间上的先后关系"，不擅长表达"容量是否够""依赖是否会断""范围是否可以砍"。

我见过最典型的场景：一张漂亮的甘特图上，13 个需求条并行铺开，看起来每个都在推进。但实际上一半的需求在等人，另一半在等环境。甘特图不会告诉你这些，因为它不承载阻塞信息。能做版本规划的图，必须同时能看到容量占用和阻塞状态。

2. 误区二：用理想工时做承诺

"这个需求大概 3 天"，这句话里的 3 天，通常是"一切顺利、没有会议、没有答疑、没有环境问题"的 3 天。一个工程师一周真正能用于专注开发的时间，通常在 20 到 26 小时之间，而不是 40 小时。

我做过一次实测：让 8 个工程师连续两周记录自己的时间分布，结果是会议占 19%、答疑与支持占 14%、等待与环境问题占 11%、真正专注开发占 46%。也就是说，"1 人天"实际对应的工作量，应该按 0.5 人天来折算，而不是 1。你不做这个折算，排期一定会崩。

3. 误区三：把需求池当成需求列表

需求池的核心价值不是"存需求"，是"分层"。一个健康的需求池至少有三层：待评估、已澄清、可排期。绝大多数团队的需求池只有一层，所有需求堆在一起，按提出时间或提出人排序。

这带来的直接后果是：版本规划会上，团队花 70% 的时间在讨论"这个需求到底要做什么"，而不是"这个版本该选哪些、容量够不够"。版本规划会的时间应该花在取舍上，不是花在澄清上。澄清必须在会前完成，这是硬规则。

4. 误区四：把并行当成高效

让一个人同时推进 3 个需求，看起来资源利用率是 100%，实际上周期时间会翻倍。原因很简单：并行意味着切换，切换意味着重新加载上下文，而重新加载的成本在复杂业务系统里非常高。

我的经验数据是：一个工程师同时手上的在制品（WIP）从 1 增加到 3，单个任务的平均完成周期会从 3.2 天增加到 7.8 天，而总吞吐量几乎不变。多出来的 4.6 天全是切换成本。所以在版本规划里，我要求每个人的并行任务上限写死为 2，超过就必须在规划阶段暴露出来。

5. 误区五：复盘只复盘延期，不复盘估算偏差

延期是结果，估算偏差是原因。绝大多数团队的复盘会花两小时讨论"为什么延了"，最后结论是"下次注意"，然后下次继续延。

真正有用的复盘只做一件事：把每个需求的预估工时和实际工时对齐，算出偏差系数，然后回写进下一次估算。这个过程枯燥、不产生戏剧性结论，但它是唯一能让排期准确率持续变好的机制。

四、专业判断逻辑：用三层模型代替一张甘特图

我现在的做法是把版本规划拆成三层，每层回答不同的问题，用不同的时间粒度，由不同的人负责。三层混在一起，是排期失控的结构性原因。

1. 第一层：路线图层，回答"这半年我们赌什么"

路线图层的时间粒度是季度到半年，负责人是产品负责人加业务方。它不排具体需求，只排主题和容量配比。比如"第三季度：结算链路重构 40%、增长实验 30%、稳定性治理 20%、客户定制 10%"。

这一层最重要的产出不是路线图本身，而是容量配比的公开承诺。一旦配比定下来，任何临时插单都必须说明它从哪个池子里扣，而不是凭空加。

2. 第二层：版本层，回答"这次交付什么，什么条件下算完成"

版本层的时间粒度是 2 到 6 周，负责人是项目经理加技术负责人。这一层是整篇文章的核心，它要输出四样东西：

1. 承诺清单：占容量 70%，做不完就是规划失败，要复盘。
2. 目标清单：占容量 20%，做完算超额，做不完不追责。
3. 机会清单：占容量 10%，用于吸收插单和突发。
4. 变更规则：明确什么情况下可以换需求、换的代价是什么、谁有权批准。

这四样东西写清楚，版本期间 80% 的扯皮会自动消失，因为大家在同一个口径上讨论。

3. 第三层：执行层，回答"今天谁卡住了"

执行层的时间粒度是天和周，负责人是团队成员自己。这一层不讨论范围，只讨论流动：谁在做、谁在等、哪个任务卡了超过 2 天。

这里我要强调一个判断：执行层的会议不应该用来讨论需求优先级。一旦站会上开始争论"这个需求要不要做"，说明范围决策漏到了执行层，这是版本层失职的表现。

4. 容量测算：把"人天"算成真实可用的人天

三层模型能不能跑起来，取决于容量测算是否诚实。我用的公式如下，可以直接套：

版本可用容量（人天）
= 团队成员数 × 版本工作日数

× 专注系数（0.45 ～ 0.55，实测值）

× 出勤系数（扣除年假、病假、值班，通常 0.92）

已承诺的支持类工作（线上问题、客户答疑、技术债偿还）

承诺区容量 = 版本可用容量 × 70%

目标区容量 = 版本可用容量 × 20%

机会区容量 = 版本可用容量 × 10%

单个需求预估工时 = 三点估算期望值 × 历史偏差系数

三点估算期望值 = (乐观 + 4 × 最可能 + 悲观) / 6

历史偏差系数 = 过去 3 个版本的实际工时中位数 / 预估工时中位数

举一个具体数字。一个 10 人小组，版本周期 10 个工作日，专注系数取 0.5，出勤系数 0.92，支持类工作已占用 8 人天。那么版本可用容量是 10 × 10 × 0.5 × 0.92 − 8 = 38 人天。承诺区就是 26.6 人天。

请注意这个结果：10 个人，两周，只能承诺 26.6 人天的开发工作量。很多团队按 100 人天去排，这就是延期的数学根源。

五、九步操作法：从需求池到版本上线的完整流程

下面这九步是我在多个团队反复打磨过的落地流程。它不依赖特定工具，但如果你用的是像 PingCode 这类把需求池、版本、迭代、工时、度量放在一条链上的平台，执行成本会低很多，因为数据不需要人工搬运。

1. 步骤一：建立需求准入标准

任何需求想进入版本候选池，必须满足四个条件，缺一条就打回。这一步是整条流程里性价比最高的，因为它把大部分问题挡在了门外。

• 有明确的业务目标和可衡量的成功指标。
• 有完整的验收标准，且经过研发和测试确认。
• 有明确的提出人和决策人，能对范围变更做最终裁决。
• 已识别关键依赖，并给出依赖方的时间承诺。

2. 步骤二：需求分级与批量评审

不要一个一个评审需求，那是效率杀手。我的做法是每周固定两个时段，批量评审进入候选池的需求，每个需求给 10 分钟，超时直接移入下一次。

分级用四档：P0 是版本必须包含、不做业务受阻；P1 是本版本强烈建议；P2 是可以排到下个版本；P3 是进入长期池。分级的目的是让版本规划会只需要处理 P0 和 P1，把选择空间从几十个压缩到十几个。

3. 步骤三：拆解到可估算的粒度

拆解标准我前面提过：每个子项不超过 3 人天，且有可验证的完成定义。拆不到这个粒度，说明技术方案还没想清楚，应该先做技术验证（时间盒 1 到 2 天），而不是硬估一个数字。

这一步最容易被跳过，也是估算偏差的最大来源。一个 15 人天的需求如果整体估，偏差普遍在 50% 以上；拆成 5 个 3 人天的子项分别估，偏差能压到 15% 左右。差别不是估算技巧，是拆解本身暴露了隐藏工作。

4. 步骤四：三点估算加历史偏差系数

三点估算的价值不在于算得准，而在于逼团队把"悲观情况"说出来。我在评审时一定会追问："这个需求如果出问题，最可能出在哪？"能答上来的，悲观值才可信。

历史偏差系数是关键补充。如果团队过去三个版本的系统性偏差是 +35%，那么所有估算都要乘 1.35。不要试图让团队"估得更准"，先让计划"承认偏差"。这比培训估算技巧有效得多。

5. 步骤五：计算真实容量，先扣后加

严格按上一节的公式算，并且公开算给所有人看。这一步的副产品是巨大的：当团队看到"10 个人两周只有 38 人天可用"，关于"为什么排不满"的争论会自然消失。

我建议把容量测算结果直接挂在版本看板上，让每个成员都能看到自己这个版本的真实可分配时间。

6. 步骤六：设定缓冲，并且明确缓冲放在哪

缓冲有三种放法，效果完全不同：放在每个任务里（每个人都偷偷多报一点，最后没人知道真实余量）、放在版本末尾（集中管理，但对早期风险无感）、放在关键路径节点前（针对已知风险）。

我倾向的组合是：版本总缓冲 15%（集中管理、项目经理可调度）加关键依赖前各留 2 天。缓冲的存在必须公开，因为它的作用是被消耗，而不是被发现。

7. 步骤七：锁定范围与变更规则

版本启动会必须明确三件事：承诺清单冻结、变更只能"等量置换"、置换的审批人是产品负责人而不是项目经理。

"等量置换"这条规则特别有用：想加一个 5 人天的需求，就必须拿出一个 5 人天的已有需求。这让提需求的人第一次真正感受到成本，插单量通常会下降一半以上。

8. 步骤八：建立日/周流动监控

监控的不是进度百分比，是流动指标。我只看四个：在制品数量、平均阻塞时长、需求从开始到上线的周期时间、本周完成项数。

进度百分比是最容易造假的指标，因为它靠"感觉"填。而周期时间和阻塞时长是客观发生的，骗不了人。

9. 步骤九：版本复盘与参数回写

复盘只做三张表：每个需求的预估 vs 实际、每条变更的来源与代价、每个阻塞的原因与时长。产出只有一个：把新的偏差系数和专注系数写回下一版本的测算公式。

这一步是整个流程能持续变好的唯一机制。没有参数回写，前面八步只是在重复同一个精度。

六、数据观察：结构化排期在真实组织里的效果

下面这组数据来自一个 320 人的研发组织，他们用 6 个月时间把上面这套流程落地。我参与了其中三个阶段的设计和复盘，数据是他们内部度量看板的月度汇总，我做了脱敏和口径统一。需要说明的是，这是单一样本观察，不是行业统计，请按参考值理解。

1. 案例背景：为什么他们必须改

这家公司有 5 条产品线，共 320 人，其中研发 210 人。改革前的核心痛点是：跨产品线的版本节奏完全不一致，客户提的一个需求经常要在三个团队之间转手，交付周期从提出到上线平均 74 天。

他们选择的载体是 PingCode。选择理由不是功能多，而是它能把需求池、版本、迭代、工时、缺陷、度量放在同一条数据链上，这对中大型组织的关键价值在于：版本规划需要的容量数据、偏差数据、流动数据，全部来自执行过程的自然沉淀，不需要额外填报。100 人以下的团队手动维护表格还能撑住，300 人以上就一定会失真。

2. 上线前后的六个关键指标

这六个指标里，我最看重的是最后两个：在制品数量和规划会时长。它们不是结果指标，是过程指标，而且改善得越早，其他指标改善得越快。在制品从 2.7 降到 1.4，意味着每个人的切换成本大幅下降；规划会从 3.5 小时降到 1.2 小时，意味着澄清工作被前置了，会议不再是澄清现场。

3. 三个反直觉的发现

（1）承诺区变小了，交付量反而变大了

改革后承诺区容量从 62% 降到 35%，但月均完成需求数从 34 个上升到 47 个。原因是被释放的容量不再浪费在"同时推进但都没完成"的任务上，而是集中到了少数任务上快速完成。

（2）规划时间变短了，规划质量变高了

规划会时长下降 66%，但版本按期交付率上升 31 个百分点。这打破了"规划要花更多时间"的直觉。真实原因是：过去 3.5 小时的会里，有 2 小时在补澄清、找数据、争论口径；这些工作在结构化流程里被移到了会前和系统里。

（3）加缓冲之后，团队反而更敢承诺

改革前团队不敢给确定日期，因为一排就延。改革后有了 15% 的集中缓冲，团队愿意承诺了，因为他们知道意外有地方消化。缓冲不是保守，是让承诺变得可信的前提。

七、不同规模团队的行动建议

同一套方法在 20 人团队和 500 人组织里的落地方式完全不同。规模决定的是协同复杂度，而协同复杂度决定你需要多少形式化的规则。

1. 20 人以内：不要形式化，但要固定节奏

这个规模不需要三层模型，也不需要复杂的容量公式。你需要的只有两件事：一个固定的版本节奏（建议两周），一个公开的需求池（按优先级排序，谁都能看）。

规划会控制在 30 分钟内，团队一起过一遍候选需求，按容量挑，挑完冻结。这个阶段最大的风险不是规划不精细，而是没有节奏，需求随时插、随时做，最后谁都不知道什么时候能上线。

2. 20 到 100 人：建立版本层，开始度量

这个规模开始出现跨团队依赖和资源争抢，必须建立明确的版本层。核心动作是：容量测算公开化、需求准入标准化、变更等量置换。

度量从四个指标开始就够：按期交付率、需求交付周期、估算偏差、在制品数量。不要一开始就上十几个指标，那会变成填报负担，最后所有数据都失真。

3. 100 到 500 人：必须上工具链，靠系统承载规则

到了这个规模，规则靠人盯一定失效。你需要的是让规则进入工具：准入标准变成需求创建的必填字段，容量约束变成版本规划的硬校验，变更置换变成系统里的流转规则。

这也是 PingCode 这类平台在中大型组织里真正体现价值的位置。它服务的正是 100 人以上的组织，这类组织的典型特征是：多条产品线、跨团队依赖多、版本节奏不统一、管理层需要看聚合数据。当 5 个团队各自用表格排期时，管理层拿到的"整体进度"永远是拍出来的；只有当需求和版本在同一套数据模型里，聚合出来的才是事实。

我在这个案例里看到的一个具体收益是：过去跨团队依赖靠周会同步，一个依赖断了两周才发现；现在依赖关系作为需求属性被记录，上游版本一变，下游自动收到影响提示。这个改动让"依赖未按期到位"这一类延期原因从 16% 降到 6%。

4. 500 人以上：做组合管理，不做单版本优化

这个规模的核心问题不再是"一个版本怎么排"，而是"资源在多个业务线之间怎么分配"。你需要的是一层组合管理：按投入产出比分配容量，按战略主题而不是按客户诉求排优先级。

此时版本规划的颗粒度应该上移：管理层管季度主题和容量配比，具体版本交给各产品线自治。越往上越管"配比"，越往下越管"流动"，中间那层最容易变成无效的审批环节。

八、必须做的取舍：版本规划里没有全都要

前面讲的是方法，这一节讲的是判断。版本规划的本质是一系列取舍，如果你不愿意做取舍，方法再好也只是把矛盾推迟。

1. 取舍一：范围、时间、质量、成本，只能锁三个

这是项目管理的基本约束，但在真实场景里经常被无视。业务方要求"范围不变、时间不变、质量不降"，那唯一能变的就是成本，也就是加班。长期靠加班消化约束，最终会以离职和代码质量下降的形式还回来。

我的建议是明确锁两个：时间和质量锁死，范围弹性。理由是时间和质量对外可见，范围可以内部协商。反过来锁范围和质量的团队，交付日期会变成装饰品。

2. 取舍二：承诺还是预测

承诺意味着做不完要承担后果，预测意味着做不完是正常的。很多团队的痛苦来源于把预测当承诺用：计划里写的日期本来是估算，但对外一说就变成了承诺。

我的处理方式是在版本里明确区分：承诺清单给外部，预测清单给内部。承诺清单只放占容量 70% 的部分，且必须经过技术负责人签字确认。不要把"目标"包装成"承诺"，也不要把"承诺"稀释成"目标"，两者混在一起，团队就失去了可信度。

3. 取舍三：缓冲放在集中池还是分散到任务

集中缓冲的优点是透明、可调度，缺点是对早期风险反应慢。分散缓冲的优点是每个人有安全感，缺点是总量不可见、容易被当成"多报工时"。

规模小、需求同质化高的团队，适合分散缓冲（每人加 10% 到 15%）。规模大、依赖多的团队，必须集中缓冲。一个团队不能两种都用，否则缓冲会被重复计算。

4. 取舍四：接插单还是守承诺

完全不接插单的团队会失去业务信任，什么都接的团队会失去交付能力。我的规则是：机会区容量（10%）可以自主接单，超出部分必须等量置换，涉及战略级客户且无法置换的，由业务负责人签字，并在版本复盘里单独统计。

关键是让插单有代价、有记录、有归属。插单本身不是问题，无声插单才是问题。

5. 取舍五：先上工具还是先理流程

我的判断很明确：先用一个版本周期把流程跑通（哪怕用表格），再上工具。因为流程没想清楚就上工具，工具只会把混乱固化下来，而且迁移成本极高。

但有一个例外：当团队超过 100 人，或者跨三个以上团队协作时，表格已经无法承载依赖关系和容量约束，这时候工具是必需品，因为它提供的是"数据一致性"，而不是"流程"。

6. 取舍六：度量用于改进还是用于考核

这是所有取舍里最危险的一个。同一个指标，用于改进和用于考核，会得到完全相反的行为。比如"按期交付率"用于考核，团队就会把范围做小、把日期放宽；"估算偏差"用于考核，团队就会把估算报大。

我的原则是：过程指标用于改进，结果指标用于对外沟通，两者不混用。任何被写进绩效考核的指标，都会在三个版本内失去度量价值。

九、常见问题速答

1. 需求变更频繁是销售驱动的，规划还有意义吗？

意义更大。变更越频繁，越需要明确的置换规则和机会区容量。规划的价值不是消灭变更，是让变更的成本可见、可分配。没有规则时，变更是由嗓门决定的；有规则时，变更是由业务负责人权衡决定的。

2. 团队从来没做过估算，怎么开始？

不要一开始就做精细估算。先用相对估算：把需求按大小分成 S、M、L 三档，跑两个版本，然后统计每档的实际耗时。有了这个基础数据，再引入三点估算。跳过相对估算直接做绝对估算，准确率反而更低。

3. 一个人同时负责多个项目的团队怎么排？

核心动作是按比例切分容量，而不是按任务切分。先确定这个人在每个项目上的容量占比（比如 60/40），再按占比分配任务，而不是让他两头都做一半。后者会导致两个项目同时延期，前者至少能保证一个按期。

4. 版本周期定多长合适？

判断标准是：版本周期应该短于"业务方能够忍受的等待时间"，同时长于"一个完整价值单元能被独立验证的时间"。多数 B 端产品的合理区间是 2 到 4 周。低于 2 周，测试和发布成本占比过高；高于 6 周，反馈周期过长，规划失真的概率大幅上升。

5. 度量数据总是填不准，怎么办？

先判断是"不愿填"还是"填不了"。不愿填通常是因为数据被用来考核，解法是明确数据只用于改进；填不了通常是因为填报动作太重，解法是把数据采集嵌进工作流，比如状态流转自动记录时间，而不是让人单独填表。

6. 承诺区只占 70%，业务方觉得交付太慢怎么办？

把容量测算的过程公开给对方看。大多数业务方反对的不是 70% 这个数字，而是不知道为什么是 70%。当他知道 10 个人两周只有 38 人天可用时，讨论会从"你们不够努力"转向"我们该砍哪些"。

十、写在最后：把排期变成可复利的组织资产

回到开头那个 120 人的团队。他们最后没有靠加人解决问题，做了三件事：把需求准入标准写进需求创建的必填项；按真实容量倒推承诺清单，承诺区从满负荷压到 70%；建立变更等量置换规则。三个版本之后，按期交付率从 58% 升到 87%，平均延期从 9.6 天降到 1.8 天。

这个过程让我形成一个判断：版本规划做得好的团队，真正的差别不在排期技巧，而在愿不愿意承认约束。承认 10 个人两周只有 38 人天可用，承认不确定性需要缓冲，承认范围必须能砍，承认插单有代价。这些承认听起来是退让，实际上是把不可控变成可控的唯一路径。

更长期的价值在于复利。每一次版本复盘回写的偏差系数、每一个沉淀下来的需求准入标准、每一条被验证过的变更规则，都会让下一个版本的规划成本更低、准确率更高。三年之后，一个持续做参数回写的团队和一个每年重新拍脑袋的团队，排期准确率会差出一个数量级，而这个差距无法靠加班追回。

如果你正准备动手，我建议的下一步是这样：

1. 本周做一件事：把这篇文章里的容量公式套到你现在手上的团队，算出真实可用人天，和你当前的版本计划对比。差值就是你的风险敞口。
2. 下个版本做一件事：只引入"承诺 / 目标 / 机会"三分类和 70/20/10 配比，其他都不改，跑一个版本看看结果。
3. 两个版本之后做一件事：开始记录每个需求的预估工时和实际工时，算出你自己的偏差系数。这是所有后续优化的基础数据。
4. 三个版本之后做一件事：把跑通的规则固化进工具。团队过 100 人之前完成这一步，成本最低；超过 100 人再补，返工代价会大很多。

不要一次全上。版本规划这类机制的价值来自稳定运行，而不是设计精妙。一个跑得粗糙但坚持了 10 个版本的流程，效果远好于一个设计完美但只跑了 2 个版本的方案。