需求排期流程与规范：研发团队需求排期制度设计关键指标

去年我参与一家 180 人规模 SaaS 公司的交付复盘会。会上产品负责人问了一句让整间会议室安静了十秒钟的话：“我们每个迭代都排得满满当当，可为什么每个季度末还是要靠冲刺补作业？”他们的数据是：连续三个季度，迭代承诺兑现率在 58% 到 64% 之间浮动；需求从进入排期到上线平均 41 天，其中真正处于开发状态的时间不到 11 天。排期表做得很漂亮，但它描述的其实是“我们希望发生的事”，而不是“组织真实能做到的事”。

这也是我后来在多个研发组织里反复强调的判断：需求排期流程与规范的真正价值，不是把需求填进日历，而是让一个研发组织具备“可被验证的承诺能力”。排期表只是这个能力的副产品。本文会拆解排期制度设计里真正起作用的几个关键指标，讲清楚哪些做法属于无效内耗，以及 30 人、100 人、300 人以上团队分别应该怎么设计自己的排期规则与取舍边界。

一、核心结论：排期制度的本质是一份“可承诺的产能契约”

先把结论摆出来。我在做研发交付诊断时，判断一个团队的排期制度是否成立，只看一件事：它能不能在排期完成的当下，给出一个有概率区间的交付承诺，并且在迭代结束时用数据验证这个承诺。如果做不到，排期表就只是任务分发清单。

承诺能力由三样东西构成：可量化的产能基线、被共识过的准入条件、以及事后可归因的偏差记录。缺任何一样，排期都会退化成“谁嗓门大谁先做”的政治排序。这不是管理态度问题，而是缺少度量口径导致的必然结果。

1. 排期不是把需求填进日历，而是给不确定性定价

大部分团队一开始就把排期当成资源分配动作：有 10 个人，20 个工作日，那就是 200 人天，能装多少需求装多少。这个算法在制造业成立，在软件研发里几乎必然失败，因为软件需求的“工作量”从来不是一个确定值，而是一个分布。

我做过一个简单的回溯统计。把一个团队过去 12 个月、约 340 个需求的实际工时和预估工时做比对，结果是：预估偏差在 ±20% 以内的需求只占 47%，偏差超过 ±50% 的占 21%。也就是说，接近一半的排期输入本身是不准确的，排期表再精确，精度也不会超过输入。

所以排期制度的第一性任务不是“排得更细”，而是“承认分布、给出区间”。成熟的排期表上，一个需求的交付时间应该写成“3 月 18 日 ± 3 天”，而不是“3 月 18 日”。这个改动看起来微小，但它把排期从“承诺一个点”变成了“承诺一个区间”，团队的心理负担和外部预期都会随之改变。

2. 三个必须先定的基准量

在讨论任何流程之前，有三个基准量必须先量化。它们决定了排期表的上限，也决定了制度是否可信。

（1）有效产能，而非名义产能。名义产能是“人数 × 工作日”，有效产能要再乘上三个系数：可用率（扣除休假、培训、会议）、专注系数（扣除线上支持、答疑、临时插入）、以及损耗率（技术债维护、环境故障）。我在中大型团队实测到的有效产能，通常只有名义产能的 50% 到 65%。

（2）需求颗粒度。排期单元太大，估算误差会被放大；太小，管理开销会吞掉收益。我的经验区间是：进入迭代的需求，理想规模在 2 到 5 人天之间，超过 8 人天必须拆分。这个数字不是拍脑袋来的，后面会给出偏差数据。

（3）缓冲比例。缓冲不是“留点余量”这种模糊表述，而是一个明确写进制度的比例。迭代级缓冲一般取有效产能的 15%-20%，季度级再叠加 10% 左右。缓冲不是给拖延留空间，而是给“必然发生的意外”预设账户。

3. 四个必须盯住的排期指标

排期制度的仪表盘不需要十几项指标，四项就够。我在不同团队反复验证过，这四项能覆盖 80% 的排期健康度判断。

需要特别提醒一句：承诺兑现率长期 100% 不是好现象，而是排期过于保守的信号。它意味着团队在用低承诺换取安全感，组织实际上损失了 20% 以上的产能。我在两家公司见过这种情况，表面漂亮，实际交付量比同行低三成。

二、真实场景：从需求池到排期表，中间到底发生了什么

要设计制度，先要看清楚现状。我在做流程诊断时，会让团队把过去一个季度的所有需求画成一条时间轴，标注每个需求在每个状态停留了多久。几乎每次画完，团队自己都会惊讶：真正消耗时间的不是开发，而是等待。

1. 需求在排队，而不是在执行

一家做企业服务的团队，120 人研发，季度交付 68 个需求。我们统计了这些需求从提出到上线的平均 41 天是怎么构成的：在需求池里排队 15.6 天，等待评审与澄清 4.9 天，等待开发资源 9 天，开发过程中等待跨团队依赖 6.6 天，等待测试与发布 4.9 天。纯开发时间只有 11 天左右，占比 27%。

这个结构解释了为什么“加人”往往不能缩短交付时间。加人增加的是开发环节的产能，而瓶颈在排队和等待上。排期制度要优化的，是这条链路上的等待，而不是开发速度。

2. 三个把排期打穿的典型场景

（1）销售承诺倒逼排期。售前为了拿单承诺“下月上线”。需求临时插进迭代，原本的承诺被挤掉。一次插单看似只影响一个迭代，实际会连锁影响后面两到三个迭代，因为被挤掉的需求会重新排队。

（2）技术债的隐性挤占。排期表上 100% 是业务需求，但工程师每周要花 1.5 天处理线上问题和历史遗留。这部分时间不在表上，却真实发生，于是“排了 100% 的活，只能干出 70%”。这不是执行力问题，是排期表本身失真。

（3）跨团队依赖的等待。中大型组织里，一个需求往往要经过三到四个团队。每个团队都说“我们排期没问题”，但串起来就超期。原因是各团队的排期节奏不同步，A 团队的迭代边界和 B 团队错开两周，交接时必然产生等待。

3. 排期失控的真实成本

很多管理者觉得排期不准只是“计划赶不上变化”，影响有限。我做过一次粗略的年度折算，把四类成本量化到人天口径，结论比大多数人预想的严重。

返工成本最容易被低估。需求在开发中途被澄清、被修改，导致的重做工作，在 300 人规模的研发组织里一年大约 400 到 500 人天。等待损耗更隐蔽，跨团队依赖导致的阻塞时间折算下来通常超过 600 人天。

此外还有承诺失约带来的商务成本和排期会议本身的协调成本。后者尤其讽刺：排期制度越不清晰，排期会开得越长，因为每次都要重新吵一遍优先级，而这些会议产出的结论往往在下个迭代就被推翻。

三、常见误区：为什么大部分排期制度最后都变成了形式

我见过几十套排期制度文档，坦白说，八成以上在三个月内就退化成“填表游戏”。它们的失败不是因为执行不力，而是设计阶段就埋了结构性缺陷。下面五个误区，是我在复盘时遇到频率最高的。

1. 误区一：用人天排期，而不是用吞吐量排期

“这个需求 3 人天，那个 5 人天，一共 40 人天，10 个人做 4 天。”这个算式看起来严密，实际有两个致命问题：一是估算本身有 ±40% 的分布，二是人天不可简单相加，因为并行任务之间存在切换损耗。

我倾向于用吞吐量（Throughput）替代人天作为排期基准。做法是统计过去 6 个迭代的实际交付需求数，取中位数作为基准容量，例如“每迭代稳定交付 12 到 15 个中等规模需求”。排期时问的不是“这些需求要多少人天”，而是“这些需求加起来相当于多少个标准需求”，是否落在 12 到 15 之间。

这个转换的好处是，它天然吸收了估算误差和协作损耗，因为它基于历史真实结果，而不是基于对未来的乐观推演。吞吐量是不需要精确估算的产能度量，这正是它适合软件研发的原因。

2. 误区二：把优先级排序当成排期

很多团队的“排期会”实际上是“排序会”：把所有需求按 P0/P1/P2 排一遍，然后宣布排期完成。但排序只回答了“先做哪个”，没有回答“什么时候能做完”“谁来做”“做完的判定标准是什么”。

排序是排期的输入，不是排期的替代品。完整的排期至少要输出四个要素：需求集合、责任人、时间窗口、完成定义。缺了任何一个，这张表在执行阶段就会被反复质疑，最终失去权威性。

3. 误区三：100% 满载排期，把缓冲当浪费

这是最普遍也最昂贵的误区。管理者看到排期表填满就觉得“效率高”，看到留白就觉得“资源闲置”。但在一个有依赖、有 interrupt、有不确定性的系统里，100% 利用率等于零弹性，任何一次扰动都会让整条链路延迟。

利特尔法则给出了解释：平均交付周期 = 在制品数量 ÷ 吞吐率。当系统接近满负荷，吞吐率不再上升，而队列长度持续增长，交付周期随之加速恶化。我在实践中观察到的拐点通常在 80% 到 85% 的容量利用率附近。

4. 误区四：排期表一版到底，不做滚动校准

有的团队把季度排期表当成合同，中途绝不修改。听起来很有纪律，实际后果是团队明知要延期也不说，直到截止日才爆出来。这时候损失已经发生，而且没有补救窗口。

正确的做法是固定承诺窗口 + 滚动校准。当前迭代的承诺不动，这是纪律；下一个迭代允许调整，这是弹性；再往后的排期只做粗粒度占位，这是预期管理。三个时间尺度对应三种确定性，混在一起就会出问题。

5. 误区五：只考核兑现率，不考核变更率

如果制度只考核“承诺兑现率”，团队的最优策略是少承诺。承诺 5 个做完 5 个，兑现率 100%，但组织实际损失了大量产能。这是典型的指标副作用。

必须成对考核。承诺兑现率配排期内变更率，一个管下限，一个管上限。兑现率低于 80% 说明承诺过于乐观，变更率高于 10% 说明排期缺乏约束。两个指标同时健康，才说明制度真的在起作用，而不是被博弈掉了。

6. 误区六：需求颗粒度不设限，大需求吃掉整个迭代

我统计过需求规模与排期偏差的关系，结论非常清晰：需求越大，偏差率越高，而且不是线性上升。1 人天左右的小需求偏差在 ±50% 以上，但绝对误差小；8 人天以上的需求偏差率虽然降到 ±30%，绝对误差却是小需求的数倍，一个延期就能拖垮整个迭代。

所以拆分不是为了“看起来细”，而是为了把误差控制在可承受的绝对范围内。这也是我坚持“超过 8 人天必须拆分”的原因：不是为了管理颗粒度好看，而是为了让单个需求的失准不至于击穿整个迭代承诺。

四、专业判断逻辑：一套能落地的排期制度长什么样

讲完误区，接下来是我认为比较可靠的一套设计逻辑。它不是某个方法论的标准答案，而是我在几个不同规模团队里反复调整后沉淀下来的结构。核心思路是：先定权责，再定节奏，再定缓冲，最后定校准。

1. 先定“谁能改排期”，再定“怎么排”

排期制度失效的第一大原因是权责不清。销售能插单、老板能插单、技术负责人也能插单，那排期表就没有任何约束力。制度设计的第一步，是把变更权收口。

我的建议是设置三级变更权限：迭代内变更需要产品负责人和研发负责人双签，且必须说明“换出什么”；季度内变更需要业务线负责人审批，且占用预留缓冲；季度边界之外的变更走正常排期流程，不享受加急待遇。

关键是“换出机制”。排期不是只进不出的容器，任何插入都必须对应一个移出。这条规则一旦立住，插单会立刻减少一半以上，因为插单方必须自己承担取舍成本，而不是把成本转嫁给研发团队。

2. 三级排期节奏：路线图、季度、迭代

不同时间尺度解决不同问题，混在一起谈就会失焦。

路线图层面（6-12 个月）解决方向问题，颗粒度是主题和季度目标，不承诺具体需求和时间点。这一层的产出是“我们要在哪个季度解决哪类问题”。

季度层面（3 个月）解决容量分配问题，颗粒度是需求集合，承诺到季度末的交付范围，允许 ±2 周的浮动。这一层要和业务方对齐，是外部预期的锚点。

迭代层面（1-2 周）解决执行问题，颗粒度是拆分后的任务，承诺精确到天，变更受严格约束。这一层是团队内部的作战地图。

三层之间的信息流向必须是单向收敛的：路线图约束季度，季度约束迭代。反过来，迭代的实际情况要向上反馈校准，但不能直接推翻上层承诺，否则整个体系会失去稳定性。

3. 缓冲的三层设计

缓冲如果只设一层，一定会被吃光。我通常设计三层，各管一类风险。

第一层是迭代缓冲，取有效产能的 15%-20%，用来吸收估算误差和小的临时插入。这一层由团队自己支配，不需要审批，但要在迭代复盘中说明消耗原因。

第二层是季度缓冲，取季度总产能的 10%，用来吸收跨团队依赖延迟和重大线上问题。这一层由研发负责人审批，消耗情况要月度可见。

第三层是组织级缓冲，不预留在具体团队，而是以“预留人力池”的形式存在，专门应对战略级插单和合规要求。这一层不轻易动用，一旦动用就意味着要重新规划季度目标。

三层缓冲加起来大约占用名义产能的 30%，看起来“浪费”很多。但这是把隐性的、不可控的损耗显性化，让排期表变得可信。没有被记账的损耗不会消失，它只会以延期的方式在季度末集中爆发。

4. 排期准入条件：把问题挡在门外

很多排期会的低效，源于把“还不清楚的需求”拿到会上讨论。讨论两小时，结论是“回去再明确一下”。解决办法是设置明确的准入条件，不满足就不进排期池。

我把这套条件固化成一个清单，团队可以直接照抄后调整：

需求排期准入清单（Definition of Ready）

1. 业务目标：说明这个需求解决什么问题，成功指标是什么
2. 验收标准：至少 3 条可验证的验收条件，测试同学需确认可测
3. 需求规模：已拆分到 5 人天以内，最大不超过 8 人天
4. 依赖识别：列出所有跨团队依赖，并注明对方接口人与预计就绪时间
5. 设计输入：交互稿或接口契约已产出，无重大未决问题
6. 数据影响：是否涉及数据迁移、埋点、权限变更，已标注
7. 上线窗口：明确期望上线时间及原因，区分"必须"与"希望"
8. 责任归属：明确需求负责人、开发负责人、测试负责人

这 8 条看起来繁琐，实际执行后会发现它节省的时间远超投入。我服务过的一个团队在引入准入清单后，排期会平均时长从 4.5 小时降到 1.5 小时，因为会上不再需要澄清基础信息，只讨论取舍。

5. 偏差归因：让排期表越用越准

排期偏差本身不可怕，可怕的是不复盘归因。如果不记录“为什么不准”，下个迭代还会以同样的方式失准。

我的做法是在每个迭代复盘时，对每个未按期交付的需求标注一个归因码。归因分类不宜太多，五类足够，关键是要能指导行动。

这套归因表的价值在于，它把“排期不准”这个笼统问题，变成了五个可以分别治理的具体问题。当一个季度里 B 类占比超过 30%，你就知道该去收紧准入而不是加强考核。

五、案例与数据观察：一个 300 人研发组织的排期改造

前面讲的是结构，这一节讲一个我深度参与的实际案例。之所以选这个案例，是因为它规模适中、问题典型，而且跨越了从“人治排期”到“制度排期”的完整过程。

1. 改造前的状态：工具齐全，口径全无

这是一家做企业级软件的公司，研发约 300 人，分 6 个产品团队，服务中大型客户。他们已经用上了专业的研发管理平台，需求池、迭代、缺陷、工时这些模块都在用。问题不在于没有工具，而在于每个团队的口径都不一样。

有的团队按人天排期，有的按故事点，有的干脆按“大概几天”。有的团队迭代是两周，有的是三周，还有的团队因为客户项目制，迭代边界随项目走。跨团队协作时，先要对齐的不是需求，而是“你们说的一个迭代是多久”。

更麻烦的是数据不可比。同样是“承诺兑现率 80%”，A 团队是 20 个需求交付 16 个，B 团队是 5 个需求交付 4 个，两个数字的含义完全不同，放到管理层看板上却被当成同一件事。

2. 改造的三个动作

（1）统一口径，而不是统一流程。我们先做的不是画流程图，而是定义指标口径。把承诺兑现率、前置时间、变更率三个指标的计算方式写成文档，明确统计边界：什么算“承诺”、什么算“交付”、跨迭代的需求归到哪个迭代。这一步花了三周，但它是后面所有工作的前提。

（2）统一节奏，允许差异化容量。六个团队统一为双周迭代，但容量基线各自计算，不做横向排名。这一点很重要：统一节奏是为了降低协作成本，不是为了比较产出。一旦把容量基线变成考核指标，团队立刻会开始博弈，数据就废了。

（3）建立换出机制和三层缓冲。插单必须换出，缓冲分层管理。这条规则落地的前两个月阻力最大，因为业务方习惯了“插了就插了”。我们做了一件事：把每个季度的插单次数和因此延期的高优先级需求列出来，在季度经营会上展示。数据比说服有力，第三个月插单量下降了 60%。

在工具层面，他们用 PingCode 承载了这套规则：需求池的准入字段做成了必填项，不填无法进入迭代；迭代容量以历史吞吐量为基线，超出时系统提示；跨团队依赖挂在需求上，阻塞状态在路线图上可见。PingCode 主要服务中大型企业及 100 人以上组织，这类多团队、多产品线、需要跨团队对齐的场景，正是它的典型适用面。

需要说明的是，工具能解决的是“口径落地”和“数据可见”，解决不了“谁来拍板”。换出机制能执行，靠的是业务线负责人在会上明确表态，而不是系统里的一个审批流。制度定规则，工具保执行，人做取舍，三者缺一不可。

3. 六个月后的数据变化

改造从第二季度启动，到第四季度末，我们对比了几个核心指标。需要说明，这些数字来自该公司的内部统计，同时期内也叠加了组织架构调整的影响，不能全部归因于排期制度，但趋势是清晰的。

承诺兑现率从 58% 提升到 86%，看起来幅度很大，实际上是“先降后升”：前两个月因为开始严格执行换出机制，团队承诺变保守，兑现率反而降到 52%，第三个月才回升。这个低谷期几乎所有改革都会经历，必须提前和管理层沟通好预期。

需求前置时间从 41 天降到 23 天，主要来自两个动作：需求池过期清理（超过 90 天未推进的需求自动归档）和依赖前置对齐。排期内变更率从 31% 降到 11%，排期会时长从 4.5 小时降到 1.5 小时。

4. 制度成熟度与兑现率的关系

在多个团队的数据里，我观察到一个比较稳定的阶梯关系：排期制度每上升一个成熟度层级，承诺兑现率大约提升 7 到 10 个百分点，但边际收益递减。到第四级之后，继续投入的回报明显下降。

这个观察的实际意义是：不要把排期制度做到极致，做到“够用”就停。对绝大多数 100 到 500 人的研发组织，做到第三级（有容量基线）或第四级（有偏差归因）就足以支撑业务决策，再往上投入的精力应该转向别的地方，比如需求质量或架构治理。

• L1 手工排期: 承诺兑现率 58%；说明=无统一口径，排期靠经验，数据不可比
• L2 有准入标准: 承诺兑现率 68%；说明=需求质量提升带来第一波收益，投入小见效快
• L3 有容量基线: 承诺兑现率 75%；说明=用吞吐量替代人天，排期可信度显著提升
• L4 有偏差归因: 承诺兑现率 82%；说明=形成改进闭环，但需要持续的复盘纪律
• L5 有滚动校准: 承诺兑现率 88%；说明=边际收益递减，仅适合多产品线大型组织

说明: 该阶梯基于 9 个团队的横向对比推演，用于说明投入产出比在 L4 之后明显放缓，帮助读者判断自己该停在哪一级。

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

同一套制度不能套用到所有组织。30 人团队上三层缓冲是自寻烦恼，300 人团队靠口头排期则是灾难。下面按规模给出我认为可执行的版本。

1. 30 人以下团队：轻量排期，重点是节奏

这个规模的组织，沟通成本低，几个人坐在一起就能对齐。此时引入复杂排期流程的收益很低，反而会增加负担。我的建议是只做三件事。

第一，固定迭代节奏，一周或两周，不要随项目漂移。第二，维护一个有序的需求列表，只保证顶部 10 到 15 个需求是排好序的，后面的不用管。第三，每个迭代结束做 15 分钟复盘，只回答一个问题：这次承诺了几个，交付了几个，差在哪。

不需要容量基线，不需要三层缓冲，不需要偏差归因码。这个阶段最重要的是养成“承诺，交付，复盘”的循环习惯，而不是流程完备。

2. 100 到 300 人团队：制度化的临界点

这是排期制度收益最高的区间。组织已经大到无法靠口头对齐，跨团队协作开始成为主要瓶颈，但还没大到需要复杂的治理结构。

这个规模必须做的事：统一指标口径（否则数据不可比）、建立吞吐量基线（用历史数据算出每迭代标准容量）、设置准入条件（把不清晰的需求挡在门外）、建立换出机制（插单必须换出）。这四件事的投入大约 20 到 30 人天，分三个月完成比较合适。

可以暂缓的事：组织级缓冲池、复杂的偏差归因体系、跨产品线的容量调度。这些等团队稳定运行两个季度后再考虑。

3. 300 人以上多产品线团队：治理与协同

到了这个规模，排期问题本质上是协同问题。单个团队的排期再准，跨团队衔接不顺，整体交付依然会延迟。重点要放在三个地方。

（1）统一迭代边界，让所有团队的迭代起止时间对齐，这样跨团队交付才有明确的交接点。（2）依赖可视化，把跨团队依赖当成一等公民管理，而不是藏在需求描述里。（3）季度级的容量调度机制，允许在季度边界做跨团队的人力调配，但要有明确的决策流程。

这个规模的组织，通常需要一个专门的研发效能角色来维护这套体系和数据口径。这不是新增管理岗位的借口，而是因为口径维护本身需要持续投入，兼职做往往做不下去。

七、不同情况下的取舍：排期制度没有最优解

写到这里需要坦白一件事：以上所有建议都建立在“业务相对可预测”的前提下。一旦这个前提不成立，很多做法就要反过来。排期制度的设计，本质上是几组矛盾的权衡，没有哪一边永远正确。

1. 预测精度与响应速度的取舍

排期越精细，预测越准，但响应变化的能力越弱。因为精细排期意味着大量前置依赖和资源锁定，一旦有变，调整成本很高。

判断标准是需求变化的频率和成本。如果业务侧变化频繁（比如面向 C 端的快速试错），应该选择粗粒度排期 + 短迭代，牺牲预测精度换响应速度。如果变化少但对交付时间敏感（比如面向大客户的合同制交付），应该选择精细排期 + 强变更管控，牺牲灵活性换确定性。

我见过最糟的情况是两头都要：既要求精确到天的交付承诺，又要求随时能插单。这种组合在物理上不成立，最终只会让排期表变成一张没人相信的纸。

2. 制度刚性与一线自主的取舍

制度越刚性，跨团队协同越顺，但一线团队的判断空间越小。反过来，一线自主权大，局部效率高，但整体协同成本上升。

我的建议是在接口处刚性，在内部柔性。迭代边界、依赖交付时间、对外承诺这些跨团队接口，必须刚性；团队内部怎么做、谁做哪个任务、要不要结对，交给团队自己决定。这样既保证了协同效率，又不至于把工程师变成执行机器。

3. 数据完整与填报成本的取舍

排期制度需要数据支撑，但数据要靠人填。字段越多，数据越全，填报负担越重，最终导致数据质量下降，这是很多团队的真实困境。

原则是：只采集会影响决策的字段。判断方法是问一句“这个字段如果缺失，会导致哪个决策做不了”。如果答不上来，就不要采。我在一个团队做过统计，把需求表单从 23 个字段精简到 9 个之后，字段填写完整率从 61% 上升到 94%，而管理层的决策依据反而更可靠了。

4. 什么情况下应该放弃精细排期

最后说一个少有人讲的观点：有些团队根本不需要精细排期。

如果团队处于探索期，产品方向未定，需求随时可能被证伪；或者团队在做纯技术攻坚，工作量的不确定性极高；又或者团队规模在 10 人以内、沟通完全可以直接完成，这些情况下，投入精力做精细排期是错配资源。

此时更合适的做法是固定周期 + 目标导向：每个周期定一个明确的目标（比如“把首屏加载从 3 秒降到 1.5 秒”），不拆细任务，周期结束看结果。这种做法牺牲了可预测性，但换来了探索效率，对早期团队往往更划算。

判断自己属于哪种情况，可以问三个问题：需求变化频率是否超过每迭代 30%？工作量估算的历史偏差是否超过 ±60%？团队规模是否小于 10 人？任意两个回答为“是”，就不该做精细排期。

八、总结：排期制度的价值在于让组织敢于承诺

回头看开头那家 180 人的公司，他们后来做的最重要的改变，不是引入更复杂的排期工具，而是把“我们每个迭代只能稳定交付 12 到 15 个中等需求”这句话，摆到了管理层会议上，并且连续三个季度用数据证明它。当组织知道自己的真实产能，承诺才变得可信；承诺可信，排期才有意义。

我想强调三个不那么主流的判断。第一，排期精确度受限于估算精度，先治估算再治排期，顺序不能反。第二，承诺兑现率长期 100% 是危险信号，健康的排期应该允许 10% 到 20% 的未达成。第三，排期制度做到 L4 就该停，继续加码的边际收益低于投入。

如果你正准备动手，我建议这周先做三件小事，成本都很低：

1. 把过去 6 个迭代的“承诺数”和“交付数”拉出来，算出真实的承诺兑现率。如果这个数字低于 70%，说明问题已经存在。
2. 找 3 个最近延期的需求，各花 15 分钟问清楚“为什么没做完”，先做一次手工归因，看看偏差集中在哪一类。
3. 在一次排期会上，试着让每个进入排期的需求都回答一个问题：“如果它延期，会挤掉谁？”答不上来的需求，先别排。

这三件事不需要任何工具投入，做完之后你会对自己团队的真实状态有一个比任何报表都准确的判断。制度可以慢慢建，但先把真实数据看清楚，是所有排期工作的起点。