需求排期怎么做？企业管理者入门指南：需求排期从0到1

去年我陪一家 320 人的 SaaS 公司做季度复盘，研发负责人把那份改了 11 版的排期表摊在桌上，指着其中一行说：这个需求 1 月 8 日排进来，承诺 3 月底上线，最后 7 月中旬才发版，中间被插了 23 个"紧急需求"。他不是在抱怨执行不力，他是在问一个更根本的问题，我们每周花 4 个小时开排期会，为什么排出来的东西从来没兑现过？

这不是个案。在我接触过的中大型企业里，排期表做得"看起来很专业"的团队不少，但真正能做到"排了就能交付"的比例，远低于管理者的直觉。更麻烦的是，大多数团队把问题归因于"研发不给力"或者"业务方太善变"，于是加了更多审批、更多会议、更多表格，结果排期越来越重，准确率却没怎么动。

这篇文章我想把需求排期这件事从 0 到 1 拆开讲清楚：它到底在解决什么问题，哪些做法看起来对但其实在制造混乱，一套可落地的排期模型长什么样，以及不同规模、不同业务形态的团队应该在哪里做取舍。文中会用到我在实际项目里观察到的数据和案例，涉及具体数字的部分我会说明口径，属于经验推演的会明确标注。

一、先给结论：需求排期不是排序，是"在有限资源上做可兑现的承诺"

1. 排期的本质是承诺管理，不是优先级排序

很多人一提到需求排期，脑子里浮现的动作是"把需求按重要性排个序"。这个理解偏差很大。排序解决的是"先做哪个"，而排期要解决的是"什么时候、由谁、交付到什么程度"，它是一份对外承诺，而不是一份内部心愿清单。

这个区别决定了后面的所有做法。如果排期是排序，那么只要顺序对了就算成功；如果排期是承诺，那么衡量标准就只有一个：承诺的交付时间与实际交付时间的偏差有多大。一家公司可以有一份完美的优先级列表，同时拥有一个烂透了的交付体系，这两件事并不矛盾。

我通常会问管理者一个问题：你们上个季度排进计划的需求，有多少是在承诺时间内交付的？能立刻说出一个数字的团队不到三成。说不出来，本身就说明排期还停留在"排序"阶段。

2. 一个合格的排期必须同时回答三个问题

我把排期的输出拆成三个必须闭合的问题，缺任何一个，这张排期表都是不完整的。

• 做什么：这一期承诺交付哪些需求，边界在哪里，哪些明确不做。没有"不做什么"的排期，等于没有边界。
• 谁来做：不是"研发部"，而是具体到小组甚至个人。跨团队协作的需求，要写明上下游各自负责的环节和交接时间点。
• 什么时候：给的是时间区间而不是某个具体日期，并且要说明这个区间的置信度，是"确定交付"还是"目标交付"。

我在做诊断时有个简单粗暴的判断方法：拿过一张排期表，看它能不能在不问任何人的情况下，让一个新人看懂"这个需求谁在做、做到哪一步、什么时候能看到结果"。看不懂，说明这张表只是记录，不是管理工具。

3. 排期的四个输入，缺一个就会失真

排期不是凭空写出来的，它是四个输入的计算结果。任何一项输入失真，排期都会变成拍脑袋。

1. 需求池：所有需求必须进入唯一入口，并且经过分类和粗颗粒估算。散落在聊天记录、邮件、口头承诺里的需求，是排期失控的第一大来源。
2. 产能：不是团队人数乘以工作日，而是扣掉会议、支持、线上问题、休假之后的真实可用工时。
3. 优先级依据：必须有一套可解释、可复算的规则，而不是"谁嗓门大谁优先"。
4. 历史数据：过去几个周期实际交付了多少、偏差多大。没有历史数据的排期，第一年基本靠猜。

这四项里，最容易被忽略的是第四项。我见过太多团队每年从零开始排期，从不回看上一期偏差在哪里，于是同样的错误一年犯四次。

二、为什么排期会失控：四个我在现场反复见到的场景

1. 场景一：需求入口没有闸门，排期表永远在追赶现实

我服务过一家做企业服务的公司，需求来源有六个渠道：销售、客户成功、老板、产品自研、老板的朋友、以及"某个大客户在饭桌上提的"。这六条渠道里，只有产品自研那条走正式流程，其余五条都能直接找到研发负责人。

结果是排期表永远滞后。因为排期表记录的是"计划内需求"，而真正占用产能的是"计划外需求"。团队每个月实际交付的需求里，计划内的只占六成左右，剩下四成全是从侧门进来的。

排期失控的第一个信号，是计划外需求占比超过 20%。超过这个比例，任何排期方法都会失效，因为你排的不是真实的产能分配。这个数字很好统计：统计一个迭代内所有被交付的需求，看有多少在迭代开始时就已经在计划里。

2. 场景二：排期会开成了资源争夺会

很多公司的排期会，实际形态是这样的：各业务线负责人轮流陈述自己需求的重要性，研发负责人在中间做权衡，最后老板拍板。会议持续三四个小时，产出是一份各方妥协后的清单。

这种会的根本问题不在于效率低，而在于它把资源分配变成了谈判，而不是计算。谈判的结果取决于参会者的职级、表达能力和当天的情绪，不取决于需求本身的投入产出比。更糟的是，它会让"会哭的孩子有奶吃"变成组织学习的对象，第二年所有人都会带着更充分的理由来争资源，而不是带来更好的需求。

3. 场景三：估算靠感觉，承诺靠勇气

我见过最典型的一句话是研发负责人说的："这个需求大概两周吧，我们加把劲。"这句话里有三个隐患：估算单位是"周"而不是"人天"或"故事点"，所以没人知道是两个人两周还是五个人两周；"大概"意味着没有置信度；"加把劲"意味着这个承诺已经建立在透支的前提上。

估算不准几乎是所有团队的常态，但问题不在于不准，而在于不准却没有被记录、被校准。成熟的团队会记录每次估算与实际的比例，三个月后就能得出一个校准系数，比如实际耗时普遍是估算的 1.4 倍，那么下次排期时直接乘 1.4。这个方法很笨，但极其有效。

4. 场景四：没有回头看，所以永远在重犯

排期偏差最大的价值不在当期，而在下一期。但绝大多数团队在迭代结束后直接进入下一个迭代，最多开个半小时的回顾会，讨论一下"这次为什么延期"，然后就没了。

我建议的做法是建立一份排期偏差台账：每次延期都记录延期天数、延期原因分类（需求变更、估算偏差、依赖阻塞、资源被抽调、技术风险）。连续记录三个季度，你就能画出自己团队的偏差原因分布，也就知道该在哪里投入改进。

下面这张图是我在一家 400 人规模企业统计的偏差原因分布，样本是连续四个季度的 217 次延期记录。这个分布很有代表性：真正因为"技术做不出来"导致的延期只占很小一部分，大头全在需求和协调上。

三、六个常见误区，以及它们各自的代价

1. 误区一：把优先级排序当成排期

这是最普遍的误解。团队花大力气建立了一套评分模型，把需求排出了 P0 到 P3，然后认为排期工作完成了。但优先级只解决了相对顺序，没有解决"这一期能做几个"。

我经常看到 P0 需求有 14 个，而团队一个迭代最多做 3 个。这种情况下 P0 这个标签已经失去意义了，它变成了"重要"的同义词，而不是"这一期必须做"的承诺。优先级必须和容量绑定才有意义：P0 的需求总量不能超过当期有效产能的 70%，剩下的 30% 留给 P1 和突发。

2. 误区二：用人天估算，然后把人天相加

用人天估算本身没错，错在"相加"。三个人各自估 5 天，加起来不是 15 天，因为协作有成本、等待有成本、上下文切换有成本。一个需求如果拆给三个人并行做，实际耗时通常比一个人做 15 天要长，除非拆分边界非常清晰。

更靠谱的做法是两级估算：需求级别用相对估算（故事点或 T 恤码），团队级别用历史吞吐量（过去 6 个迭代平均每迭代完成多少点）。排期看吞吐，不看人天总和。这样即使单个需求估算不准，整体排期的准确率也会高很多。

3. 误区三：把产能排到 100%

这是新手管理者最容易犯的错，也是最有欺骗性的错，因为排到 100% 看起来"效率很高"。

现实是，任何一个团队都有无法消除的损耗：会议、答疑、线上问题、招聘面试、跨部门协调。我在多个团队做过工时采样，纯编码/设计时间通常只占名义工时的 55% 到 65%。把产能排到 100%，等于从第一天起就欠了 40% 的债，这些债最终会以延期的形式还回来。

我的建议是计划内需求占有效产能的 70% 到 75%，剩下的留给计划外和缓冲。这个比例看起来"浪费"了四分之一产能，但它换回来的是排期的可信度，而可信度本身是有价值的，它让业务方愿意相信你的承诺，从而减少反复催问和临时插单。

4. 误区四：认为排期一旦确定就不能变

有些团队走向另一个极端：为了维护排期的严肃性，规定排期一旦确定就不许改，任何变更都要走特批。这看起来很规范，实际后果是所有人开始"绕过排期"，需求不报备就做，做完再补记录。

健康的排期不是不变的排期，而是变更有成本、有记录、有交换的排期。"有交换"是关键：新需求插进来，必须明确说出哪个已有需求被挤出去或者延后。没有交换的插入，本质上是从团队的时间预算里偷钱。

5. 误区五：所有需求进同一个池子

把战略级需求、客户定制需求、内部优化需求、技术债修复全塞进一个池子排序，结果一定是短期需求把长期需求挤死。因为客户定制需求有明确的截止日期和明确的提出人，而技术债没有。

正确做法是分池 + 配额：战略/产品需求一个池，客户与支持类需求一个池，技术债与工程效能一个池，每个池子分配固定的产能比例（比如 60/25/15）。池子内部排序，池子之间不排序。这样长期投入不会被短期需求吃掉。

6. 误区六：只排研发，不排上下游

一个需求从提出到上线，要经过需求评审、设计、开发、测试、发布、运营准备等多个环节。如果排期只排开发这一段时间，那它必然不准，因为瓶颈往往在设计或者测试。

我在一家公司看到过极端案例：开发阶段平均 8 天，但从需求评审通过到开发启动平均等了 11 天，因为设计资源排队。排期要排端到端，识别真正的瓶颈环节，否则优化开发效率毫无意义。

四、专业判断逻辑：从 0 到 1 搭一套排期模型

1. 第一步：建唯一需求池，先分类再排序

所有需求必须进入唯一入口，这一步没有商量余地。入口不统一，后面所有分析都是在错误的数据上做。

进入池子后先做三件事：分类、粗估、补全信息。分类决定它进哪个池子，粗估决定它占多少产能，补全信息决定它能不能被评审。没有验收标准的准入需求，一律打回，这一条能过滤掉相当一部分"想法"级别的伪需求。

需求状态我建议至少分六种：待评审、已排期、开发中、待验收、已上线、已搁置。状态流转要有明确的责任人和时限，否则池子会变成一个黑洞。

2. 第二步：算清楚有效产能，而不是名义产能

有效产能的计算是排期最基础也最容易糊弄的一步。我给一个可以直接套用的算法：

有效产能（人天/迭代）= 团队人数 × 迭代工作日
× (1 – 会议与协作损耗率 0.15)

× (1 – 线上问题与支持占比 0.20)

× (1 – 休假与人员流动率 0.08)

× 新成员产能折扣系数（0.6 到 0.9，视占比而定）

示例：8 人团队 × 10 个工作日 = 80 名义人天

80 × 0.85 = 68

68 × 0.80 = 54.4

4 × 0.92 = 50.0
若其中 2 人为入职 3 个月内新人：50.0 – 2×10×0.35 ≈ 43 人天

结论：8 人团队在 10 个工作日的真实产能约 43 人天，而非 80 人天。

这个计算看起来很"保守"，但它接近真实。我建议每个团队用自己的数据校准这四个系数，校准方法很简单：连续记录三个迭代的实际投入分布，算出各项占比。

3. 第三步：用可解释的评分模型定优先级

我不推荐照搬现成的优先级框架，因为它们大多假设你能准确量化业务价值，而现实中做不到。更实用的做法是一个五项加权评分，每项 1 到 5 分，权重由管理层定，然后公示。

优先级得分 = 业务价值 × 0.30
+ 用户覆盖 × 0.20

+ 战略契合 × 0.20

+ 紧迫性 × 0.15

研发成本 × 0.10

技术风险 × 0.05

评分口径（每项 1-5 分）：

业务价值：直接收入影响 / 成本节约 / 合规要求

用户覆盖：受影响客户数或用户数，取对数后分档

战略契合：是否属于年度三大方向之一

紧迫性：是否有外部截止日期（合同、监管、市场窗口）

研发成本：反向计分，成本越高分越低

技术风险：反向计分，不确定性越高分越低

这套模型的价值不在于算得多准，而在于它把争论从"我觉得重要"变成"我这个维度打几分，你为什么打低分"。评分可以吵，但吵的是具体维度，而不是立场。另外，权重必须公开，公开的权重本身就是一种管理信号。

4. 第四步：三层节奏，分别锁定不同颗粒度

排期不能只有一层。只有季度排期，颗粒度太粗，指导不了日常；只有双周排期，颗粒度太细，看不到方向。我建议三层节奏并行，每层锁定不同的东西。

三层之间的关系是：越往下越刚性，越往上越柔性。执行层必须刚性，否则团队无法专注；战略层必须柔性，否则组织无法转向。很多公司的毛病正好相反，战略层定死了却不许改，执行层天天被插单。

5. 第五步：给区间而不是给点，给置信度而不是给日期

承诺"3 月 15 日上线"和承诺"3 月中下旬上线，置信度 80%"，哪个更专业？后者。因为在不确定性面前，精确的日期是一种虚假的专业感。

我的做法是把承诺分成三档：确定交付（有 90% 以上把握，已经预留缓冲）、目标交付（70% 到 80% 把握，依赖外部条件）、规划交付（50% 左右，还在探索阶段）。对外沟通时明确说明是哪一档，比统一说"预计"要诚实得多，也更容易管理预期。

6. 第六步：把变更做成流程，而不是事故

变更管理的关键是设计一个"交换机制"。我给客户设计的规则通常是这样的：

1. 任何插入需求必须指定一个被挤出的需求，或者明确接受整体延期。
2. 插入需求的申请人要签字确认交换内容，不能只提交不担责。
3. 每个季度统计一次插单次数和被挤出的需求清单，作为下一季度规划的输入。
4. 紧急通道（真正的事故、合规、大客户阻断）单独设立，配额不超过有效产能的 10%。

这套规则上线后，插单量通常会下降一半以上。不是因为流程变严了，而是因为申请人第一次意识到插单是有代价的，以前代价由研发承担，现在代价由提出方承担。

五、一个 400 人企业的排期改造实录

1. 改造前的基线：一个季度交付了计划的三分之二

这家公司做企业级软件，研发 180 人，分 9 个研发小组，同时服务 3 条产品线。改造前的基本情况是：需求池分散在三个系统加若干表格里，季度排期由各产品线分别做，研发负责人事后汇总；没有统一的优先级规则；季度末的交付率大约在 65% 左右。

更麻烦的是，没人能说清楚这 35% 的缺口是怎么产生的。产品说是研发不给力，研发说是需求老变，老板说是协同不行。三方都有道理，但三方都拿不出数据。

2. 我们做的五件事

整个改造没有引入任何新概念，就是把上面那套逻辑落到位。

• 统一入口：三个系统加散落表格全部收拢到一个需求池，入口从 7 个减到 1 个。这一步花了三周，主要工作在历史数据清洗。
• 分池配额：战略产品需求 60%、客户与支持 25%、技术债与效能 15%，三个池子独立排序，配额按季度调整一次。
• 产能校准：用前面那套公式算出各小组的有效产能，并连续两个迭代用实际数据反向校准系数。校准后发现，之前排期用的产能普遍高估了 45%。
• 三层节奏：季度定清单、月度做对齐、双周跑迭代。季度清单允许 15% 的调整额度，双周迭代内原则上不插入。
• 偏差台账：所有延期必须记录原因分类，季度末做一次分布分析。

3. 工具承担了什么：以 PingCode 为例

这套流程如果没有工具承接，会在两个月内退回原形。因为统一入口意味着所有需求要在同一个地方流转，分池配额意味着要能按池子统计产能消耗，偏差台账意味着延期原因要能被结构化记录和聚合。

这家公司最后选的是 PingCode，我参与了部分方案评估。选它的原因不是功能最多的，而是它把需求、迭代、工时、测试、发布放在了一条链路上，这正好对应前面说的"端到端排期"，你可以在同一个需求上看到它从提出到上线的完整时间分布，从而识别瓶颈在评审、开发还是测试。

具体来说，工具在四个环节起了作用。

（1）需求池与分池视图。所有需求进入统一池子后，按池子打标签，用不同的视图分别管理。规划时可以直接看到每个池子当前积压了多少、本期分配了多少产能，配额是否超支一目了然。以前这件事靠人工汇总表格，一个产品经理每周要花 3 小时，现在是实时视图。

（2）迭代容量与工时。每个迭代开始前，团队成员的可用工时会被明确设定（扣除休假、会议、支持），排期时系统会提示超出容量的部分。这个提示看起来简单，但它把"产能超配"从一个隐性事实变成了一个显性警告，排期会上没人能装作看不见。

（3）依赖关系可视化。跨团队需求可以标注依赖，被依赖方延期时上游会收到提示。前面统计里跨团队依赖阻塞占了 21.7% 的延期原因，这个功能直接针对的就是它。

（4）报表与偏差分析。延期原因作为必填字段沉淀下来，季度末可以直接出分布图。这家公司在第二次季度复盘时，第一次拿出了完整的偏差原因分布，而不是凭印象讨论。

需要说清楚的是，工具解决的是"信息可见"和"规则可执行"，解决不了"该不该做这个需求"和"优先级怎么定"。这两件事仍然要管理层自己判断。把管理问题交给工具，是另一种形式的偷懒。

4. 六个月后的数据变化

改造从第二季度启动，下面是改造前基线（Q1）与改造后（Q4）的对比。数据来自这家公司的内部统计，口径为季度内所有进入排期的需求。

5. 三个值得说清楚的细节

（1）前两个月指标是变差的。统一入口后，需求池里的需求数量暴增了三倍，因为以前藏着掖着的需求全冒出来了。管理层一度想放弃，以为是流程拖慢了效率。实际情况是"以前看不见的问题现在看见了"，第三个月开始回落。任何排期改造，前 60 天的数据都不能用来判断成败。

（2）真正的难点是产能校准，不是工具。系数校准花了整整两个迭代，因为没人愿意承认自己的团队只有 55% 的有效产能。这件事最后是靠数据说服的：连续四周的工时明细摆出来，争论就结束了。

（3）承诺兑现率提升到 88% 之后，业务方的满意度改善幅度远超预期。这一点很反直觉，需求交付的总量并没有显著增加，但因为承诺可信了，业务方的规划可以建立在确定的预期上，催问和临时插单大幅减少，形成了正向循环。

六、不同情况下的行动建议

1. 10 到 50 人团队：先解决"看得见"，不要上复杂模型

这个阶段的团队最大的问题是需求在脑子里和聊天记录里。我的建议非常简单：先建一个统一的需求列表，字段只要六个，需求描述、提出人、优先级、预估工作量、状态、承诺时间。用最轻的工具就行，一张共享表格都可以。

关键是每周固定花 30 分钟过一遍这个列表，把状态更新掉。这个阶段追求的是"信息不丢"，不是"排期准确"。上复杂的评分模型、三层节奏，只会增加负担而没有收益。

2. 50 到 200 人团队：先解决"排得准"，重点在产能校准

这个规模的团队通常已经有了基本流程，痛点是排期不准。核心动作是两个：一是把有效产能算清楚，二是建立估算校准机制。

具体做法：连续三个迭代记录实际投入，算出有效产能系数；同时记录每次估算与实际的比例，得出团队级的校准系数。这两个数字出来之后，排期准确率通常能提升 20 个百分点以上，而且不需要任何流程变革。

3. 200 到 1000 人团队：先解决"对得齐"，重点在分池和三层节奏

这个规模最大的问题是跨团队协同。9 个小组各自排期，加起来的计划一定超过公司总产能，而且依赖关系没人管。

关键动作是建立公司级的统一规划节奏：季度一次全公司对齐，输出一份跨团队的需求清单和依赖清单；月度做一次进度校准；各小组在此基础上做双周迭代。同时必须上工具，靠表格已经管不住这个复杂度了。

4. 1000 人以上团队：先解决"算得清"，重点在口径统一

超过千人之后，最大的挑战不是排期方法，而是数据口径。三个事业部用三套定义算"交付率"，汇报时根本无法比较。

这个阶段第一件该做的事是定义公司级指标字典：什么叫"交付"、什么叫"按期"、需求从哪一天开始计时。口径统一之后，才谈得上跨部门比较和资源调配。

5. 项目交付型公司和产品型公司，排期逻辑完全不同

这一点经常被忽略。产品型公司的排期是"从池子里挑"，核心是优先级；项目交付型公司的排期是"按合同履约"，核心是资源和deadline倒排。

项目型公司如果照搬产品型的优先级模型，会发现自己永远在救火，因为合同日期不能谈判。项目型公司的排期重点应该放在资源冲突检测和关键路径管理上，而不是需求优先级排序。反过来，产品型公司如果按项目制排期，会被一个个"里程碑"切碎，失去产品节奏。

七、必须提前想清楚的五组取舍

1. 交付确定性 vs 响应速度

这两者本质上是矛盾的。要提高确定性，就要冻结需求、预留缓冲、减少插单；要提高响应速度，就要保持弹性、随时可插、快速试错。没有哪个更好，取决于你的业务形态。

To B 的合同型业务，确定性优先，因为延期直接影响回款和客户信任；To C 的流量型业务，响应速度优先，因为市场窗口很短，慢一步就没有机会。最糟糕的是两种都要，既要求零延期，又要求随时插单，最后团队只能靠加班和隐瞒来维持表面平衡。

2. 排期透明 vs 组织灵活

排期透明意味着所有人都能看到计划、进度和偏差。好处是信任成本低、协调效率高；代价是团队暴露在聚光灯下，一旦有偏差就会被追问，容易催生"防御性汇报"，把估算故意放宽，把进度报得比实际慢。

我的建议是透明到团队级别，不透明到个人级别。公开每个小组的产能利用和交付情况，但不在公司层面公开某个人的任务明细。前者解决协调问题，后者避免微观管理。

3. 工具约束 vs 流程自觉

好的工具能把流程变成默认路径，比如需求不填验收标准就无法进入评审，产能超配就会红字提示。这比开会强调一百遍都有效。

但工具也有代价：它会固化流程，当业务变化时调整成本很高。判断标准是：这条规则是否稳定超过一年。稳定的规则交给工具强制，不稳定的规则交给流程约定。把还在探索中的流程硬编码进系统，半年后就会变成所有人都想绕开的障碍。

4. 集中排期 vs 分散排期

集中排期的好处是资源可以全局最优调配，坏处是决策链长、响应慢，而且中央排期的人往往不了解一线细节。分散排期的好处是贴近业务、反应快，坏处是各组容易重复投入、资源无法共享。

我的经验是分层：产能分配集中，需求排序分散。公司层面决定每个业务线分多少产能（这需要全局视角），业务线内部决定这些产能用来做什么（这需要一线判断）。这样既保证了资源不浪费，又保证了决策贴近实际。

5. 精细度 vs 维护成本

排期精度每提高一档，维护成本大约翻一倍。精确到周，需要每周更新；精确到天，需要每天更新；精确到小时，基本上只有咨询公司做演示时才会用。

我见过最离谱的案例是一个 60 人团队，排期精确到半天，结果产品经理每周要花 8 小时维护排期表，而实际偏差仍然有 5 天以上。排期精度应该匹配你的不确定性水平：不确定性 5 天，排期精度做到 1 天就够了，再细就是自欺欺人。

八、下一步：一份 90 天落地清单

1. 第 1 到 30 天：把现状摸清楚，别急着改

第一个月不要动流程，只做三件事：收拢需求入口、统计当前基线、记录一次完整的偏差。

1. 把所有需求来源列出来，数一数有几个渠道，每个渠道每周进来多少需求。
2. 统计过去一个季度的三个数字：计划内需求占比、承诺兑现率、平均延期天数。
3. 建立偏差台账，从下一个延期开始记录，原因分类不少于五类。
4. 选一个试点小组，不要全公司铺开。

这一个月最重要的产出是让管理者第一次看到真实的基线。很多人对"我们排期挺准的"的印象，会在看到 60% 兑现率的那一刻被打破，而这个冲击本身就是变革的起点。

2. 第 31 到 60 天：试点小组跑通最小闭环

在试点小组做四件事：算有效产能、建分池、定优先级评分规则、跑两个完整迭代。这个阶段的目标不是指标改善，而是验证流程能不能跑通、数据能不能采集到。

重点是产能校准。第一版系数一定是错的，用两个迭代的实际数据修正一次，你会得到接近真实的数字。这时候通常会有一个"原来我们只有一半产能"的惊讶时刻，这是好事。

3. 第 61 到 90 天：固化规则，逐步推广

第三个阶段做三件事：把跑通的规则写成文档、把能固化的部分放进工具、向第二批团队推广。

推广节奏建议每次增加 2 到 3 个团队，不要一次性全铺。因为每个团队的情况不同，产能系数、池子配额都要重新校准，一次性铺开会导致大量细节没人管。

4. 判断是否成功的四个指标

90 天结束时，用这四个数字判断改造是否有效，不要看感觉。

• 计划外需求占比：从 40% 以上降到 20% 以内。
• 产能测算误差：控制在 15% 以内。
• 偏差记录覆盖率：达到 85% 以上。
• 承诺兑现率：相比基线提升 10 个百分点以上。

四个指标里，前三个是过程指标，必须在 90 天内达成；第四个是结果指标，允许滞后一个季度。如果过程指标达成了但结果指标没动，通常是产能校准还不够准；如果过程指标都没达成，说明流程本身没跑起来。

九、写在最后：三个我越来越确信的判断

做了这么多年的排期改造，有些判断从最初的假设变成了现在的确信，这里说三个。

第一，排期问题的根源几乎从不在研发端。在我统计的所有延期原因里，真正因为技术做不出来导致的延期很少超过 10%。绝大多数问题出在需求没冻结、依赖没识别、产能没算清。这意味着排期改进的主导者应该是产品和业务侧，而不是研发管理者，但现实中往往是研发在背这个锅。

第二，排期的价值不在准确，而在可预期。一个团队做到 80% 的兑现率并且稳定，比做到 90% 但波动剧烈要有价值得多。因为业务方要的不是每次都准时，而是能提前知道什么时候不准时，从而做出替代安排。可预期性是一种可以设计的组织能力。

第三，任何排期方法都需要自己的数据来校准。这篇文章里给的所有系数，15% 的会议损耗、20% 的支持占比、70% 到 75% 的计划占比，都是起点而不是答案。照抄别人的参数，等于用别人的身体穿自己的鞋。真正有效的做法是先用一个粗略的起点跑起来，用三个迭代的数据把自己的系数校准出来，然后每半年再校准一次。

如果你正准备动手，我的建议是从最小的一步开始：这周就把所有需求来源列出来，数一数到底有几个入口。这个动作不需要任何工具、不需要任何授权、不需要开会讨论，一个人半小时就能做完。但它会给你一个非常直观的冲击，大多数管理者第一次数完才发现，自己以为的 2 个入口，实际上有 7 个。

数完之后，再回来考虑产能、优先级和节奏的事。顺序搞反了，做多少都是白做。