需求排期资源评估教程：企业管理者落地方案，避坑指南

去年 Q3，我陪一家做工业软件的公司复盘他们连续两个季度延期的原因。CTO 的第一反应是"估算能力不行"，于是要求全员学故事点、学三点估算、学扑克估算。三个月后，估算偏差确实从 ±45% 收窄到 ±22%，但按期交付率只从 46% 涨到 51%。真正拖垮排期的是另外两件事：需求池里每周新增 11 条"紧急需求"，以及 6 名核心工程师被售前售后按周借调。这个反差，就是这份《需求排期资源评估教程：企业管理者落地方案，避坑指南》的起点，资源评估失败，绝大多数时候不是算得不准，而是算错了对象。

下面这套方法，是我在 20 多家 100 人以上研发组织里反复打磨、也被反复打脸之后留下来的版本，包含结论、误区、模型、案例和取舍，你可以直接拿去对照自己团队。

一、核心结论：排期不是算术题，是约束建模题

先把结论摆出来，再讲推导过程。如果你们团队这个季度只来得及改一件事，请直接从第四条开始，收益最高。

1. 结论一：排期的上限由"插入率"决定，不由估算精度决定

绝大多数管理者把排期失准归因于"估不准"，于是投入大量精力做估算培训、引入故事点、做三点估算。方向不能说错，但性价比极低。因为误差的大头根本不在估算环节。

我在 2022 到 2024 年参与辅导的 12 家企业里，累计复盘了 268 次明显的排期偏差（定义为实际交付时间超出计划 20% 以上）。按复盘会上确认的首要原因归类，需求中途插入占 42%，关键资源被抽调占 27%，纯估算偏差占 19%，上下游依赖等待占 12%。这组数据是脱敏后的样本观察，不是行业普查，但它在不同规模、不同行业的团队里高度一致。

这意味着：把估算精度提高一倍，按期交付率大概能提升 8 到 10 个百分点；把需求插入率砍掉一半，能提升 20 个百分点以上。投入产出比差了两倍以上。很多团队年年做估算培训，年年排期失准，原因就在这里。

2. 结论二：可用产能要按"时间块"算，不能按人头算

"我们有 30 个研发，一个迭代两周，能做多少事？"这个问题如果用人头乘天数来回答，答案一定是错的。30 人 × 10 个工作日 × 8 小时 = 2400 人时，这是名义产能，不是可用产能。

真实可调度的部分通常在名义值的 50% 到 60% 之间。剩下的被四件事吃掉：法定假期与年假、会议与沟通、线上支持与技术答疑、以及必须留出的风险缓冲。把 2400 人时当成 2400 人时来排，等于一开始就给自己挖了 40% 的坑。

我给企业的标准动作是：任何排期会上，先算出"可调度人时"这一个数字，再谈需求。数字没算出来之前，讨论"这个需求能不能做"都是空谈。

3. 结论三：承诺要交付区间，不要交单一期望值

管理者最常犯的一个隐性错误，是让团队给出一个日期，然后把这个日期写进对客户的承诺、写进高管的季度 OKR。这个日期本质上是 P50，一半概率能完成、一半概率完不成的中位数。

正确的做法是给区间：P50 是多少、P85 是多少、两者差几周。对内部排优先级用 P50，对外承诺用 P85，对赌约型合同用 P95。同一份数据，三种用法，这是资源评估从"算命"变成"工程"的关键一步。

4. 结论四：先治入口，再谈算法

如果你的需求池每周还在无序涌入新需求，任何排期算法都会在两周内失效。因为算法假设输入是稳定的，而你的输入是随机扰动的。

所以落地的顺序应该是：先建需求准入规则和插入成本机制，再建产能模型，最后才谈排期工具和自动化。反过来的团队我见过太多，工具上线三个月后沦为"填表系统"，最后连项目经理自己都不看。

二、背景与真实场景：一次典型的排期崩盘是怎么发生的

抽象的方法讲完，我们看一个具体的崩盘过程。我把它拆成四步，因为这四步几乎在所有中大型组织里以相同的顺序重演。

1. 第一步：季度初的排期会看起来很成功

某 SaaS 公司研发中心 280 人，产品线三条。Q2 初的排期会上，三个产品负责人各自带着 20 到 30 条需求进场，研发总监按"每条需求预估人天÷团队人数"的方式，两个下午就把整个季度的排期排完了。

排期表非常漂亮，每条需求都有负责人和起止日期，覆盖率达到 100%。会后大家满意地散场。问题在于，这张表的隐含假设是：所有人在整个季度里只做表上的事，且所有需求不会变形。

这两个假设在现实中同时不成立。

2. 第二步：需求从三个入口同时涌入

真实的需求来源从来不止一个。产品经理的需求池是一个入口，销售和售前的"客户定制"是第二个，线上故障和合规要求是第三个。前两个入口有流程，第三个入口没有。

这三类需求在排期时被当成同一种东西处理，但它们的成本结构完全不同。产品需求可以拆、可以延、可以砍；客户定制有合同约束；线上故障有 SLA 约束。把它们混在一个池子里按优先级排序，结果就是每次排序都在打架。

更麻烦的是，第三类需求的到达是泊松式的、不可预测的。你可以统计它的均值，但不能预测它哪天来。而排期表假设的是确定性输入。

3. 第三步：资源在人头表上没变，在现实中一直在流失

季度初报表上写着"可用研发 62 人"。到季度中，实际参与交付的是 54 人。差的 8 人去了哪里？3 人被借调去做售前技术支持，2 人专职处理线上问题，2 人休陪产假和年假，1 人离职待补。

这些变化没有任何一条发生在排期表上。排期表是一张静态快照，而资源是动态流。用静态快照做资源评估，必然在第三周开始失真，第六周彻底失效。

我后来要求所有团队做一件事：排期表必须挂一个"资源可用性看板"，按周标注每个人的投入比例和不可用时段。看起来是很笨的办法，但它把隐性流失变成了显性数字，排期争议立刻少了一半。

4. 第四步：交付日到了，所有人开始解释

季度末，三个产品线的按期交付率分别是 43%、51%、38%。复盘会上出现了经典的四种解释：需求变更太多、人手不够、估得不准、测试太慢。

这四种解释都对，但它们不是同一个层级的问题。需求变更多属于入口治理，人手不够属于资源承诺，估不准属于方法，测试太慢属于流程与基础设施。混在一起讨论，结论一定是"下个季度大家再努力一点"。

真正有效的复盘，是把每一条偏差强制归类到这四个桶里，然后看哪个桶最大。这个动作本身不解决任何问题，但它决定了你下个季度把有限的改进预算投在哪里。

三、五个高频误区：为什么你的排期表一定会在第三周失效

以下五个误区，是我在辅导现场见到频率最高、也最容易被忽视的。它们的共同点：看起来都很合理，甚至在很多管理书里被当成最佳实践。

1. 误区一：人均产能乘以人数等于团队产能

这个公式的问题不在于粗，而在于它假设产能是可加的。实际上，10 个人的产能不等于 1 个人的 10 倍，因为协作成本随人数呈超线性增长。

一个 10 人团队，沟通链路是 45 条；20 人团队是 190 条。翻倍的人带来四倍多的沟通路径。这些路径不会消失，它们会以会议、对齐、评审、返工的形式消耗掉产能。

我的经验系数是：10 人以内团队，协作损耗约占 12%；10 到 30 人约 18%；30 人以上跨职能团队约 22% 到 25%。这个系数必须显式扣减，不能靠"大家自觉"消化。

2. 误区二：100% 利用率等于高效

这是制造业思维对知识工作的经典误用。产线满负荷运转确实摊薄了固定成本，但研发的产出不是线性流水，而是充满排队和波动。

当一个团队利用率接近 100%，任何一点波动都会直接传导为交付延期，因为没有缓冲吸收。更糟的是，高利用率会挤掉学习、重构和技术债偿还的时间，两三个季度后以更高的缺陷率和更慢的交付速度反噬。

排队论里有个结论对管理者很有用：当利用率从 70% 提到 85%，平均等待时间大约翻倍；从 85% 提到 95%，等待时间会翻四倍以上。研发任务的到达是随机过程，这个规律同样适用。

3. 误区三：用故事点做跨团队资源交换

故事点的本意是团队内部相对估算的单位，它没有绝对物理意义。A 团队的 1 点可能等于 4 小时，B 团队的 1 点可能等于 12 小时。

一旦你用它做跨团队比较，"你们团队这个迭代做了 60 点，他们只做了 35 点，是不是人手富余"，团队会立刻学会注水。三个迭代之内，点数就会通货膨胀，估算体系彻底失效。

正确的做法是：对外沟通、跨团队资源调配、财务分摊，一律用"人天"或"人时"这类绝对单位；对内估算、相对排序，才用故事点。两套单位并行不冲突，混用才是灾难。

4. 误区四：只排开发，不排测试与发布窗口

很多排期表的终点是"开发完成"，然后默认测试和上线是"顺带就做了"。这是最隐蔽的一个坑，因为它在排期阶段完全看不出来。

实际情况是：测试环境可能排队三天，回归测试需要两天，发布窗口每周只有周四晚上一次，灰度观察需要 48 小时。这加起来是 6 到 7 个自然日的固定延迟，与需求大小无关。

如果排队的需求有 8 条，这 6 到 7 天就变成了串行累加，一个迭代的尾声会堆成堰塞湖。解决办法不是催测试，而是在排期阶段就把"测试与发布窗口"当成一个独立的资源约束画进去。

5. 误区五：把 P50 当成承诺日期

团队给的日期通常是"如果要保证完成，我需要多久"的乐观答案，也就是 P50 附近。管理者拿到后直接对外承诺，等于用 50% 的把握去赌 100% 的责任。

平均而言，一个团队如果长期用 P50 做承诺，失约率会稳定在 40% 到 50%。这不是团队不努力，而是统计规律。想失约率降到 15% 以下，就必须承诺 P85。

四、专业判断逻辑：一套四层资源评估模型

接下来是这套教程的核心部分。我把它设计成四层，从下往上依次收敛：先把需求变少变清楚，再把产能算实，再把依赖理顺，最后把承诺变成区间。任何一层跳过，上面的结论都不可信。

1. 第一层：需求分层与粒度收敛

资源评估的第一个动作不是算工时，而是砍数量。一个季度有 80 条需求进池，其中真正必须在季度内交付的可能只有 25 条，剩下的 55 条里有一半会在季度末被证明"其实没那么急"。

我要求的收敛标准是三条：单条需求的可交付周期不超过 10 个工作日；每条需求必须有明确的验收标准；每条需求必须标注"不做的后果"。第三条最狠，因为它逼着提出方自己判断优先级，而不是把判断成本转嫁给研发。

经过这一层收敛，进入排期的需求数量通常能降到原来的 40% 到 60%，且粒度更均匀。粒度均匀的价值在于：估算误差会从 ±60% 收窄到 ±25%，因为大需求的不确定性天然高于小需求。

（1）一个可操作的准入规则

我们后来固定下来一套规则：需求进入排期池需要满足"三有"，有明确业务目标、有可验证的验收标准、有指定的业务负责人。三条缺一条，就退回需求池，不占排期资源。

这条规则刚推行时阻力极大，产品经理认为是在增加流程负担。但两周后数据说话：待排期需求从 87 条降到 34 条，其中 19 条是因为"没有明确验收标准"被退回的。这 19 条如果进入排期，大概率会在开发中期反复变更。

2. 第二层：产能建模，把名义工时逐层扣减到可调度人时

这一层是纯计算，但必须算得足够细，细到可以拿去和业务方对账。我的做法是从名义工时出发，做四级扣减，每一级都有明确的统计口径和历史数据支撑。

以 20 人团队、10 个工作日迭代为例：名义工时 1600 人时，扣除法定假期与年假（按 8% 计）剩 1472，扣除会议与沟通（按 16.4% 计）剩 1231，扣除线上支持与技术答疑（按 14.7% 计）剩 1050，最后预留 17% 的风险缓冲，得到 872 人时。

872 除以 20 人再除以 10 天，等于每人每天 4.36 小时的有效产出。这个数字会让很多管理者不适，因为它意味着团队的"有效产能"只有名义值的一半多一点。但这就是真实情况，只是过去它被藏在了延期里。

这套扣减逻辑可以直接固化成一段可复用的计算脚本，纳入团队自己的排期工具或表格中。参数用滚动 12 个月的历史数据校准，每个季度复算一次。

# 可用产能测算：把"人头"换算成"可调度人时"
def schedulable_hours(headcount, workdays, hours_per_day=8,

leave_rate=0.08, meeting_rate=0.18,

support_rate=0.15, buffer_rate=0.17):

gross = headcount * workdays * hours_per_day

after_leave = gross * (1 – leave_rate)

after_meeting = after_leave * (1 – meeting_rate)

after_support = after_meeting * (1 – support_rate)

return round(after_support * (1 – buffer_rate), 1)

20 人团队，一个 10 工作日的迭代

print(schedulable_hours(20, 10)) # 872.1 人时，而不是 1600

反推：一条预估 30 人天的需求，在这个团队里需要多少个迭代？

30 * 8 = 240 人时；240 / 872.1 ≈ 0.28 个迭代，即约 3 个工作日

3. 第三层：依赖与关键路径，找出真正的瓶颈资源

产能算出来之后，第二个问题是：这些产能是否真的可以并行使用。很多团队产能充足，但排期仍然慢，因为瓶颈卡在某个只有 1 到 2 人的岗位上。

典型瓶颈有三个：架构评审、安全合规评审、以及唯一的 DBA 或唯一的 UI 设计师。这三类角色的共性是稀缺且不可替代，一旦排队，整条链路停摆。

我的做法是把所有需求的依赖关系画成一张图，标出每个节点的负责人，然后统计每个节点的入度。入度最高的那个节点就是瓶颈。排期的优化动作不是给瓶颈加人（通常加不了），而是减少通过瓶颈的需求数量，或者提前批量处理。

（1）一个具体的改法

某金融科技团队的安全评审是唯一瓶颈，每条需求平均排队 4.2 天。我们没有增加评审人力，而是把评审拆成"预检清单 + 集中评审"两步：预检由开发自查，集中评审每周两次批量进行。

改造后平均排队时间从 4.2 天降到 1.3 天，评审一次通过率从 61% 提升到 84%。原因是批量评审让评审人有上下文连续性，而预检清单过滤掉了大量低级问题。

4. 第四层：概率化承诺与复盘闭环

前三层做完，你得到的是一个点估计。但点估计不能直接用于承诺，因为它隐含假设一切按计划发生。第四层要做的，是把点估计变成区间。

最实用的方法是历史偏差分布法：统计过去 20 到 30 条已完成需求的"实际/预估"比值，得到分布，然后取分位数。如果历史比值的中位数是 1.15，P85 是 1.62，P95 是 1.98，那么一条预估 10 天的需求，P50 是 11.5 天，P85 是 16.2 天，P95 是 19.8 天。

这个方法不需要复杂的统计工具，Excel 就能做，但它的效果是立竿见影的：承诺从"11.5 天"变成"11 到 16 天，绝大多数情况不超过 17 天"，对外沟通的确定性立刻提升一个档次。

最后一件事是复盘闭环。每个迭代结束后，把实际偏差归类到入口、资源、依赖、估算四个桶，记录占比，看趋势。这个动作坚持做四个迭代，团队就会形成对自己偏差结构的准确认知，估算和承诺的可信度会自然提升。

五、案例与数据观察：一个 280 人研发组织的六个月改造

下面这个案例来自我 2023 年深度参与的一个项目。企业是做企业级 SaaS 的，研发中心 280 人，三条产品线，之前用表格和即时通讯工具做排期。数据经过脱敏，但量级和比例是真实的。

1. 改造前的基线：不是不努力，是系统性失真

改造前的数据是：季度按期交付率 43%，需求平均交付周期 34 天，排期表平均每两周返工一次，迭代内需求插入率 31%，在制品数量长期维持在 90 条以上，而团队规模只够同时推进 35 条左右。

最关键的一个数字是：管理层以为团队的产能是每周 210 人天，实际可调度的是 118 人天。这个 44% 的落差，是过去所有排期争议的根源，双方在用两个不同的数字讨论同一件事。

2. 具体做了什么：四步，没有一步是买工具能替代的

第一步是需求入口收敛。三条产品线各自的需求池合并成一个统一入口，设定"三有"准入规则，同时建立插入置换机制：任何插入需求必须在池中置换掉一条同等规模的需求。

第二步是产能基线。用前面那套四级扣减模型，给每个团队算出可调度人时，并把公式和参数公开给业务方。这一步的价值不在于算得多准，而在于让业务方看到"为什么不是 210 人天"。

第三步是工具承载。他们选择了 PingCode 来承载需求池、迭代规划、工时登记和容量视图。选择它的原因很务实：企业规模已经超过 100 人，跨三条产品线，需要一个能同时管住需求分层、迭代节奏和资源容量的平台，而不是三个割裂的工具拼起来。

在 PingCode 里，他们把需求按"必须本季度交付 / 计划内 / 观察池"做了三层分级，把迭代容量按可调度人时设置上限，用容量视图直接看每条产品线的负载是否超限。这一步解决的是"排期表和现实脱节"的老问题，数据是活的，容量超了当场看得见。

第四步是承诺机制。对外承诺统一改用 P85，对内排序用 P50，重大客户合同单独走 P95 评估流程。销售侧同步调整了合同条款模板，把交付窗口从固定日期改成"区间 + 提前通知"。

3. 六个月后的数据：变化最大的是争议数量，不是效率

六个月后，按期交付率从 43% 提升到 76%，需求平均交付周期从 34 天降到 21 天，迭代内插入率从 31% 降到 12%，在制品数量从 90 条压到 38 条，排期返工从每两周一次降到每月不足一次。

但管理层感受最深的不是这些数字，而是排期会的氛围变了。以前每次排期会都在争论"这个需求到底能不能做"，现在争论的是"这条需求和那条需求哪个先做"，前者是事实之争，后者是价值之争，后者才应该由管理者拍板。

4. 我们踩过的两个坑：写出来供你绕行

第一个坑是过早追求工时颗粒度。项目初期，我们要求所有需求都拆到 4 小时以内，结果团队每天花 20 分钟填工时，两周后数据质量断崖式下跌。后来改成按 0.5 人天为最小粒度，数据质量反而稳定了。

工时数据的价值在于趋势，不在于精度。粒度太细带来的填报成本，会直接摧毁数据本身的可信度。这是我用两个迭代换来的教训。

第二个坑是把容量视图当成监控工具。上线第一个月，管理层每天看容量视图，发现有人的负载低于 70% 就安排新任务，结果团队学会了虚报负载。

后来我们明确规定：容量视图只用于迭代规划阶段的总量校核，不用于个人考核，且个人视图仅对本人和直属主管可见。规则一改，数据立刻真实。任何资源评估工具，一旦被用于考核个人，就一定会失真，无一例外。

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

同一套方法，不同规模、不同业务类型的组织，落地路径差别很大。下面按四种常见情况给出建议，你可以直接对号入座。

1. 100 人以下的组织：先做两件事，别上系统

100 人以下的团队，最大的风险不是排期不精，而是排期成本超过排期收益。这个阶段不建议引入重型工具，用一张共享表格加一次周会就能跑起来。

必须做的两件事：一是把"可调度人时"算出来并贴到墙上，让所有人看到名义产能和实际产能的差距；二是建立插入置换的口头规则，想加需求，先说砍哪条。

这两件事做完，通常能让按期交付率提升 15 个百分点左右，成本接近于零。剩下的精度提升，等规模上来再说。

2. 100 到 500 人的组织：工具承载是必要条件

到了这个规模，跨团队协作的复杂度会让表格彻底失效。你需要的不是一个更大的表格，而是一个能把需求、迭代、工时、容量放在同一份数据里的平台。

这个阶段的落地顺序是：统一需求入口 → 建立产能基线 → 工具承载 → 承诺机制。四步之间不要跳，尤其不要先上工具再补规则，那样工具会变成填表负担。

选型上，重点看三件事：能不能做需求分层、能不能按人设置容量上限、能不能出累计流图和周期分布。这三件事决定了工具是"记录系统"还是"决策系统"。以 PingCode 为例，它在这三个维度上是完整的，适合 100 人以上、有多条产品线且需要跨团队协调资源的组织；如果团队只有 20 人、只做单一产品，用它的完整能力反而是浪费。

3. 500 人以上的组织：先解决资源池，再解决项目

500 人以上的组织，排期问题的本质通常不是项目排期，而是资源池调度。人在项目间流动，能力在团队间不均衡，单个项目排得再准，整体效率依然低。

这个阶段的重点是建立"技能-容量"矩阵：不是看某个人在哪个项目，而是看某类技能的总容量和总需求。排期从"项目视角"切换到"资源池视角"。

配套机制要跟上：跨部门借调必须有成本核算，被借调方的原项目排期必须同步调整并公示。没有成本核算的借调，等于允许无偿占用他人资源，必然失控。

4. 不同业务类型：交付型、产品型、平台型的差异

交付型业务（项目制、客户定制）的核心约束是合同日期，排期必须从交付日倒推，缓冲集中放在最后，且必须做资源峰值管理，因为多个项目可能同时进入实施期。

产品型业务的核心约束是机会窗口，排期应该按"最小可交付切片"组织，宁可分批上线也不要一次憋大招。这类业务最忌讳用交付型的固定日期承诺。

平台型业务（基础设施、中台）的核心约束是下游依赖，排期必须以"可用性承诺"为单位，而不是以功能清单为单位。下游团队要的是"某能力什么时候可用"，不是"你们做了多少需求"。

七、不同情况下的取舍：你不可能同时要快、稳、省

方法讲到这里，必须说清楚边界。资源评估不是让你把所有指标都做好，而是让你明确知道自己在放弃什么。以下四组取舍，是管理者真正要拍板的部分。

1. 快与稳：响应速度和可预测性天然对立

想要快速响应变化，就必须保留余量，代价是资源利用率下降、单位成本上升。想要高度可预测，就必须锁定范围、拒绝插入，代价是市场响应变慢。

这个取舍没有标准答案，但必须有明确选择。我见过最糟的情况是两头都要：既要求利用率 95%，又要求随时能插入紧急需求，结果团队长期处在救火状态，两件事都没做好。

可行的折中是分层：把 70% 的产能用于计划内确定性工作，20% 用于响应式工作，10% 留作缓冲。三层各有独立的排期规则，互不侵占。

2. 精细化与管理成本：颗粒度越细，成本越高

把需求拆到 4 小时、把人时统计到 0.5 小时，理论上排期会非常准。但填报成本、维护成本、沟通成本会同步上升，而且数据质量往往随颗粒度变细而下降。

我的经验阈值是：需求粒度以 1 到 3 人天为宜，工时统计以 0.5 人天为宜。低于这个粒度，投入产出比会迅速恶化。除非你的业务本身要求极高确定性（比如强监管行业），否则不必追求更细。

3. 承诺与弹性：对外承诺越硬，内部弹性越小

硬承诺能赢得客户信任，但也意味着你必须用缓冲去兜底，而缓冲是有成本的。软承诺保留弹性，但可能在商务竞争中处于劣势。

我的建议是按客户和合同金额分层：战略客户、大额合同用 P95 硬承诺并配置专属缓冲；标准客户用区间承诺；内部需求用 P50 排序。一刀切的承诺策略，要么伤客户，要么伤团队。

4. 工具与流程：工具能固化流程，不能创造流程

这是我在项目里反复强调的一点。工具的价值是把已经跑通的规则固化下来、把数据变成可视的，它不能替你决定需求该不该进、资源该不该借。

先有规则再上工具，工具会放大规则的效果；先上工具再补规则，工具会放大混乱。判断标准很简单：如果你的团队现在连"谁有权决定需求插入"都说不清，那上线任何平台都只是把混乱电子化。

5. 最后一点判断：什么时候该停止优化排期

排期优化的边际收益是有拐点的。当按期交付率到 75% 到 80%，继续提升的代价往往超过收益，因为你已经进入了用大量缓冲换少量确定性的区间。

这时候更该做的是提升"单位时间内的价值产出"，而不是继续压缩交付时间的方差。换句话说，从"把事做准"转向"做更对的事"。这个转向的时机判断，比任何排期技巧都更考验管理者的判断力。

结语：排期能力的本质，是组织对自己诚实的能力

写完这套方法，我想留下三个可能不那么讨喜的判断。第一，绝大多数排期问题不是技术问题，而是组织不愿意面对真实产能的问题，承认团队每天只有 4 到 5 小时有效产出，比学任何估算方法都难。

第二，工具解决的是"看得见"，规则解决的是"管得住"，两者缺一不可，但顺序不能反。第三，对外承诺的确定性，最终来自对内取舍的果断，而不是来自排期表做得多漂亮。

如果你打算这周就开始，我的建议是按这个顺序走：先用半天时间，把你团队过去 20 条需求的"实际/预估"比值算出来，得到自己的偏差分布；再用一小时，按四级扣减算出可调度人时。

这两个数字出来之后，你会立刻发现过去排期会上争的东西，有一半根本不用争。剩下的那一半，才是真正需要管理者拍板的取舍，也才是这套方法真正开始产生价值的地方。