需求排期资源评估全流程：跨部门团队数据分析与一文讲清

2023 年 Q3，我参与过一家 400 人规模公司的季度排期会。会议室里坐了三拨人：产品、研发、测试，白板上贴了 60 多张需求卡片，按“优先级”从 P0 排到 P3。三个小时后，大家达成一致：本季度交付 47 个需求。季度末复盘，真正按时上线的只有 29 个，兑现率 61%。更扎心的是，那 18 个延期的需求里，只有 4 个是因为“技术难度超预期”，剩下 14 个全部卡在同一件事上，等另一个部门的接口、等测试环境、等上游数据字段确认。

会后有人说了一句话，我记到现在：“我们排的是人力，卡的是依赖。”

这就是需求排期资源评估的真实困境。大多数团队把这件事理解成“把需求分给人、把天数加起来”，于是排期会开成了分账会，资源评估做成了算术题。但跨部门团队里，真正决定能不能交付的，从来不是总人力够不够，而是关键路径上的等待时间有没有被看见。这篇文章我想把这套流程完整拆开：从需求进入到承诺交付，中间要建哪几本账、用什么数据口径、在什么节点做判断、以及在资源不足时怎么取舍。

一、核心结论：排期的对象不是任务，是不确定性

先把结论摆出来。我在过去几年里看过几十个团队的排期流程，凡是能持续做到 80% 以上承诺兑现率的，几乎都在这四件事上和别人不一样。这四件事听起来不复杂，但每一件都和主流做法相反。

1. 排期排的不是工时，是交付区间

“这个需求 8 人天。”这句话在跨部门场景里几乎没有信息量。8 人天是乐观估计还是悲观估计？包含不包含联调？依赖方什么时候给接口？如果这三个问题没有答案，8 人天就只是一个让会议能结束的数字。

我的判断是：资源评估的合格产出，是一个带置信度的区间，而不是一个确数。比如“P50 是 9 个工作日，P85 是 15 个工作日”，含义是“有一半概率 9 天内完成，有 85% 概率 15 天内完成”。对外承诺用 P85，对内排布用 P50，中间那 6 天差额就是你需要管理的缓冲，而不是需要隐藏的 slack。

这个转变的价值在于：它把“延期”从道德问题变成了统计问题。团队不再需要为“为什么没做到 8 天”辩护，而是可以讨论“我们的 P85 估计准不准、缓冲留得够不够”。

2. 资源评估的第一个动作是扣减，不是加总

绝大多数排期表是这样算的：12 个人 × 20 个工作日 = 240 人天。这个数字通常比真实可用容量高出 35%-50%。

要扣的东西很具体：法定假与年假、例会与评审、线上问题支持、代码评审与技术债、跨部门沟通、新人上手损耗。我跟踪过的团队里，一个 12 人研发小组在 20 个工作日内的有效可支配工时普遍落在 130-155 人天之间，也就是名义容量的 54%-65%。

如果你用 240 人天做规划，等于一开始就给自己埋了 40% 的透支。这不是执行力问题，是记账问题。

3. 跨部门排期的瓶颈在依赖，不在人数

一个反常识的观察：在 100 人以上的跨部门组织里，需求从“排进迭代”到“真正开始动手”的平均等待时间，往往占到端到端周期的 25%-40%。等待发生在哪？等接口文档、等上游数据、等测试环境、等另一个团队的空档、等一个跨部门评审会。

这意味着，同样增加 10% 的人力，收益远小于把这 30% 的等待压缩一半。前者需要招聘、上手、磨合，周期 3-6 个月；后者只需要把依赖关系显性化、把接口人定下来、把联调窗口提前锁死。

4. 必须被量化的四个指标

如果只能保留四个数字，我会留这四个。它们构成了资源评估的最小可观测集：

• 有效容量率：有效可支配人天 ÷ 名义人天。低于 55% 说明会议与支持性工作已经侵蚀了交付能力。
• 承诺兑现率：按期交付需求数 ÷ 承诺需求数。这是排期流程唯一的终极结果指标。
• 跨部门等待占比：需求处于“阻塞/等待”状态的天数 ÷ 端到端周期。它直接告诉你瓶颈在谁那里。
• 需求返工率：进入开发后因需求理解偏差导致的返工需求数 ÷ 总需求数。它衡量的是准入质量，不是开发质量。

二、背景与真实场景：为什么排期越来越难

排期难不是新问题，但难的形状变了。五年前，一个团队的需求大多在自己的边界内闭环，排期的核心矛盾是“谁先做”。现在，一个稍微复杂一点的需求，平均要穿过 3-5 个团队边界，核心矛盾变成了“谁能先给我东西”。

1. 三个结构性变化

（1）需求从功能型变成链路型。以前一个需求改一个页面，现在一个需求要动前端、后端、数据、算法、风控、运营配置。任何一环没到位，整条链路就交付不了。排期的单位从“任务”变成了“链路”，而大多数排期表还是按任务粒度做的。

（2）资源从专属变成共享。中大型组织里，测试环境、数据平台、基础架构、设计资源往往是共享池。共享池的特点是：你觉得你有 1 个测试工程师，实际上你要和其他 4 个项目排队。排期表上写的是 1，实际可用是 0.2。

（3）承诺的传导链条变长。一个对客户的交付承诺，向上会拆成产品承诺、研发承诺、测试承诺、运维承诺。链条上任何一环的“大概没问题”，到最外层就变成了确定性承诺。信息在传导过程中被不断“乐观化”，这是承诺兑现率长期低于 70% 的组织性原因。

2. 一个真实的季度排期现场

回到开头那家 400 人公司。我花了两周时间复盘他们 Q3 的排期数据，发现三件很典型的事。

第一，47 个承诺需求里，有 31 个在排期当天并没有明确的验收标准。也就是说，三分之二的需求在“能不能做”还没定义清楚的时候，就已经被估了人天。这直接导致后面 18% 的返工率。

第二，跨部门依赖一共识别出 63 条，但只有 12 条被写进了排期表，且没有一条标注了“对方什么时候给”。剩下 51 条依赖在排期会上被一句“这个到时候对一下就行”带过。

第三，测试资源在排期表上被记为 6 人全程投入，但实际上这 6 个人同时支撑 4 条产品线，Q3 期间平均只有 2.3 人的等效投入。排期表的资源和真实资源之间，差了 2.6 倍。

这三件事叠加起来，61% 的兑现率其实是一个“合理”的结果，流程本身就已经注定了它做不到。

3. 不同规模团队，排期难在哪不一样

我不能给一套放之四海的流程，因为 20 人团队和 500 人团队的瓶颈位置完全不同。下面这组对比来自我参与的 9 个团队样本（2022-2024），做了脱敏与归一化处理，可以当作参照基准。

这张表最值得看的是最后一列。团队规模每上一个台阶，有效的干预手段就往上移一层：小团队改输入，中团队改可见性，大团队改承诺结构。很多组织失败的原因是，用 20 人团队的方法管 500 人团队的问题，于是天天开会同步，却始终没有解决依赖登记这件事。

三、拆解五个常见误区

下面这五个误区，我在不同公司反复见到。它们的共同点是：看上去都很合理，甚至在某个阶段确实有效，但一旦团队规模过了 100 人，就会从“有效”变成“有害”。

1. 误区一：人天 = 人力 ÷ 天数

这是最基础也最顽固的一个。它的隐含假设是：人是可以被完整切分的、任务是可以无损并行的、沟通成本为零。

三个假设全错。人是不能被完整切分的（一个人同时做三个需求，切换成本会让总产出下降 20%-40%）；任务并行有上限（同一链路上的任务强行并行只会增加返工）；沟通成本随人数呈平方增长。

正确的做法是先算容量，再算需求。容量是分母，需求是分子，先确认分母的真实值，再去讨论分子怎么切。

2. 误区二：排得越细越可控

我见过最精细的排期表，精确到每人每天的任务。结果是：这张表在排完的第二天就失效了，然后团队花更多时间去维护它，而不是交付。

排期精度存在一个收益拐点。根据我的观察，当排期粒度细于 2 个工作日时，维护成本的增长速度超过它带来的可控性收益。原因很简单：越细的计划，被现实打断的概率越高；被打断后需要重排的面越大；重排本身又要消耗协调成本。

比较健康的做法是双周滚动 + 季度承诺两级结构。季度层面只承诺“交付哪些需求”，双周层面才细化到“这周谁做什么”。前者稳定，后者灵活。

3. 误区三：优先级靠开会投票

优先级会议最常见的结局是：所有 P0 都保留，P1 砍掉两个，P2 全部延期。因为投票机制下，每个人都会为自己负责的需求争取，而“砍掉”的代价由别人承担。

我的判断是：优先级不应该被“讨论”出来，而应该被“约束”逼出来。先定死容量上限（比如本季度最多 380 人天），再让所有需求按价值密度排序，排到 380 人天就停。剩下的自动进入下季度，不需要任何人做“砍掉”的道德决策。

这个机制的妙处在于：它把冲突从“人与人”转移到了“需求与容量”之间。会议性质从谈判变成了排序。

4. 误区四：资源冲突靠加人解决

布鲁克斯法则说的是“向进度落后的项目增加人力，只会让它更落后”。这句话在跨部门场景里更成立，因为新增的人需要被现有的人带，而现有的人正是瓶颈。

我在一个 200 人研发组织里做过测算：临时增加 6 名工程师支援一个延期项目，前 3 周团队总产出反而下降约 8%，第 6 周才回到原水平，第 9 周才体现出净增益。而那个项目的延期窗口只有 4 周。加人救不了 4 周内的火，只能救 3 个月后的产能。

5. 误区五：有看板就等于有数据分析

这是最近几年最普遍的错觉。工具上线了，燃尽图、累积流图、工时报表都有了，于是团队认为“我们已经在做数据驱动的排期了”。

但看板回答的是“现在是什么状态”，排期需要回答的是“未来会是什么状态”。前者是观测，后者是预测。要做预测，你至少需要三样东西：历史周期时间的分布（不是平均值）、依赖关系的登记数据、以及变更记录。缺了任何一样，看板就只是装饰。

四、专业判断逻辑：三本账 + 一个节奏

把上面的误区反过来，就是一套可落地的流程。我把它总结成“三本账 + 一个节奏”：需求账管输入，容量账管分母，依赖账管瓶颈，节奏管颗粒度。四者缺一不可，缺了任何一个，另外三个都会失真。

1. 第一本账：需求账（管输入质量）

需求账的核心不是“记录需求”，而是给每个需求定义一个可验证的完成条件。没有完成条件的需求，不应该进入资源评估环节。

我在实践里用的准入清单只有五条，超过五条就没人认真填了：

1. 业务目标：这个需求上线后，哪个指标会变化，变化多少？
2. 验收标准：如何判定“做完了”？给出可检验的描述。
3. 依赖清单：需要哪些团队/系统提供什么，什么时候需要？
4. 影响范围：涉及哪些模块、哪些数据、哪些下游？
5. 不做的后果：如果这个季度不做，会发生什么？

第五条最容易被忽略，但它是最有效的排序依据。凡是答不出“不做的后果”的需求，通常也不值得占用容量。

（1）需求账的字段设计

字段设计的核心原则是：每个字段都必须有人用它做决策。如果一个字段填了但没人看，它就会在三个月内变成垃圾数据。

最小字段集建议是：需求 ID、业务目标、验收标准、估算区间（P50/P85）、依赖方、需求方接口人、承诺层级（季度/双周）、状态、阻塞原因码。其中“阻塞原因码”是被低估最严重的一个字段，它是你后面定位瓶颈的唯一数据来源。

（2）阻塞原因码怎么设

不要用自由文本，用枚举。我通常设 8 个：等接口文档、等上游数据、等环境、等评审、等排期空档、技术方案未定、需求变更、外部依赖不可控。每周统计一次分布，你就能看到瓶颈在哪。

一个真实的发现：某团队连续 6 周的阻塞原因分布里，“等环境”始终占 30% 以上。他们一直以为是人力不足，实际上是测试环境只有 2 套而项目有 7 个。加人没用，加环境一周就解决了。

2. 第二本账：容量账（管分母真实性）

容量账要按月维护，按周校正。它的结构是“名义容量 → 扣减项 → 有效容量 → 已占用 → 剩余可用”。

关键在于区分三种占用：已承诺（必须做）、预留（变更缓冲）、可用（可排新需求）。我的经验值是变更缓冲应占总有效容量的 15%-20%。低于 15%，一次紧急插入就会打乱整季；高于 25%，说明你的估算体系本身偏保守，需要校准。

3. 第三本账：依赖账（管瓶颈位置）

依赖账是跨部门排期里最被低估的一本账。它的形式很简单：一条依赖一行，包含提供方、接收方、依赖内容、需要时间、承诺时间、实际交付时间、状态。

它的价值在于把“口头承诺”变成“可追踪记录”。我见过太多团队，依赖在群里说了一句“下周给你”，然后三周后双方都记不清当时说的是哪一周。依赖一旦不被登记，它就一定会在关键路径上制造意外。

4. 用 P50/P85 分布替代平均值

平均值是排期里最具欺骗性的统计量。假设某类需求的历史周期是 3、4、4、5、6、7、8、9、12、30 天，平均值 8.8 天。但你按 8.8 天承诺，成功率不到 60%，因为有长尾。

正确做法是看分布的分位数。上面这组数据的 P50 是 6.5 天，P85 是 12 天。对内排布用 P50，对外承诺用 P85，这就是一个可解释的区间。

具体怎么算，一段脚本就够了：

import statistics
def cycle_time_band(samples):

"""samples: 历史同类需求的周期时间（工作日）列表"""

s = sorted(samples)

n = len(s)

p50 = statistics.median(s)

线性插值法取 P85

idx = 0.85 * (n - 1)

lo, hi = int(idx), min(int(idx) + 1, n - 1)

p85 = s[lo] + (s[hi] - s[lo]) * (idx - lo)

mean = statistics.mean(s)

return {"n": n, "P50": round(p50, 1), "P85": round(p85, 1), "mean": round(mean, 1)}

示例：某类需求近 12 次的实际周期

data = [3, 4, 4, 5, 6, 7, 8, 9, 12, 14, 21, 30]

print(cycle_time_band(data))

{'n': 12, 'P50': 7.5, 'P85': 15.8, 'mean': 10.2}

注意这里的差距：均值 10.2 天，P50 是 7.5 天，P85 是 15.8 天。如果你用均值做承诺，实际准时率大概只有 58%；用 P85 做承诺，准时率能到 85% 左右。同一个团队、同一批数据，只是换了个口径，兑现率就能提升 25 个百分点以上。

（1）样本量不够怎么办

样本少于 8 个时，分位数不稳定。这时候用“类比法 + 系数修正”：找一个结构相似的已有需求类别，取其 P85，再乘以难度修正系数（通常 1.2-1.6）。同时明确标注“低置信度估计”，在排期表里单独标记，避免它被当成确定承诺传导出去。

5. 节奏：季度承诺 + 双周滚动

排期节奏决定了这套流程能不能活下来。我的建议是两级：

• 季度层：承诺需求清单 + 总容量分配 + 关键依赖锁定。只做一次，变更需走正式流程。
• 双周层：具体任务拆分 + 人员分配 + 依赖对账。每两周重排一次，允许 20% 的调整空间。

这个结构的价值在于：它把“稳定性”给了外部（季度承诺可预期），把“灵活性”留给了内部（双周可调整）。如果只有季度，团队会被僵化的计划绑死；如果只有双周，外部永远拿不到可靠承诺。

6. 变更预算：让承诺兑现率可被管理

没有任何流程能消灭变更。所以不要试图阻止变更，而是给它一个预算。我通常建议每季度预留 15%-20% 的有效容量作为变更缓冲，所有插入需求都从这里出。

缓冲用完之后怎么办？两个选项：要么砍掉等量的已承诺需求（并对外同步），要么明确拒绝新需求。最糟的做法是“先接了再说”，那等于把变更成本转嫁给交付质量。

五、案例观察：一套流程在 300 人组织里的六个月

抽象的方法论落到具体组织里，会变形。我想用一个相对完整的案例说明这套流程怎么跑起来，以及它在工具层面需要什么支撑。这里以 PingCode 为例，因为它主要服务中大型企业及 100 人以上组织，需求池、迭代、工时、依赖关系、度量报表这些环节在一个系统里闭环，比较适合做跨部门排期的载体。

1. 起点：三个数字都很糟

这家公司约 300 人，研发 180 人，分 6 个团队，同时支撑 3 条产品线。介入前的基线数据是：承诺兑现率 61%、跨部门等待占比 26%、需求返工率 18%、每周排期相关会议耗时约 6 小时/人。

他们当时的状态很有代表性：需求散在三个地方（邮件、聊天工具、需求文档），工时靠 Excel 汇总，依赖关系靠人脑记忆，排期会的主要工作是“对齐大家记的是不是同一件事”。

2. 第一步：把需求收敛到一个池子，并强制准入

第一件事不是排期，是收敛。所有需求进入统一需求池，且必须填齐前面说的五项准入信息才能进入评估。这一条执行了四周，需求池从 470 条清洗到 280 条，其中 190 条因为“说不清不做的后果”被关闭或合并。

这一步的副作用很直接：需求返工率从 18% 降到 12%。因为大量模糊需求在准入阶段就被挡掉了，而不是在开发阶段返工。

3. 第二步：建容量池，而不是按人分配

他们没有按“每个人做多少”来排，而是建了 6 个团队容量池 + 3 个共享资源池（测试、数据、设计）。每个池子按月维护有效容量，扣减项公开可见。

关键设计是：共享资源池必须显示“已占用比例”。当测试池的占用率达到 92% 时，任何新需求排进去都会自动触发提示。这个提示改变了排期会的对话方式，从“我觉得测试能挤一挤”变成“测试池只剩 8% 余量，要么延期要么加资源”。

4. 第三步：依赖登记 + 接口人制

所有跨团队依赖必须登记成条目，包含提供方、需要时间和承诺时间，且每条依赖必须有一个具体的接口人，不能是“某团队”。

这一步的效果最明显：跨部门等待占比从 26% 降到 14%。原因不复杂，依赖一旦被写下来并指定了人，它就从“大家的事”变成了“某个人的事”。而“大家的事”在组织里通常等于“没有人的事”。

5. 第四步：用度量报表替代人工统计

他们把周期时间、吞吐量、阻塞原因分布、承诺兑现率做成固定报表，每周自动生成。原来每周 6 小时的排期会议，压缩到 2 小时以内，因为大量“我们对一下数据”的环节被报表替代了。

这里有个细节值得说：他们最初想看“人均产出”，试了两周就放弃了。原因是人均产出在不同团队之间不可比（需求复杂度差异太大），而且它会诱导团队挑简单的活。最终保留的指标是团队级的吞吐量和周期时间分布，这两个指标既可比，又不诱导拆分需求。

6. 六个月后的数据

下面这组数据是六个月前后的对比，属于该组织的实际观测值（已脱敏）。它不是行业基准，但可以作为量级参照。

值得注意的一个反直觉点：他们没有增加任何人力，交付需求数反而上升了 11%。增量全部来自等待时间的压缩和返工的减少。这也印证了前面的判断，跨部门团队的产能瓶颈，大部分时候不在人的数量上。

7. 一个反例：只上工具不改流程的团队

同期我还看到另一个 260 人的团队，采购了同一套工具，做了完整的字段配置和看板设计，但八个月后承诺兑现率只从 63% 提升到 66%。

原因很清楚：他们把工具当成了“记录系统”，而不是“约束系统”。需求池还是可以随便塞、依赖还是选填、工时还是事后补录、排期会还是靠讨论定优先级。工具把流程固化了，但如果流程本身是空的，固化下来的就是空的流程。

这个反例的价值在于：它划出了工具能解决和不能解决的边界。工具能解决的是可见性、可追溯、统计成本；工具不能解决的是准入标准、容量约束、优先级规则，这些必须是管理动作。

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

方法论必须按团队现状裁剪。下面按四种典型情况给出具体动作，你可以直接对号入座。每一条都标注了“先做什么”和“暂时不要做什么”，因为错误的顺序往往比不做更糟。

1. 20-50 人团队：先修输入，别建体系

这个阶段的团队，排期不准的根因 80% 在需求准入。我的建议是：

• 先做：统一验收标准模板，要求每个需求写清“怎么算做完”。
• 先做：把排期粒度定在周，不要细到天。
• 先做：每周记录一次阻塞原因，用枚举值。
• 别做：不要建复杂的工时体系，20 人团队填工时的成本高于收益。
• 别做：不要引入多层审批，会直接杀死交付速度。

这个阶段的目标是把承诺兑现率做到 80% 以上，通常 6-8 周能做到。

2. 100-300 人团队：先建容量池，再谈排期

到了这个规模，共享资源开始成为主要瓶颈。动作顺序是：

1. 梳理共享资源清单（测试、环境、数据、设计、架构），明确每个池子的有效容量。
2. 为每个池子建立占用率视图，超过 85% 时触发预警。
3. 需求排期改为“排池子”而不是“排个人”。
4. 引入 P50/P85 双口径，对外承诺统一用 P85。
5. 设立 15%-20% 的变更缓冲。

这个阶段最容易被跳过的是第 1 步。很多团队直接开始排期，结果排了三个月才发现测试资源只有名义值的 40%，前面所有的计划都要重做。

3. 300-800 人团队：依赖台账是核心工程

这个规模的组织，跨部门依赖已经是主要矛盾。核心动作是建立依赖台账 + 接口人制 + 联调窗口前置。

具体做法：所有跨团队依赖必须在需求进入排期前登记，每条依赖指定一个具体的人（不是团队），承诺交付时间必须精确到周。每周做一次依赖对账，只对“本周到期”和“已逾期”的条目，15 分钟能完成。

联调窗口前置的意思是：不要把联调排在开发末尾，而是在排期时就把联调窗口锁死在一个具体日期，双方团队都把它当成硬约束。这一条能消掉大量“开发完了但联不上”的隐性等待。

4. 800 人以上：承诺分层，避免信息失真

超大组织的核心问题不是排期不准，而是承诺在传导过程中被逐层乐观化。解决方案是分层承诺：

• 团队层承诺“做什么”，用 P50 口径，允许调整。
• 产品线层承诺“什么时候有什么”，用 P85 口径，需要审批才能改。
• 公司层承诺“对外交付日期”，只在 P85 且依赖全部锁定时才允许给出。

关键规则是：上一层只能引用下一层的 P85，不能引用 P50，更不能引用口头估计。这条规则一旦被破坏，整个承诺体系就失效了。

5. 从 0 到 1 的 30 天落地清单

如果你现在就要动手，这四周的顺序是我验证过比较稳的：

四周之后不要急着优化，先用新流程跑完一个完整季度，拿到至少 6 个双周期的数据，再校准你的 P85 系数。没有数据之前的任何“优化”，都只是换一种猜测方式。

七、不同情况下的取舍

所有流程设计本质上都是取舍。这一节我想把五个最关键的取舍点讲清楚，因为大部分团队不是不知道方法，而是在这些取舍上做了错误的选择，然后一路错下去。

1. 精度 vs 速度：排期该多快给出

一个需求从提出到拿到排期答复，应该控制在 3 个工作日内。超过这个时间，业务方就会开始绕过流程找关系，流程就废了。

这意味着你必须接受“排期时信息不全”。我的做法是：用区间 + 置信度标签来换取速度。可以在 3 天内给出“P50 12 天 / P85 20 天，置信度中等，待接口确认后更新”，而不是花两周做精确估算再给一个数。

取舍原则：早期给区间和置信度，后期给确数和承诺。反过来做（早期给确数、后期改口）会严重损害流程公信力。

2. 透明 vs 政治成本：数据要不要全公开

数据透明会带来两个后果：好处是瓶颈无处藏身，坏处是会引发部门间的相互指责。我见过团队因为公开了“等待归属部门”报表，导致两个部门负责人关系恶化。

我的建议是分级公开：过程数据对管理层和接口人全透明，对全员只公开团队自身的指标。也就是说，A 团队能看到自己的等待占比，但看不到 B 团队的；管理层能看到全部。

取舍原则：透明是为了改进，不是为了追责。一旦数据被用于考核，它就会立刻失真，这是所有度量体系的铁律。

3. 标准化 vs 团队自治：字段要不要统一

统一字段的好处是能横向对比、能汇总分析；坏处是会抹平团队差异，且增加填写负担。我见过一个组织强行统一了 40 个字段，结果三个月后 60% 的字段是空的或填的默认值。

我的判断是：只统一“用于跨团队决策”的字段，其余交给团队自定。跨团队决策需要的字段其实很少，需求 ID、状态、承诺层级、依赖方、阻塞原因、承诺/实际交付时间。这六个够了。

取舍原则：统一决策字段，放开过程字段。

4. 集中排期 vs 分散排期：谁来拍板

集中排期（一个委员会统一分配资源）的好处是全局最优，坏处是决策慢、离一线远。分散排期（各团队自己排）的好处是快、贴近实际，坏处是资源冲突无人协调。

我倾向于“容量集中定、需求分散排”：由管理层集中确定每个池子的容量上限和优先级规则，具体的需求排序和人员分配交给团队。这样既保证了资源分配的全局性，又保留了执行的灵活性。

取舍原则：约束集中，执行分散。

5. 自建 vs 采购：工具怎么选

100 人以下，用现成工具即可，自建不划算。100-300 人，选能覆盖需求池、迭代、工时、依赖、度量五个环节的一体化平台，避免多工具拼接导致的数据割裂。300 人以上，通常需要在标准平台上做二次配置甚至集成自建报表。

选择时的三个硬性判断标准，比功能清单有用得多：

1. 依赖关系能不能被建模：不是写在描述里，而是作为独立实体，能查、能统计、能设提醒。
2. 容量视图能不能按池子看：不是按人看工时，而是按资源池看占用率。
3. 历史数据能不能支撑分位数计算：报表能不能输出周期时间的分布，而不只是平均值。

这三条如果不满足，工具再漂亮，也只是把 Excel 换了个皮肤。以 PingCode 这类面向中大型组织的平台为例，它在依赖关系和度量报表上的建模能力，是决定它能不能承载这套流程的关键，而不是看它的界面有多少个视图。

结语：排期能力本质是组织的信息能力

写到这里，我想回到开头那句话：“我们排的是人力，卡的是依赖。”这句话的真正含义不是“依赖比人力重要”，而是，排期流程的质量，取决于组织能把多少隐性信息变成显性数据。

依赖在谁手里、环境什么时候空出来、这个估算的置信度有多高、上次类似需求实际花了多久，这些信息如果只存在于人的记忆里，排期就只能靠猜；一旦它们被写下来、被统计、被回溯，排期就变成了计算。

我见过的最好的排期团队，不是估算最准的团队，而是最愿意承认自己估不准、并且用数据和缓冲来管理这种不准的团队。他们把不确定性当成一个需要被管理的对象，而不是一个需要被掩盖的缺陷。

如果你想现在就开始，我建议的顺序是这三步：这周先把手上所有需求按“有没有可验证的验收标准”过一遍，把说不清的那批挑出来；下周统计一次团队的真实有效容量，用扣减法而不是加法；再下周，把最近 10 个已完成需求的周期时间拉出来，算出 P50 和 P85。三周之后你会得到一组让你不太舒服但非常有用的数字，那才是真实排期的起点。