需求排期需求排期教程：企业管理者效率提升，避坑指南

去年九月，我陪一家做工业软件的公司做季度复盘。会议室里挂着一张很漂亮的甘特图，四十五条泳道，每条都按周切好，颜色分层清清楚楚，看上去像是把未来三个月完全驯服了。CTO 指着图说了一句让我印象很深的话：“这张图我每周更新两次，但交付从来没跟上过。”我翻了他们过去两个季度的数据：排期承诺 118 个需求，按期交付 47 个，达成率 39.8%；而真正让他们难受的不是这个数字，是另外两个，需求进入排期后平均被改期 2.3 次，以及 61% 的延期发生在“已经开发到一半、被人插队打断”的场景里。

这就是我想在这篇文章里讲清楚的事情：绝大多数企业的需求排期失败，不是算错了工时，而是从一开始就没把约束条件写进排期表。排期表看起来是一张时间表，本质是一份关于“我们放弃什么”的契约。当这份契约里只有日期、没有取舍，它就一定会在第一次插队时崩掉，然后团队会用“加班”和“改期”两个动作反复修补，直到所有人都不再相信这张表。下面这套东西，是我在 100 人以上研发组织里反复用过、也反复改过的排期方法，包含结论、误区、判断逻辑、真实案例数据，以及不同规模组织该怎么取舍。

一、核心结论：排期不是排时间，是排约束

先把最重要的一句话放在最前面：需求排期的产出不应该是一张时间表，而应该是一份“资源，约束，承诺”的三元组。时间表只是这个三元组的一个视图。你如果只交付时间表，等于只交付了结论，没交付推导过程，任何人（包括老板）都可以在不改变资源的前提下要求改结论，这就是排期表永远在变的根本原因。

1. 排期失控的三种真实成因

我把过去几年接触过的排期问题做了归类，发现表面上的“估算不准”“执行力不够”“需求变太多”，往下追一层，基本都落在三个成因上，而且这三个成因的处理难度是递增的。

• 成因一：约束不可见。排期表里只有任务和日期，没有人力容量、没有依赖关系、没有缓冲池。团队知道“这周只有 3.5 个人力”，但表上看不出来，于是排期表天然比现实乐观 30% 以上。
• 成因二：承诺不分级。所有需求在表上长得一样，都是“某月某日上线”。但真实业务里，有的是对外合同承诺，有的是内部实验，有的是“有空就做”。混在一张表里，导致资源永远优先给了会喊的人，而不是最该给的人。
• 成因三：没有校准回路。排期做完就结束，交付完不复盘偏差，下个季度继续用同一套直觉估算。一年之后，团队的估算能力和一年前没有任何差别。

这三个成因里，第一个是工具和流程问题，改起来最快；第二个是管理决策问题，需要管理层真的愿意分级；第三个是组织习惯问题，最难，但它是唯一能让前两个改造长期生效的东西。

2. 三个可以直接拿走的判断

如果你只想要结论，这里是三条我认为在 100 人以上组织里几乎总是成立的判断，后面所有章节都是在论证它们。

1. 排期精度和需求颗粒度强相关，和估算方法弱相关。把一个大需求拆到 3 人天以内，用最简单的三点估算就够；不拆，用再复杂的模型也是垃圾进垃圾出。
2. 凡是产能利用率长期高于 85% 的团队，交付准时率一定下降。这不是勤奋问题，是排队论问题：利用率接近饱和时，等待时间呈非线性上升。
3. 承诺达成率低于 60% 的组织，问题几乎都在“需求准入”，不在“执行”。先别优化开发效率，先把不该进排期的需求挡在门外。

3. 伪排期和真排期的七个分水岭

下面这张表是我在做诊断时最常用的对照清单。左边这一列如果命中四项以上，说明你们做的其实是“伪排期”，形式上完成了排期动作，实际上没有产生任何约束力。

二、背景与真实场景：为什么中大型企业的排期会失控

小团队的排期几乎不需要方法。五个人坐在一间屋子里，谁手上有什么活大家心里都有数，插队了当场就能调。真正需要方法的是跨过 100 人这条线之后：需求来自五个以上业务方，研发分成六七个职能小组，交付要经过测试、运维、合规三道关口。这个时候，排期从“协调”变成了“调度”，而调度是有数学规律的。

1. 一个典型的季度排期现场

我见过最多的场景是这样的：季度初，产品负责人收集了 80 到 150 个需求，按业务价值打了分，拉了一张优先级列表。然后召集各团队 leader 开一次三小时的排期会，逐条过，能塞进这个季度的就打勾。会议结束时，表上有 60 多条任务被排进了三个月。

问题出在这次会议的隐含假设上：它假设所有被排进去的需求，规模都是已知且可信的，并且资源在整个季度内不会被抽走。而在真实环境里，这两个假设的成立概率大概只有一半。于是到了季度中期，表上 30% 的任务开始延期，管理层的第一反应是加压，团队的第一反应是把估算往上抬，第二轮排期会开完，表变得更保守，但达成率反而更低，因为保守的估算让更多需求被挤到下一个季度，压力进一步累积。

这个过程我称之为“排期通胀”。它不是任何一个人的失误，是系统缺少反馈回路时的必然结果。

2. 需求来源多头化：排期表永远在变的真正原因

很多管理者把“需求变更多”归因为市场变化快或者销售乱承诺。但我实际统计过，在一个典型的中大型组织里，一个季度内发生的需求变更，按来源拆开大致是这样的：

• 外部合规与客户合同变更：约占 20%。这类变更不可谈判，只能吸收，但可以提前预留容量。
• 高层临时插入的战略需求：约占 25%。这类变更的杀伤力最大，因为它通常不进入正常评审，直接以“这个很急”的形式落到某个团队。
• 上游需求没想清楚导致的返工：约占 35%。这类被伪装成“变更”，本质是准入没做好，是唯一可以通过流程大幅压缩的部分。
• 技术侧发现的新增工作量：约占 20%。这类属于估算问题，可以通过拆分和校准降低，但不可能消除。

换句话说，真正“外部不可控”的变更只有两成左右，另外八成里有一半以上是自己造成的。这就是为什么我坚持认为排期优化的第一刀应该砍在需求准入，而不是砍在开发效率上。

3. 排期的三个真实约束：人力、依赖、认知

我认为排期只需要管住三个约束，其他的都是衍生问题。这三个约束的重要性顺序，也和大多数人的直觉不同。

（1）人力约束：最容易看见，也最容易被算错

人力约束不是“有几个人”，是“有多少可用人天”。一个 8 人小组，一个季度按 13 周 × 5 天 = 520 人天算，看起来很宽裕。但扣掉周会、需求评审、线上支持、代码评审、休假、培训，实际可用往往只有 330 到 370 人天，也就是打了七折。如果排期表按 520 算，那张表从第一天起就已经超载 40%。

（2）依赖约束：最容易被忽略，成本最高

跨团队依赖的隐性成本极高。一个需求如果在等另一个团队的接口，等待的时间里人还在，但不能推进，这部分时间在表上是不可见的。我跟踪过的样本里，跨团队等待平均占需求总周期的 22% 到 31%，而绝大多数排期表里完全没有这一项。

（3）认知约束：最难量化，但决定长期上限

认知约束指的是团队对需求的理解程度。同一个需求，如果验收标准写得清楚、有原型、有历史相似案例，开发效率可能是模糊需求的两倍以上。这一项在排期里通常被完全忽略，但它是需求准入能产生巨大收益的根本原因。

三、拆解误区：九个最常见的排期陷阱

下面这九个误区，我在不同公司反复见到，而且它们经常同时出现、互相放大。我按“出现频率 × 破坏力”排了序，前三个基本是重灾区。

1. 误区一至三：把排期当成了填表

（1）误区一：把人力饱和度当成排期准确率

这是最普遍也最危险的一个。管理者看到每个人的排期都排满了，就觉得计划很扎实。但排期满载意味着零弹性，任何一次插队、任何一个人请假，都会直接造成延期。排队论里有个很朴素的结论：当系统利用率从 80% 提到 95%，平均等待时间不是上升 19%，而是上升三到五倍。

我在两家公司做过同样的观察：把团队计划利用率从 95% 降到 82%，季度承诺达成率分别从 51% 和 58% 提升到 79% 和 84%，而总交付需求数只下降了 4% 和 6%。少排一点，反而多交付。这个结论反直觉，但只要你的组织里存在插队，它就必然成立。

（2）误区二：用统一的工时口径估算跨职能需求

一个需求要经过产品设计、前端、后端、测试、运维五道工序，如果用“总工时 ÷ 总人数”来算周期，会严重低估。因为工序之间有先后，存在等待，串行的等待时间不会因为人多而消失。正确的算法是按关键路径算，而不是按总工时算。

（3）误区三：给老板的是日期，给团队的是范围

这是很多排期沟通里最隐蔽的问题。管理层听到的是“这个功能十月上线”，团队执行时发现做不完，于是悄悄砍掉一部分边缘功能，十月确实上线了，但功能不完整。短期看双方都过关，长期看信任被消耗，管理层下次会把日期往前压，团队会把范围再往小砍，形成负向螺旋。

正确的做法是：日期和范围只能固定一个。要么锁定日期、范围可谈；要么锁定范围、日期可谈。两个都锁，第三个变量（质量或人力）一定会替你做出选择，而且是在你没注意的时候。

2. 误区四至六：把排期当成了谈判

（4）误区四：忽略需求的“半成品状态”

大量需求进入排期时其实是半成品：有标题没验收标准，有想法没边界。这类需求在开发过程中会持续消耗澄清成本。我做过一次粗略统计，同一个团队里，验收标准完整的需求平均返工 0.4 次，不完整的平均返工 2.1 次，而每次返工平均吞掉 2.7 人天。

（5）误区五：排期会议变成谈判会

如果排期会的实际内容是各业务方争抢资源，那它产出的不是计划，是妥协。妥协的问题在于它没有记录取舍，被砍掉的需求消失了，没人记得它为什么被砍，下个季度它又会以“这个很重要”的姿态回来。健康的排期会应该有明确产出物：进入清单、退出清单、置换记录。

（6）误区六：只看单项目，不看资源池

到了 100 人以上，一个人往往同时参与两到三个项目。如果每个项目单独排期，每个项目都认为这个人有 50% 的时间可用，加起来就是 150%。这种情况在表上看不出来，只有把所有项目放进同一个资源池视图才会暴露。排期必须按“人”看，而不是按“项目”看。

3. 误区七至九：把排期当成了一次性动作

（7）误区七：上线即完成

很多排期表在“上线”这一格就结束了。但需求真正的成本往往在后面：线上问题处理、数据迁移、用户培训、后续迭代。如果这些不进入排期，它们会以“隐性支持”的形式吃掉团队 15% 到 25% 的产能，而排期表对此一无所知。

（8）误区八：没有缓冲，或者缓冲藏在每一条里

两种极端都常见。一种是不留缓冲，任何意外都直接变成延期。另一种是每个人在估算时偷偷加 20%，看起来每条都稳妥，但缓冲被分散在几十条任务里，无法统一调配。正确的做法是集中缓冲：所有任务按真实估算排，然后在项目级别放一个统一的缓冲池，谁出问题从池子里取。

（9）误区九：试图用工具解决流程问题

这是我最想强调的一条。很多组织发现排期乱，第一反应是上一套项目管理工具，把需求录进去、把看板建起来，然后排期就“规范”了。但工具只能让混乱变得可见，不能消除混乱。我见过上线工具后指标反而变差的团队，因为工具把原来隐藏在 Excel 和口头里的问题全部暴露出来，而流程没有跟上，团队反而更焦虑。

工具的价值在于让约束可计算，而不是让流程自动发生。顺序必须是：先定准入规则和承诺分级，再用工具承载，最后用数据校准。反过来做，基本都会失败。

四、专业判断逻辑：我用的四层排期模型

把上面这些误区反向拆解，就得到了我在实际项目里用的四层模型。它的顺序不能颠倒，因为每一层都依赖上一层的输出。我把这套模型叫“约束先行”排期法，核心思想是：排期不是把需求放进时间，而是把时间从约束里挤出来，再分配给需求。

1. 第一层：需求准入，把不合格需求挡在门外

准入是整个模型里收益最高的一层。我通常建议用一份不超过十条的清单，任何需求必须全部打勾才能进入排期池。清单不需要复杂，但必须被真的执行，包括对高层插入的需求也执行。

• 有明确的用户或业务场景，能说清“谁在什么情况下用”
• 有可验证的验收标准，至少三条，可量化
• 有明确的需求负责人，且这个人在排期期内不会换
• 规模已经拆分到 5 人天以内，超过的一律拆
• 依赖清单已列出，跨团队依赖已确认对接人
• 明确标注承诺等级（第三层会讲怎么定）

这份清单第一次推行时一定会遭遇阻力，理由是“太慢”。我的经验是先用数据说话：把过去一个季度因需求不清晰导致的返工人天算出来，通常会占总人天的 12% 到 20%。准入环节多花半天，能换回两周的返工。这个账只要摆出来，阻力会小很多。

2. 第二层：产能建模，把“有几个人”换成“有多少可用人天”

产能建模最容易做成形式主义，所以我常用一个很土的办法：拿过去 8 周的实际数据倒推。不问大家“你觉得有多少时间”，而是问数据“你实际有多少时间”。具体算法可以写成一段可复用的计算逻辑。

# 团队季度可用产能估算（按 13 周计）
输入均取过去 8 周的实际统计值，而不是主观估计

headcount = 8                    # 团队人数

workdays_per_week = 5            # 每周工作日

weeks = 13                       # 季度周数

gross_capacity = headcount * workdays_per_week * weeks   # 名义产能 = 520 人天

固定损耗（按实际记录，不用行业平均值）

meeting_ratio   = 0.11           # 会议

support_ratio   = 0.08           # 线上支持与答疑

review_ratio    = 0.05           # 代码评审与技术讨论

leave_ratio     = 0.06           # 休假、培训、调休

handover_ratio  = 0.03           # 交接、入职带教

loss_ratio = meeting_ratio + support_ratio + review_ratio + leave_ratio + handover_ratio

available = gross_capacity * (1 - loss_ratio)            # 可用产能 ≈ 348 人天

计划利用率上限（不是 100%，这是排期纪律的核心）

plan_utilization = 0.82

plannable = available * plan_utilization                  # 可排期产能 ≈ 285 人天

集中缓冲（按项目风险等级取值，不用平均分摊）

buffer_ratio = 0.12 if risk_level == "high" else 0.08

committable = plannable * (1 - buffer_ratio)               # 可承诺产能 ≈ 251 人天

print(f"名义 {gross_capacity} → 可用 {available:.0f} → 可排 {plannable:.0f} → 可承诺 {committable:.0f}")

这段逻辑的关键不在公式，在三个取值：损耗率必须来自自己的历史数据、计划利用率上限必须小于 1、缓冲必须集中而不是分散。很多团队算到“可用产能”就停了，直接把 348 人天全部排满，等于把损耗和缓冲都当成了可支配资源，结果就是必然延期。

另外一项常被忽略的是技能矩阵。同样是 348 人天，如果某个模块只有一个人能做，那这个模块的有效产能上限就是这一个人的可用时间，而不是团队总产能。排期时必须按“关键技能瓶颈”再削一次。

3. 第三层：承诺分级，把一张表拆成三张表

这是我个人认为投入产出比最高的一次改动。把所有需求按承诺强度分成三级，并且明确规定：只有第一级可以对外承诺具体日期。

分级之后会发生一件很有意思的事：承诺级的数量通常只占全部需求的 25% 到 35%。也就是说，过去组织里那些“必须按时完成”的需求，其实大部分并不真的必须。当这个比例被显性化，管理层往往第一次意识到自己在承诺上有多随意。

4. 第四层：校准回路，让每一次延期都变成资产

校准回路的做法很简单，但需要纪律：每个需求交付后，记录三个数，估算人天、实际人天、延期天数，并且按需求类型（新功能、优化、技术改造、缺陷）分别汇总。每季度算一次各类型的估算系数，下一季度估算时直接乘上去。

我跟踪过一个 60 人左右的研发团队，他们坚持做了六个季度，各类型的估算系数从最初的 1.42、1.28、1.65、1.15 逐步收敛到 1.15、1.09、1.21、1.04，季度承诺达成率从 54% 提升到 83%。这个提升没有引入任何新工具，靠的就是把偏差记录下来并反馈回估算。校准回路的价值不在于让估算变准，而在于让组织承认自己一直不准，并把这个事实制度化。

五、案例与数据观察：PingCode 在 100 人以上组织中的排期实践

讲到这里必须落到具体工具和具体场景上，否则容易变成方法论空转。在需求排期这个场景里，我合作较多的工具是 PingCode，它主要服务中大型企业及 100 人以上组织，产品形态覆盖需求管理、迭代排期、跨项目资源视图和度量报表，正好对应上面四层模型里最费手工的几块。下面这个案例来自一家 320 人左右的智能硬件企业，他们用 PingCode 做了一轮为期 9 个月的排期改造，我在中间参与了方案设计和两次复盘。

1. 改造前的真实状态

这家公司的产品线有三条，研发分成硬件、嵌入式、云端、App 四个中心，共 214 名研发人员。改造前的状态很有代表性：需求分散在三个业务方的 Excel 里，排期靠季度初的两天集中会议，跨中心依赖靠微信群沟通，度量数据基本为零。他们最痛的不是交付慢，而是无法回答“这个需求为什么还没做完”，每次老板问，团队只能给一个模糊的解释。

• 季度承诺需求 96 个，按期交付 44 个，达成率 45.8%
• 需求从提出到进入开发的平均等待时间 11.2 天
• 跨中心依赖导致的等待平均每次 8.4 天，且无记录
• 需求返工率 37%，主要原因是验收标准缺失
• 没有任何历史估算数据，全靠个人经验

2. 三个具体动作

他们没有做大跃进式的流程重构，只做了三件事，每件事都对应模型里的一层。

（1）动作一：把准入清单做成系统里的必填项

在 PingCode 的需求工作项里配置了强制字段：验收标准、需求负责人、规模分级、依赖项。缺任何一项，需求状态无法流转到“已排期”。这一条看似机械，但它把准入从“会议上的口头要求”变成了“系统里的硬约束”。推行第一个月，进入排期的需求数量从月均 38 个降到 24 个，业务方抱怨很多，但返工率在第二个月就从 37% 降到了 21%。

（2）动作二：建立跨中心依赖的统一视图

所有跨中心依赖必须在系统里建立关联，并且指定对方的交付点和责任人。这样做的直接效果是：依赖从“微信里的口头承诺”变成了“有日期、有责任人、会出现在对方迭代里的工作项”。跨中心平均等待从 8.4 天压缩到 3.1 天，这一项单独贡献了整个周期缩短的近四成。

（3）动作三：用度量报表替代季度末的手工统计

他们用系统里的度量能力，把估算偏差、承诺达成率、需求周期时间做成固定看板，每周例会只看这三个数。这件事的意义在于，校准回路从“靠自觉”变成了“靠报表”。团队不需要记得复盘，报表每周都在提醒。

3. 九个月的数据变化

下面这些数据来自他们内部的季度度量报表，我做了脱敏和归并。需要说明的是，这是一家公司的单点观察，不能直接外推成行业基准，但变化的趋势和幅度我认为有参考价值。

有两个地方值得单独说。第一，第 3 个月的估算偏差率是 46%，比“没数据”看起来更糟，因为一开始记录就会暴露真实情况，这是正常的阵痛期，很多团队在这一步放弃。第二，季度交付需求数从 44 涨到 68，涨幅 54%，但团队人数只增加了 11 人（约 5%），产出提升主要来自等待时间和返工的压缩，而不是加班。

4. 边界：这套方法什么时候不奏效

我不想把这套方法说得太万能，它在三种情况下效果会明显打折，甚至有害。

• 需求本身高度不确定的探索型业务。如果做的是全新市场的产品验证，需求的生命周期可能只有两周，做完整准入反而拖慢验证速度。这种情况应该用更轻的方式，只保留“规模拆分”和“集中缓冲”两条。
• 组织没有排期决策权。如果排期的最终决定权在老板一个人手里，且不接受置换机制，那所有分级和准入都会被一次“这个很急”推翻。这种情况下先解决授权问题，再谈方法。
• 团队规模低于 30 人。小团队的沟通成本本来就低，上重流程的收益抵不过管理开销。这个阶段用一张共享看板加每周一次对齐会就够了。

另外要提醒一句：工具能显著降低执行成本，但不能替代决策。我在这个案例里看到的真实收益，大约 30% 来自工具带来的可视化和自动化，70% 来自管理层愿意接受“进一个必须出一个”这条纪律。如果只买工具不改纪律，指标通常会在前两个月短暂改善，然后回落到原点。

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

方法论要落地，必须按组织现状裁剪。下面按规模、业务形态、成熟度三个维度给出可以直接执行的动作，都是我认为投入产出比最高的第一步。

1. 按团队规模：不同阶段做不同的事

（1）30 人以下：不要上流程，先统一语言

这个阶段最大的问题是每个人对“做完”的定义不一样。建议只做两件事：一是把需求拆到 3 人天以内，二是每周固定一次 30 分钟的排期对齐，明确本周承诺和下周预期。不需要准入清单、不需要度量报表、不需要承诺分级，沟通成本足够低，流程反而是负担。

（2）30 至 100 人：建立准入和产能台账

这个规模开始出现跨团队协作，等待时间开始显著。建议动作是：上线一份不超过十条的准入清单，建立一张按人统计的可用人天台账（每月更新），并把计划利用率上限设在 85%。这一阶段先不要做复杂的承诺分级，用“本周承诺 / 本月预期”两级就够。

（3）100 人以上：四层模型全上，重点是依赖和承诺分级

到了这个规模，产能和准入通常已经有一定基础，真正的瓶颈在跨团队依赖和承诺管理。建议优先做三件事：把所有跨团队依赖建到系统里并指定责任人、建立三级承诺体系并限制承诺级占比不超过 35%、把度量报表做成周会固定输入。工具层面，这个规模的组织通常需要像 PingCode 这类支持跨项目资源视图和度量能力的产品，因为它要解决的核心问题是“在多个项目和多个中心之间看清楚一个人到底有多少时间”。

2. 按业务形态：稳定型与变化型的差别

To B 业务和 To C 业务的排期逻辑几乎相反，把一套方法硬套到另一类业务上会出问题。

3. 按成熟度：从哪一步开始

如果你的组织现在完全没有排期数据，我建议的顺序是：先做两周的数据采集（记录估算和实际，不改变任何流程），再根据数据决定改哪里。这个顺序很重要，因为直接上流程往往会选错重点，你以为的瓶颈是开发效率，数据可能会告诉你瓶颈是等待。

1. 第 1，2 周：只记录，不改变。记录每个需求的估算人天、实际人天、等待天数。
2. 第 3，4 周：按数据定位瓶颈，通常是依赖等待或返工其中之一。
3. 第 2 个月：针对性改一项，不要同时改三项以上。
4. 第 3 个月：建立周度度量看板，把三个核心指标固定下来。
5. 第 4 个月起：引入承诺分级，并开始季度校准。

七、不同情况下的取舍

排期的本质是取舍，所以这一节可能是全文最实用的部分。下面四组取舍，我在不同组织里见过它们以不同方式被解决，没有标准答案，只有适用条件。

1. 精度与速度：排得多细才够

排期精度不是越高越好。把需求拆到 0.5 人天，估算成本会急剧上升，而收益几乎为零，因为拆分本身消耗的时间可能超过节省的返工。我的经验分界线是：单体需求规模在 2 到 5 人天之间时，排期的投入产出比最高。

• 如果你所在的组织变更频率低、合规要求高：倾向更高精度，拆到 2 人天，保留完整的依赖记录。
• 如果变更频率高、市场窗口短：倾向更低精度，拆到 5 人天即可，把省下的时间用于快速验证。
• 如果两者兼有（比如同时做合同项目和创新项目）：按项目类型分别设定精度，不要用一个标准统一要求。

2. 承诺与弹性：对外承诺多少才安全

承诺级需求占比是一个需要精细控制的变量。占比太高，排期失去弹性，一次插队就引发连锁反应；占比太低，业务方不信任排期表，会绕过流程直接找老板。我建议把承诺级控制在 25% 到 35% 之间，并且承诺级需求的资源必须是显式锁定的。

还有一个常被忽略的点：承诺级需求应该配有明确的“降级方案”。也就是当它真的做不完时，砍掉哪些范围还能保住核心价值。这个方案在承诺时就要写清楚，而不是延期时才临时讨论，后者一定会变成互相指责。

3. 工具与流程：先买还是先改

这个问题我被问过太多次。我的判断很明确：如果你的问题是没有数据，先上工具；如果你的问题是有数据但没人用，先改流程。两者的诊断方法很简单，随机抽五个需求，问负责人“这个需求的验收标准是什么、谁在做、什么时候能上”，如果答案清楚，说明流程没问题，缺的是记录和可视化；如果答案模糊，说明流程有问题，工具只会把模糊固化下来。

4. 集中与分散：缓冲放在哪里

缓冲的放置方式会显著影响延期分布。分散缓冲（每条任务加 20%）的问题是缓冲无法调配，某个任务出问题，它自己的缓冲不够用，别人的缓冲又拿不过来。集中缓冲（项目级留 10%，15%）的好处是可以按风险动态分配，代价是需要有人负责管理这个池子。

如果你们团队规模小、任务同质化高，分散缓冲也能用，管理成本低；如果任务异质化程度高、有长尾风险，必须用集中缓冲。这一点在硬件和嵌入式项目上尤其明显，一个物料延期的风险，靠单个任务的缓冲是吸收不了的。

写到这里，我想回到开头那家公司。他们后来没有做出更漂亮的甘特图，反而把泳道从四十五条砍到了十九条，图上多了两列：一列是被置换掉的需求，一列是缓冲池余额。CTO 后来说的一句话我觉得可以作为全文的收尾，“排期表的价值不在于它预测得多准，而在于它让所有人对‘我们放弃了什么’达成了共识。”

如果你准备开始改，我建议只做一件事：下周挑五个即将进入排期的需求，用准入清单逐条检查一遍，把不合格的退回补充，并记录这一步花了多少时间、拦下了几个。一周之后你会有两个数字：拦下比例和投入时间。这两个数字比任何方法论都更能说服你的管理层，也更能告诉你自己该从哪一层开始改。