需求排期需求排期全流程：项目成员入门指南与一文讲清

去年我帮一家做企业服务的公司复盘交付延期问题，翻完 6 个迭代的排期表，发现一件反常识的事：延期最严重的 11 个需求里，有 9 个在排期时的估算偏差不到 20%。问题并不出在“估得不准”。真正的问题在这些需求进入迭代之前：从来没有人认真问过一句“这个双周我们到底有多少小时可以干活”。排期表上的数字很漂亮，但它描述的主要是愿望，而非资源。

这篇文章讲的就是这条从“愿望”到“承诺”的路。我会按需求排期的完整流程拆开讲：需求怎么准入、容量怎么算、顺序怎么排、承诺怎么给、变更怎么接。中间会穿插我自己踩过的坑、对几个不同规模团队的样本观察，以及一个 300 人规模组织把排期从会议室搬进系统之后的真实变化。如果你是参与排期的开发、测试、设计或项目管理者，这篇可以当入门手册用；如果你已经在做排期，也可以拿它对照一下自己团队究竟卡在哪一层。

一、先给结论：排期是“用约束换承诺”，并非“填时间”

我见过太多团队把需求排期理解成一件行政工作：把需求列出来，把负责人填上，把日期写进去，然后发到群里。这种动作做完之后，团队得到的是一个时间表；但时间表并不等于承诺，承诺也不等于可交付。排期真正在做的，是把三种互相拉扯的约束摆到桌面上，让它们公开冲突一次，然后达成一个所有人都知道代价的约定。

这三种约束是：范围（要做多少）、容量（有多少人多少时间）、依赖（有多少事必须等别人）。任何一条排期，只要这三者中有一个是模糊的，这条排期就是假的。它会在执行过程中以“临时插入”“这个做不完”“等上游接口”的形式，把成本还给团队。

1. 一条真正成立的排期，必须四要素齐全

在约束之外，我还要求补充第四个要素：缓冲。前三个要素决定了“理论上能不能做完”，缓冲决定了“出意外时还撑不撑得住”。我把这四个要素合起来称为排期的四要素：范围、容量、依赖、缓冲。缺任何一个，排期就从“计划”退化成“口号”。

新人最容易缺的是容量和依赖。他们通常能说清楚“这个需求要做什么”（范围），也能说清楚“大概几天”（时间的粗略感），但说不清“这段时间里团队实际能投入多少”，也说不清“这件事在等谁”。这两块恰恰是排期里唯一需要专业判断的部分，其余都可以靠工具填。

（1）假排期和真排期的六个对照维度

2. 需求排期全流程其实只有六个环节

把排期拆到最细，它是一条六段流水线：需求收集 → 准入评审 → 容量测算 → 排序与依赖确认 → 承诺与发布 → 执行跟踪与滚动调整。新人常以为排期只是第四段“排序”，其实前面三段决定了排期质量的上限，后面两段决定了排期能不能被守住。

我统计过三个团队连续四个季度的需求流转记录，一条需求从提出到按期交付，整体通过率大约在 20% 上下。也就是说，排期表上写的十条需求，最后真正按期落地的可能只有两条。这个数字听起来很糟，但它本身并不糟，糟糕的是团队不知道衰减发生在哪一层。

3. 为什么“入门”阶段最容易走错方向

新加入项目的成员，通常被交给两件事：评估自己那部分的工作量，以及在排期会上汇报进度。这两件事都只覆盖了排期的很小一角，却容易让人形成一种错觉，排期就是“报工时”。一旦这个认知固化，后面所有的协作问题都会以“我明明估了 3 天”的形式爆发。

我更希望新人在第一个月就理解一件事：你不是排期的被动执行者，你是容量的所有者。你比任何人都清楚自己这周有几个会、要支持几次线上问题、有多少时间被切碎。把这些信息交出去，比报一个漂亮的工时数字有价值得多。

二、真实场景：一条需求在系统里走过的 37 天

讲抽象流程容易飘，我讲一条具体的需求。某 B 端产品的一个“批量导入支持自定义字段映射”需求，从客户提出到上线用了 37 天。开发实际投入 6.5 人天，测试 2 人天，设计 0.5 人天。按纯工作量算，一个双周迭代足够。那剩下的 28 天去哪了？

我拆了这条需求的状态停留记录：在“待评审”停了 4 天，因为要等客户成功补充真实数据样例；在“待排期”停了 11 天，因为当期迭代容量已满；开发中 6 天，其中 2 天在等上游数据服务的字段字典；待测试 3 天，测试环境被另一个项目占用；待发布 5 天，赶上了月度发布窗口。真正有效率的时间不到三分之一。

1. 排期表上看不见的三类时间

第一类是等待时间。它不是任何人偷懒造成的，而是资源和信息没有同时在位。等待时间通常占端到端周期的 50% 以上，但几乎从不出现在排期表里，因为它不属于任何一个人的工时。

第二类是切换时间。一个人手上同时压着三个需求，每切换一次都要重新加载上下文。我做过一个粗糙的自我记录：连续两周记录自己每天被打断的次数和恢复工作状态所需的时间，平均每次打断后需要 11 分钟才能回到原来的思路。一天被打断 6 次，就是 1 小时以上的净损失。

第三类是协调时间。跨团队需求的对齐会、接口联调、评审会，这些时间真实消耗人力，但很少被计入排期。一个 100 人以上的组织，一个需求平均要经过 2.4 个团队的协作，协调成本会随团队数量非线性上升。

2. 名义工时和可用工时之间，差着一半

排期里最常见的技术性错误，是把“8 小时 × 人数 × 天数”当成可用容量。这是名义工时，它从来没有真实存在过。我在多个团队做过同一件事：让成员连续两周记录自己每一个半小时在做什么，然后按类别汇总。结果相当稳定，真正能用于深度开发的净时间，大约只有名义工时的 45% 到 55%。

这个比例在不同角色上差异很大。后端开发因为要处理线上问题和技术支持，净时间比例通常最低；测试在版本后期会被高度压缩；设计在评审周几乎无法产出。排期时如果所有人一律按 8 小时算，等于系统性地高估了 80% 以上的产能。

3. 100 人以上组织为什么复杂度会跳变

20 人的团队，排期靠三个人碰一下就能定。到了 100 人以上，排期会突然变成一个组织问题，原因有三个。第一，容量不再可加：A 团队的 3 个空闲人天，填不进 B 团队缺人的测试环节，因为技能不匹配。第二，依赖开始成环：需求 A 等 B 团队接口，B 团队等 A 团队的数据结构，两边都在等对方。第三，信息开始失真：三层汇报之后，“还需要一周”会变成“本周完成”。

这也是为什么中大型组织几乎一定会引入系统化的排期载体。我接触过的一家 300 人规模的企业服务公司，最终选的是 PingCode 这类面向中大型组织的研发管理平台，它的需求池、迭代规划、工时与依赖视图能把“谁在什么时候有什么容量”这件事从会议纪要变成可查询的数据。工具本身不解决判断问题，但它能让判断所需的信息不再靠人肉汇总。

三、拆解七个高频误区

下面这七条，是我在复盘会上重复讲过最多次的。它们不是“最佳实践的反面”，而是新人（甚至不少有几年经验的人）真实会犯的错。每一条我都会说清错在哪、代价是什么、怎么改。

1. 把人天估算当成排期结论

“这个需求 5 人天”，这是一条估算，不是一条排期。估算回答的是“工作量有多大”，排期回答的是“哪几天、谁来做、做完谁验、什么时候能上”。把前者当后者，团队就会得到一句“5 天后见”，然后在这 5 天里被会议、支持、等待反复打断。

正确的做法是两步走：先估工作量（不含缓冲），再把它放进容量日历，看落在哪几天、与哪些事冲突。估算的单位是人天，排期的单位是日期区间，两者之间隔着一层容量换算，这层换算不能省。

2. 只排开发，不排测试、联调和发布

一个典型的新人排期表长这样：需求拆成 4 个开发任务，每人 3 天，第 6 天上线。中间没有测试时间，没有联调时间，没有发布窗口。执行到第 5 天，测试说“我这边还有两个版本在排”，发布说“这个月窗口已经过了”。

我的经验比例是：一个中等复杂度的需求，开发、测试、联调、发布的工时比大约是 5:2:1.5:0.5。也就是说，如果开发是 5 人天，端到端至少还要再加 4 人天的其他角色投入。漏掉这部分，排期会稳定地短 40% 左右。

3. 把优先级当成执行顺序

P0 先做，P1 后做，这个逻辑在需求少于 10 条时勉强成立，超过之后就会失效。原因是有依赖。一个 P1 需求可能是某个 P0 需求的前置条件，先做 P0 反而会卡住。还有一种情况：三个 P0 需求抢同一个瓶颈资源（比如唯一懂支付系统的那个后端），它们的“优先级”其实无法区分，能区分的只有先后顺序。

更实用的判断是价值密度加约束条件：用价值除以成本得出密度，再叠加截止日期、依赖关系和瓶颈资源占用三个约束。密度决定“值不值得做”，约束决定“现在能不能做”。两者都通过，才能进当期排期。

4. 忽略外部等待和前置依赖

依赖分两种。内部依赖是团队内的，看得见；外部依赖是跨团队、跨供应商、跨审批的，最容易被默认成“到时候就有了”。我见过一个需求因为等一份第三方合规文档，在“开发完成”状态下停了 19 天，排期表上完全看不出来。

处理办法很笨但有效：每条需求在进入排期前，必须明确列出“我在等什么、等谁、对方承诺哪天给”。如果这三个问题答不出来，这条需求就不该进排期，它应该留在待排期池里等条件成熟。

5. 让最忙的人估值，让不干活的人承诺

这是一个组织问题。常见的错配是：技术负责人凭经验给出一个日期，而这个日期既不是执行者估的，也没有经过执行者确认。等到执行时，实际做的人发现根本做不完，但他不好意思推翻已经发出去的承诺。

我的判断是估算权归执行者，承诺权归容量所有者。执行者说他这块需要 4 天，这是估算；项目管理者结合整体容量和冲突，说这个需求在 3 月 14 日交付，这是承诺。两者分离，责任才清晰。

6. 一次排死，不做滚动

有些团队每个季度初排一次，之后三个月不再动，理由是“排期老变说明管理混乱”。这个逻辑恰好相反：排期不变，通常意味着它已经和现实脱节了。市场在变、线上问题在插、人在流动，一个季度前的判断不可能还成立。

更合理的是分精度滚动：最近 2 个迭代做精确到天的排期，第 3 至 6 个迭代做粗到周的规划，更远的只做容量预留和方向性判断。精度是有成本的，把精度花在最近两周，收益最高。

7. 没有合法的“未排期”状态

这是我认为最隐蔽、代价最大的一个误区。很多团队的需求池和排期表是同一张表，所有需求都“在排期中”，只是时间栏空着。结果是：需求方看到自己的需求在表里，就认为“已经在做了”；团队看到表里堆着 80 条，就默认“这些都要做”。双方对进度的理解从第一天起就是错位的。

健康的结构必须有三个明确状态：已收集（还没评估）、已准入（评估过、在等容量）、已排期（有日期、有负责人、有验收口径）。“未排期”必须是一个被公开承认的合法状态，而不是一种失败。

四、专业判断逻辑：四层漏斗和三个公式

排期做得好不好，差别不在工具，在判断顺序。我把它整理成一个四层漏斗，从上到下逐层收窄。每一层都有一个明确的判断问题，答不上来就不要往下走。

1. 第一层：准入，这条需求值不值得占用容量

准入层的唯一问题是：把这一份容量花在这里，是不是当前最优的选择。注意，问的并不是“这个需求重不重要”。几乎所有需求都重要，容量却是有限的，真正要回答的是机会成本。

我用的判断工具是价值密度：分子是预期价值（收入影响、客户留存、效率提升、风险消除），分母是端到端成本（开发、测试、联调、文档、后续维护）。两者都不需要精确到小数，量级对就够用。一个价值 30 万、成本 20 人天的需求，密度是 1.5 万/人天；一个价值 5 万、成本 1 人天的需求，密度是 5 万/人天。后者应该先做。

（1）准入评审必须产出的四项信息

• 价值口径：这条需求上线后，哪个指标会变化，变化多少，谁来验证。
• 可验收的最小范围：如果只能做 60%，做哪 60% 仍然有价值。
• 不做会怎样：是流失风险、合规风险，还是只是“体验不够好”。
• 成本量级：是一个迭代内、一个季度内，还是跨季度的大工程。

这四项信息不齐的需求，一律退回待补充状态。这一条执行得越严格，后面的排期会越轻松。我见过把准入做扎实的团队，待排期池从 120 条压到 30 条，排期会的时长从 90 分钟降到 35 分钟，而交付量没有下降。

2. 第二层：容量，到底有多少可承诺的小时

容量测算是我认为最被低估的一环。它不需要复杂模型，只需要把名义工时逐项扣减，并且把扣减过程公开。下面这段脚本是我自己在用的简化版，输入成员的空闲比例，输出可承诺工时。

def commit_hours(members, days, buffer_ratio):
"""

把名义工时折算成可承诺工时。

members: [{"name": str, "meeting": float, "support": float, "leave": float}]

buffer_ratio: 风险等级对应的缓冲比例，低 0.10 / 中 0.20 / 高 0.35

"""

total = 0.0

detail = []

for m in members:

nominal = days * 8

扣掉会议、支持、休假

available = nominal * (1 - m["meeting"] - m["support"] - m["leave"])

上下文切换折损，经验值 15%

net = available * 0.85

detail.append((m["name"], round(net, 1)))

total += net

迭代级缓冲集中管理，不摊到个人

committable = total * (1 - buffer_ratio)

return round(committable, 1), detail

team = [

{"name": "后端A", "meeting": 0.20, "support": 0.15, "leave": 0.10},

{"name": "后端B", "meeting": 0.15, "support": 0.05, "leave": 0.00},

{"name": "前端C", "meeting": 0.20, "support": 0.10, "leave": 0.00},

{"name": "测试D", "meeting": 0.25, "support": 0.15, "leave": 0.20},

]

hours, detail = commit_hours(team, days=10, buffer_ratio=0.20)

print(hours, detail)

名义 320 小时，可承诺约 190 小时，缓冲 48 小时

这段代码的价值不在算法，在流程：它强制团队把“会议占 20%”“测试这周有 2 天休假”这些平时只存在于脑子里的信息写下来。一旦写下来，排期会上的争论就从“我觉得做不完”变成“测试只有 4 天可用，这 3 条需求的验收排不进去”，讨论立刻变得具体。

（2）容量测算的三个纪律

1. 按技能算，不按人头算：8 个人里只有 2 个能做支付相关改造，真实容量是 2，不是 8。
2. 瓶颈资源单独列出：瓶颈岗位的容量决定整个迭代的上限，其他资源再空闲也没用。
3. 缓冲不摊到个人：个人估算里加 20% 的安全垫，会被计划谬误吃掉，也掩盖了真实风险。缓冲应该集中在迭代层面，公开可见、按需消耗。

3. 第三层：排序，关键路径和瓶颈资源

排序的本质是找路径。把本迭代所有需求按依赖关系连起来，最长的那条链就是关键路径，它决定了迭代的最短周期。关键路径上的任何一个环节延误一天，整个迭代就延误一天；不在关键路径上的环节，有一两天的自由度。

这一步新人几乎都会跳过，因为它需要把需求画成图而不是列成表。但收益很直接：我参与过的一个团队，把迭代需求画成依赖图之后发现，有三条需求都在等同一个接口，而这个接口排在迭代的第 7 天。把它们前移之后，迭代周期从 12 天缩到 9 天，没有增加任何人。

另一个排序技巧是识别瓶颈资源并给瓶颈排满。如果全团队只有一个人会做某类工作，那么他的日程应该是最后被排的，其他所有事绕着它转。非瓶颈资源排得再满，也只是在制造库存，不会提高产出。

4. 第四层：承诺，给区间，不给单点

承诺环节最容易被外部压力扭曲。需求方要一个日期，团队给一个日期，双方都得到了心理安慰，但没人知道这个日期有多大概率成立。我的做法是给区间和概率：“80% 概率在 3 月 14 日前交付，95% 概率在 3 月 21 日前”。这个表述比“3 月 18 日”诚实得多，也让需求方能够自己做决策。

区间从哪里来？从历史数据来。如果团队过去 8 个迭代里，同规模需求的周期分布在 6 到 11 天之间，中位数 8 天，那么 P80 大致落在 10 天，P95 落在 13 天。这个统计不需要多精密，跑几个迭代就能有可用的分布。

5. 三个可以直接拿去用的公式

公式一：可承诺容量 = 名义工时 ×（1 − 非生产占比）× 0.85 ×（1 − 缓冲比例）。非生产占比取 0.35 到 0.45，0.85 是上下文切换折损，缓冲比例按风险取 0.10 到 0.35。用它算出来的数字，通常只有名义工时的三分之一到一半。

公式二：价值密度 = 预期价值 ÷ 端到端成本。端到端成本要含测试、联调、文档和后续维护，不能只算开发。这条公式用来做准入和排序，比拍脑袋的优先级可靠。

公式三：迭代内变更成本 = 基础工时 ×（1 + 0.15 × 插入时点天数）。这是一个经验拟合式：迭代第 1 天插入，成本约 1.15 倍；第 5 天插入，约 1.75 倍；第 8 天插入，约 2.2 倍。它用来说明一件事，越晚插入，代价越高，而且这个代价必须由提出方看见。

五、案例与数据观察：一家 300 人公司的排期改造

下面这个案例来自我参与的一次为期两个季度的改造。公司做企业级 SaaS，研发加产品测试约 300 人，分 9 个小组，同时维护 3 条产品线。改造前的状态很有代表性：需求池里 400 多条需求，排期靠每周三一场 90 分钟的会，会后由项目管理者手工汇总进一张共享表格。

1. 改造前的三个具体症状

症状一：排期会和实际执行完全脱节。会上定的日期，会后第二天就被新插入的需求冲掉，但表格上没有记录，两周后没人说得清当初为什么这么排。

症状二：跨组依赖靠微信同步。A 组等 B 组的接口，B 组不知道 A 组在等，A 组以为 B 组知道。这类问题平均每月发生 6 到 8 次，每次平均阻塞 3.5 天。

症状三：没人知道真实容量。每个组都报“人手紧张”，但没有任何数据能说明紧张在哪、紧张多少。资源协调会变成了立场谈判。

2. 改造做了四件事

第一件，把需求池和排期表彻底分开。需求池只放“已收集”和“已准入”两种状态，排期表只放“已排期”。这一条花了两个月才真正落地，因为业务方习惯了“把需求丢进排期表就等于承诺”。

第二件，把容量测算变成每迭代的固定动作，用统一的工时口径，扣除会议、支持和休假。这一步的阻力最大，因为等于公开承认“我们只有一半时间在干活”。但数据一出来，很多争论自然消失了。

第三件，把所有跨组依赖搬进系统，每条依赖必须有对方负责人和约定日期。这里他们用的是 PingCode 的跨项目依赖和迭代规划视图，不是为了自动化，而是为了让“谁在等谁”这件事有一个唯一的、所有人可见的答案。

第四件，改成滚动排期：最近 2 个迭代精确到天，第 3 至 6 个迭代粗到周，其余只做容量预留。同时引入迭代级缓冲，按风险高低取 10% 到 30%。

3. 两个季度后的数据变化

下面这组数据来自他们内部的两个季度对比，统计口径是 9 个小组的全部需求，属于单一样本，不能直接外推到其他组织，但方向值得参考。

有一点需要说清楚：这些改善里，工具只贡献了一部分。真正起作用的是“需求池与排期表分离”和“容量公开”这两个流程决定。工具的作用是让这两个决定可以被持续执行，而不是执行两周就退回原样。

4. 三个可以被验证的观察结论

结论一：排期准确率的提升，主要来自减少插单，而不是提高估算精度。这家公司改造后估算偏差只从 24% 降到 19%，但按期交付率提升了 27 个百分点。差别在于插单比例从 31% 降到 14%。

结论二：需求池的规模和被交付的速度成反比。400 条需求的池子和 96 条的池子，后者的端到端周期短了 35%。池子越大，评审越草率，优先级越混乱，每个人都在处理“最紧急”的那一条。

结论三：跨团队依赖的可视化，收益比任何排期算法都高。依赖阻塞天数从 3.5 天降到 1.2 天，单这一项就贡献了整个周期改善的一半以上。原因很简单，大部分阻塞只是因为对方不知道你在等。

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

排期没有唯一正确答案，只有和团队规模、业务形态匹配的答案。下面按四种情况给具体建议，你可以直接对照自己的团队。

1. 20 人以下的小团队：先保节奏，别上流程

这个阶段最忌讳照搬大厂流程。20 人以内，信息传递成本低，一句话就能同步清楚，引入复杂的准入评审和容量测算反而会拖慢速度。你需要的只有三件事。

• 一个唯一的待办清单：所有需求进同一个列表，不要分散在群聊、邮件和某人的笔记本里。
• 一个固定的排期节奏：每周固定 30 分钟，只决定“下周做什么”，不做季度规划。
• 一条插单规则：插入新需求必须移出等量的旧需求，由提出方选择砍哪一条。

这个阶段不需要精确到人天的容量测算，但需要有一个粗略的感觉：本周可用人力是 3 个人还是 2 个人。有一个人休假，容量就掉三分之一，这个判断不需要工具。

2. 20 到 100 人：把容量和依赖显性化

这个规模是转折点。团队开始出现分工，一个人不再了解所有人的工作，跨组协作变得频繁，口头同步开始失效。核心动作是两件：让容量可见，让依赖可见。

容量可见的做法是每个迭代做一次工时折算，用固定的口径，哪怕粗糙也要统一。依赖可见的做法是每条跨组依赖都有明确的“谁在等谁、等什么、什么时候给”。这两件事用一张表就能做，不必急着上系统。

同时要开始积累历史数据。每个迭代记录一次“计划 vs 实际”，跑满 6 个迭代之后，你就有了自己的周期分布，承诺时给区间才有依据。

3. 100 人以上或多团队：系统承载加定期校准

这个规模下，靠人工汇总的排期表会迅速腐化。信息在传递三层之后失真，依赖在多个团队之间成环，容量数据一周就过期。这时候需要一个统一的载体，把需求、迭代、工时、依赖、发布放在同一套口径里。

这也是我建议在这个阶段考虑 PingCode 这类面向中大型组织的平台的原因：它的价值不在于功能多，而在于让 9 个小组用同一套字段描述同一件事。需求状态、工时口径、依赖关系一旦统一，跨团队的排期会从“谈判”变成“查询”。

但工具上线只是开始，还需要两个配套动作。一是每两周校准一次容量口径，因为组织在变，人的可用比例也在变。二是每月复盘一次准时率与插单率，这两个指标比“完成了多少需求”更能反映排期系统的健康度。

4. 项目制与产品制：两种节奏，两套排期逻辑

项目制的特征是边界清晰、有明确交付终点，排期应该以里程碑和关键路径为核心，缓冲集中在阶段交界处。产品制的特征是持续迭代、需求源源不断，排期应该以稳定节奏和吞吐量为核心，关注每个迭代的平均交付量是否稳定。

两者混用会出问题。我见过产品团队用项目制的方式排期，每个迭代都设里程碑，结果每个迭代都在赶工，技术债越积越多。也见过项目团队用产品制的方式排期，永远在“下个迭代再做”，最终交付日期一再推迟。

5. 新成员第一周该做的五件事

1. 找到团队唯一的排期载体，把最近两个迭代的需求完整看一遍，包括已经延期的。
2. 问清楚工时口径：一天按几小时算，会议和支持怎么扣，缓冲谁管。
3. 找出自己负责的部分有哪些前置依赖，逐条确认对方的承诺日期。
4. 记录自己一周的真实时间去向，得到一个个人的可用工时比例。
5. 在下次排期会上，主动说出“我这周实际可用 X 小时”，而不是报一个整数。

这五件事做完，你对排期的理解会超过大部分工作了两三年的人。因为它们全都指向同一件事：排期的质量取决于信息的真实度，而不是格式的漂亮度。

七、不同情况下的取舍

排期做到最后，剩下的全是取舍。下面五组矛盾没有标准答案，但每一组都有一个判断依据，能帮你在具体场景下做决定。

1. 范围、时间、质量：三个只能保两个

这是最古老也最常被回避的一组。当三者冲突时，团队必须明确说出“我们砍哪一个”，而不是三个都想要。我的判断顺序是：质量不可让，时间和范围可以谈。质量让步的代价会延迟显现，通常在两三个季度后以技术债和线上故障的形式回来，而那时候修复成本是当初的几倍。

具体操作上，宁愿缩小范围保时间，也不要扩大范围拖时间。一个按期交付的 60% 版本，比一个延期两个月的 100% 版本更有价值，因为它能更早拿到真实反馈。

2. 精度与成本：精度是有价格的

把排期精确到半天，需要投入的沟通成本可能是精确到周的 5 倍，而收益在大多数场景下并不成立。我的经验分界线是：两个迭代以内值得精确到天，两个月以内精确到周，更远只需要容量预留。

这条分界线背后的逻辑是信息衰减。超过两个月的需求，其范围和优先级发生变化的概率超过 50%，为它做精确排期的期望收益是负的。

3. 透明度与心理安全：数据公开到什么程度

排期数据全公开能提升协作效率，但也可能变成压力工具。如果“延期次数”被用来考核个人，团队会立刻学会两件事：把估算拉长，把问题藏起来。这两种行为都会让排期数据彻底失真。

我的建议是公开流程数据，不公开个人排名。迭代的准时率、插单率、周期分布应该全员可见；某个人的延期次数不应该被单独统计和比较。前者改进系统，后者制造防御。

4. 集中排期与分散排期：谁来做决定

集中排期效率高、口径统一，但容易脱离一线；分散排期贴近实际、响应快，但容易出现资源冲突和重复投入。中大型组织的常见做法是集中定规则和容量，分散定具体顺序。平台团队统一工时口径、缓冲策略和依赖管理规则，各小组在自己的容量范围内决定做什么、先做哪个。

这个分层的关键在于“容量”是集中分配的资源，“顺序”是分散决策的权力。把两者混在一起，要么总部管得太死，要么各组抢资源抢成一团。

5. 工具与流程：工具放大流程，不创造流程

这是我最后想强调的一点。工具能放大一个好流程的效果，也能放大一个坏流程的混乱。在需求池和排期表还没分开的时候上系统，你只会得到一张更精致的、400 条需求的混乱表格。

判断顺序应该是：先确定状态定义（什么是已准入、什么是已排期），再确定容量口径（一天按几小时、扣哪些），再确定变更规则（插单换什么），最后才选工具承载这三件事。反过来做，多半会失败。

八、总结：排期能力的三条反常识结论与下一步

写到这里，我把整篇文章的判断压缩成三条结论，它们都不太符合直觉，但我在多个团队里反复验证过。

1. 三条反常识结论

第一，排期准确率的提升主要来自“少做事”，而不是“算得准”。减少插单、缩小范围、拆小需求，这三件事对准确率的贡献远大于提升估算技巧。估算偏差从 30% 降到 20% 很难，插单率从 30% 降到 15% 只要一条规则。

第二，让“未排期”合法，反而能提高交付速度。承认大部分需求暂时不会被排期，团队才能专注在当前这几条上。池子越小，评审越认真，优先级越清晰，周期越短。

第三，缓冲不是浪费，是调度能力。把容量排到 95% 的团队看起来最努力，实际上最脆弱，任何一次插单都会引发连锁延期。留出 20% 的余量，是给不确定性买的保险，也是给团队留的反应时间。

2. 明天就能做的五件事

1. 把当前的需求列表按三个状态重新分一遍：已收集、已准入、已排期。分不完没关系，先分出“已排期”那一部分。
2. 算一次真实容量：名义工时扣掉会议、支持、休假，再打 85 折，看看剩多少。
3. 找出本迭代所有跨团队依赖，逐条补上“对方负责人”和“约定日期”。
4. 给下个迭代设一个公开的缓冲比例，写在排期表最上方。
5. 定一条插单规则：插入必须移出等量范围，由提出方选择砍哪条。

3. 两周和一个季度分别检查什么

两周后检查两件事：容量测算有没有真的用上（还是排完就忘了），插单规则有没有被破例（破了几次、为什么）。如果这两件事都做到了，排期表的可信度会明显上升。

一个季度后检查三件事：按期交付率、需求端到端周期中位数、跨团队依赖的平均阻塞天数。这三个指标合起来，能判断你的排期系统是在改进还是在退化。至于用不用工具、用哪个工具，到这个阶段反而不重要了，流程对了，表格也能跑；流程不对，再好的系统也只是把混乱记录得更整齐。

如果你现在只能记住一句话，我希望是这句：需求排期的本质，是把有限的容量诚实地分配给无限的需求，并且让所有人都看见这个分配的过程。做到这一点，排期就不再是每周一次的争论，而变成团队真正的调度能力。