资源评估怎么做？项目成员制度设计：需求排期从0到1

去年冬天，我陪一家做工业软件的公司复盘他们一个延期了 11 周的大版本。会上吵得最凶的不是技术方案，而是"当初这个排期到底是谁拍的"。产品负责人说研发答应了 6 月交付，研发负责人说他当时只说了"争取"，项目经理翻出甘特图，发现每一行任务都排到了 100% 负荷，中间一个缓冲都没有。三方都没有说谎，但三方的记忆都对不上，因为整个过程里根本没有一份可以被追溯的资源评估。

这件事几乎是我过去两年做排期咨询时反复遇到的剧本。团队并不缺工具，缺的是一套从"人能干活的时间"到"需求能排进去的顺序"之间的规则。这套规则的正式名字叫项目成员制度设计，落到日常就是资源评估与需求排期。它看起来是项目管理问题，实际是组织效率问题，而且是从 0 到 1 最难建的那一类制度，因为它同时触碰了三群人的利益：产品想要更多，研发想要更稳，管理层想要更可预测。

下面这篇内容，我会把我自己踩过的坑、在 6 家 100 人以上研发组织里拿到的样本数据、以及一套可以直接照抄的制度框架完整写出来。包含公式、参数、准入清单、报表口径和不同规模下的取舍。你可以把它当成一份排期制度的施工图。

一、结论先行：资源评估的产出是一份带区间的承诺

我先把结论讲清楚，再解释为什么。因为大部分团队一开始就把目标定错了，后面再怎么努力都是错的方向。

1. 资源评估的对象是"人 × 时间 × 专注度"的切片

第一个结论：资源评估的单位不是"人"，而是"可用人天"。一个 12 人的研发小组，一个 20 个工作日的迭代，账面产能是 240 人天。但我几乎没有见过任何一个团队能真的交付 240 人天的工作量，实际能排进计划的通常在 130 到 150 人天之间，占比 55% 到 62%。

差额去哪了？休假和法定节假日吃掉一部分，各种评审会、周会、汇报、招聘面试吃掉一部分，线上问题和技术支持吃掉一部分，最后还有一块最容易被忽略的：上下文切换。一个人上午写代码、下午救线上、晚上回邮件，他的有效编码时间远小于 8 小时。这些损耗不是管理不善，是组织的固有摩擦，但它们必须被显式地写在产能账本上，而不是藏在"大家努力一下"里。

把 240 当分子去除需求总量，是所有排期崩塌的起点。这不是估算能力问题，这是口径问题。

2. 需求排期的本质是排队系统

第二个结论：排期不是除法，是排队。除法的假设是任务可以无限切分、可以完美并行、切换零成本；排队的现实是任务有依赖、并行有损耗、切换有代价。当你把团队利用率推到 90% 以上，等待时间会以非线性方式爆炸，这在排队论里有个很朴素的解释：利用率越接近 100%，队列长度越接近无穷。

我在实践中用的经验阈值是：团队长期利用率不要超过 80%，最好控制在 70% 到 75%。剩下的 20% 到 30% 不是浪费，是系统吸收波动的能力。一个常年跑在 95% 利用率的团队，看起来效率很高，实际上任何一次线上故障或一个紧急需求，都会让整个季度的承诺连环违约。

3. 从 0 到 1 的建设顺序不能颠倒

第三个结论：制度建设的顺序比制度本身更重要。大部分团队一上来就开排期会，结果会开成了争吵会，因为前置条件全都不具备。我的建议顺序是：

1. 第一步，颗粒度标准化：定义什么叫"一个需求"，多大的需求才有资格进入排期。没有这一步，估出来的数字互相不可比。
2. 第二步，产能账本：把名义工时折算成可用人天，形成每个团队、每个月的固定分母。
3. 第三步，准入闸门：定义需求进入排期前必须满足哪些条件，谁有权判定。
4. 第四步，承诺与缓冲机制：明确承诺的是区间还是点值，缓冲放在哪里，谁有权动用。
5. 第五步，才是排期会：会议只做三件事，确认约束、切需求、记录假设。不做估算，不做技术方案讨论。

跳过前三步直接开第五步，是我见过最常见的失败模式。会议照开，决议照出，但每次都要重新吵一遍，因为没有一个双方都认的分母和分子。

二、真实场景：三次排期崩塌的完整复盘

抽象结论讲完，我讲三个具体的崩塌现场。这三个场景按时间顺序发生在我参与的不同项目里，每一个都对应一类制度缺失，也对应后面章节的一个解法。

1. 第一次崩塌：240 人天的幻觉

那是 2022 年一个 14 人的团队，要做一个行业 SaaS 的 2.0 版本。产品把需求清单拉出来，一共 68 条，自己估了总量约 520 人天。项目经理一算，14 人 × 3 个月 ≈ 840 人天，看起来绰绰有余，于是承诺 3 个月交付。

实际结果：第 6 周就有 40% 的需求没动，第 10 周团队开始周末加班，第 14 周交付了大约 55% 的功能，剩下 45% 里有一半被砍。事后复盘，真实可用的产能是 402 人天，只有账面值的 48%，而需求总量在澄清过程中从 520 涨到了 690。分子涨了 33%，分母缩了 52%，乘起来偏差接近 3 倍。

这次崩塌的根因不是估算不准，是分母错了。团队后续做了一件很朴素的事：连续 8 周记录每个人每天的时间去向，分五类，新功能、缺陷、支持、会议、其他。结果和最初的假设差得非常远。

2. 第二次崩塌：需求闸门失守

第二个项目是一个 200 人左右的研发中心，他们有排期会，有估算，有迭代，流程看起来很完整。问题是排期会永远开不完，因为每次会上都会冒出新需求，而且这些新需求往往来自更高层，没人敢说不。

三个月里，进入迭代的需求条目数从每两周 18 条涨到 31 条，同时在制品数量从 12 涨到 27。周期时间随之从 6 天涨到 21 天。团队没有变懒，只是每个人都同时在四五件事之间跳。

根因是准入闸门缺失。没有"什么样的需求才算准备好"的明确标准，需求就会以半成品状态流入，然后在开发过程中反复澄清、反复返工。我后来统计过这个团队的数据：需求描述完整度低于 60% 的条目，返工率是完整度 80% 以上条目的 2.7 倍。

3. 第三次崩塌：缓冲被当成"藏私"

第三个项目最有意思。团队接受了要留缓冲的理念，于是每个任务估算时加 30%，但这些加出来的时间散落在几百条任务里，谁也看不见。结果是：单条任务的完成时间确实变宽松了，但项目整体依然延期。

原因在于散落的缓冲会被各方"就地消耗"。开发觉得这条任务时间宽松，就顺手多做点优化；产品看到时间宽松，就塞个小需求进去；到了项目末期，缓冲早就被吃干净了，而关键路径上的风险一点没减少。

缓冲必须集中管理，不能分散发放。这是关键链方法最核心的一条，也是我在实践中最坚持的一条：估算按 50% 概率的乐观值给，把聚合出来的缓冲放在项目层或资源池层，由一个人统一看管，动用需要理由。

4. 六家组织的样本观察

2023 到 2024 年，我完整跟进过 7 家 100 人以上研发组织的排期改造，其中 6 家能拿出连续三个季度的完整数据。以下是脱敏后的汇总观察，样本量不大，但方向相当稳定，供你作为参照基准而不是绝对结论。

这张表里我最想让你注意的是最后一行。利用率从 93% 降到 74%，按期交付率反而从 41% 涨到 78%。这违反直觉，但完全符合排队规律：少做一点并行，换来的是等待时间和返工的显著下降。很多管理者不敢做这个交换，因为它看起来像"降低了效率"。

三、拆解误区：八个把排期做废的动作

下面这八个误区，是我在复盘会上出现频率最高的。它们的共同点是：单看每一步都很合理，组合起来就是一个必然延期的系统。

1. 用总人天除以人数得出工期

这是最经典也最难根除的一个。520 人天的需求，14 个人，所以 37 个工作日，看起来天衣无缝。但需求之间有关系，人之间有依赖，合并处有集成成本。把一个可以并行的任务拆给 5 个人，实际耗时不等于五分之一，通常在三分之一到二分之一之间。

正确的做法是：先按模块和依赖关系画出关键路径，只对关键路径做工期累加，非关键路径用资源平衡去填充。排期的最小单位应该是一条链路，而不是一个总数。

2. 把 100% 时间算作可用产能

这一条在上一章已经用数据拆过了，这里补充一个判断标准：如果你算出来的可用产能超过名义工时的 75%，说明你的账本是假的。任何超过这个比例的测算，都需要拿出时间记录来证明。

我的经验区间是：稳定运行的成熟团队 60%，70%，有新成员加入或系统不稳定时 45%，55%，纯维护型团队可以到 75%。这个区间不是拍出来的，是时间去向记录跑出来的。

3. 让"最懂的那个人"估所有的活

技术负责人一个人估全部任务，短期看效率最高，长期看是组织能力的黑洞。首先，单点估算有系统性偏差，乐观的人估出乐观的数，谨慎的人估出保守的数，而你无法校准。其次，估算过程本身是团队理解需求的过程，跳过它等于跳过了共识建立。

我倾向的做法是：由执行者估，由团队校准，由历史数据纠偏。三条腿缺一不可。执行者估保证承诺感，团队校准消除个体偏差，历史数据提供客观刻度。

4. 把故事点当工期用

故事点是相对规模的度量，不是时间。一个 5 点的需求在 A 团队可能是 3 天，在 B 团队可能是 8 天。它的设计目的就是跨团队不可比，从而避免被拿来当 KPI。一旦你把故事点换算成工期写进合同或承诺，这个工具就废了。

如果管理层需要时间承诺，正确的做法是用团队自己的历史吞吐量做换算：这个团队过去 6 个迭代平均每个迭代完成 42 点，那么 120 点的需求大约需要 3 个迭代，并给出 P50 和 P85 两个置信区间。

5. 需求没准备好就进排期

半成品需求进入开发的代价极高。我统计过一个 300 人研发中心的数据：需求描述中被开发追问超过 3 次的条目，平均交付周期是追问 0 次条目的 1.8 倍，返工率是 2.4 倍。

很多人以为这是开发在挑刺，其实是需求本身缺少可验证的验收条件。没有验收条件，开发就只能按自己的理解做，做完必然返工。准入闸门不是流程装饰，它是返工率的主要控制点。

6. 相信"加人能加速"

布鲁克斯定律讲了五十年，但每个季度还是有人在用。新人加入一个正在交付的项目，前两周产出接近于零，第三到第六周是负产出，因为他要占用老成员的时间。真正开始贡献通常在第 6 到第 10 周。

加人只对一种情况有效：项目还有 3 个月以上的剩余工期，且新加入的模块边界清晰、可以独立交付。否则加人就是加速延期。

7. 一次把容量排满 100%

排满意味着系统没有任何吸收波动的能力。一次线上故障、一个监管需求、一个核心成员离职，都会让整条计划链断裂。而断裂之后团队会做什么？会重新排一次，然后把新的计划再排满，进入下一轮循环。

我建议的分配比例是：70% 用于已承诺的版本需求，20% 用于缺陷与支持，10% 作为机动池。机动池由一个人统一调度，用了要记录，季度末复盘用了多少、用在哪。

8. 把排期当成一次性事件

排期是一个持续的重排过程，不是一次会议的输出。需求会变，人会走，系统会出问题，三个月前算出来的计划必然失效。真正有效的不是那份计划，而是那套在计划失效时能快速重排的机制。

我们的做法是固定节奏：每两周做一次轻量重排（30 分钟，只看约束变化和新增插入），每季度做一次资源池级别重排（2 小时，看容量分配和人员配置）。计划本身是滚动的，承诺只在当前迭代内有效。

四、专业判断逻辑：四层模型与可运行参数

讲完误区，讲我实际用的框架。我把它叫四层模型：容量层、需求层、约束层、缓冲层。这四层的顺序不能颠倒，因为上一层是下一层的输入。

1. 容量层：算出可信的分母

容量层的目标是回答一个问题：这个团队在下个月到底有多少可用人天？公式如下：

可用人天 = 名义工时 × 出勤系数 × 专注系数 × 有效投入系数
名义工时 = 人数 × 工作日数

出勤系数 = 1 – (年假 + 病假 + 法定假) / 全年工作日 → 通常 0.90 – 0.94

专注系数 = 1 – (会议 + 汇报 + 面试) / 有效工时 → 通常 0.68 – 0.78

有效投入系数 = 1 – (支持 + 救火 + 切换损耗) / 有效工时 → 通常 0.80 – 0.90

示例：12 人 × 20 天 × 0.92 × 0.72 × 0.86 ≈ 137 人天

这三个系数不要抄我的数，要用你自己的时间去向记录跑出来。记录方式可以极简：每人每天在五类里选一个主分类，坚持 8 周。8 周的数据足够稳定，成本也足够低，比任何估算方法论都值得先做。

2. 需求层：统一颗粒度

颗粒度不统一，估算就不可比。一个 3 天的需求和一個 30 天的需求放在同一张清单里排序，排序结果一定是错的，因为大需求永远排在后面，永远做不完。

我用的分层标准是这样的：

• 史诗（Epic）：1 个季度以上的工作量，只在路线图层出现，不进入排期。
• 特性（Feature）：2 到 6 周，是资源分配的基本单位，一个特性对应一个明确的价值假设。
• 用户故事（Story）：1 到 5 天，是排期与交付的基本单位，必须能独立验收。
• 任务（Task）：4 小时到 1 天，只在迭代内拆解，不做跨团队估算。

关键规则是：任何超过 10 人天的条目，必须在进入排期前拆到 10 人天以内。这条规则会强迫产品在提交前想清楚边界，也会让估算偏差大幅收窄。我服务过的一个团队执行这条规则后，估算偏差的中位数从 58% 降到 23%。

3. 约束层：找到真正的瓶颈

资源评估最容易犯的错，是假设瓶颈在"人不够"。实际上瓶颈可能在一个特定的角色（比如只有 1 个安全工程师、2 个 DBA），可能在一个环境（只有一套联调环境），也可能在一个外部依赖（第三方接口审批要 3 周）。

判断瓶颈的方法很简单：看队列堆在哪里。哪个环节前面的等待队列最长，那个环节就是瓶颈。然后所有资源评估都要围绕瓶颈展开，瓶颈环节的产能才是系统产能，其他环节再快也没用。

我在一个项目里做过这样的调整：团队整体利用率 68%，看起来还有余量，但测试环境排队平均等 4.5 天。把环境扩容之后，整体周期时间从 16 天降到 9 天，团队人数一个没变。那次改造的真实成本是两台服务器，收益是 44% 的周期缩短。

4. 缓冲层：集中管理而不是分散发放

缓冲的位置决定了它有没有用。分散在每条任务里的缓冲会被就地消耗，而且不可观测。集中管理的缓冲有三个层次：

缓冲动用的记录比缓冲本身更重要。每次动用都要写清楚：动了多少、为什么、影响了哪条承诺。季度末看这张表，你会看到组织的风险来源非常集中，通常是两三个反复出现的类型，针对性地解决它们，比再多留缓冲有效得多。

5. 一套可以直接抄的参数起点

如果你现在就要开始，下面这组参数可以作为起点，跑两个季度再校准：

• 可用产能占名义工时：60%（新团队）到 70%（成熟团队）
• 迭代承诺容量：可用产能的 70%
• 缺陷与支持预留：可用产能的 20%
• 机动池：可用产能的 10%
• 单条目上限：10 人天，超过必须拆
• 在制品上限：团队人数的 1.5 倍，且不超过 2 倍
• 承诺口径：给 P50 和 P85 双区间，对外承诺用 P85

这组数字没有魔法，它们的价值在于"有"而不是"准"。一个有共识的粗略参数，胜过一个没有共识的精确参数。因为前者可以被复盘和修正，后者只会在争吵中被抛弃。

五、案例：100，500 人组织如何把排期真正跑起来

前面讲的框架在小团队靠白板和表格就能跑。但组织一旦超过 100 人，多产品线、多项目并行、跨团队资源冲突成为常态，就必须依赖平台承载数据。这个规模区间是最难的：小团队的默契已经不够用，大组织的流程又还没建立，中间这段靠人肉协调会迅速失控。

1. 为什么 100，500 人是最难的一段

这个规模有三个特征。第一，资源池开始跨项目共享，一个人同时属于两个项目组，任何一次排期都要协商。第二，管理层级出现，信息在传递中失真，"研发说尽力"传到上一层就变成"研发承诺了"。第三，历史数据开始积累但还没形成分析能力，报表有一堆，没人看得懂。

我服务过的一家做企业服务的公司，320 人研发，11 个团队，同时在跑 4 条产品线。他们最初的做法是 Excel 排期表 + 每周一次 3 小时的对齐会，结果是：排期表有 7 个版本在流转，没人知道哪个是最新的；对齐会上 70% 的时间在争论"上次说好的是什么"。

这类组织的核心诉求不是"更好的估算方法"，而是"一个所有人看到同一份数据的地方"。这也是我后来在类似规模的客户里，普遍建议用 PingCode 这类面向中大型组织的研发管理平台来承载排期制度的原因，它的定位就是服务 100 人以上、多团队多项目并行的组织，工作项、迭代、版本、工时、负载视图和报表在同一套数据模型里，不需要在不同系统之间对账。

2. 数据结构怎么搭：三层建模

第一层是工作项统一建模。需求、任务、缺陷、子任务用同一套工作项体系承载，通过类型区分，而不是分散在几个模块里。这一步决定了后面所有报表能不能聚合。

第二层是承诺分层。用迭代承载"两周内的确定承诺"，用版本或发布计划承载"季度内的方向承诺"，用路线图承载"半年以上的意图"。这三层的变更成本依次递减，谁想改哪一层，就要走哪一层的流程。

第三层是属性标准化。每条需求必须填规模（人天）、优先级、所属产品、所属团队、验收条件五个字段，缺一个就不允许进入排期状态。这一步靠必填项和状态流转规则来强制，不靠自觉。

3. 容量视图与负载预警

容量视图要解决的核心问题是：让超载在排期前就可见，而不是在延期后才发现。具体做法是把每个成员在每个迭代的计划工时汇总成负载率，超过 100% 标红，低于 50% 标黄。

我们在 PingCode 里给客户配的一套规则是这样的：负载率超过 110% 时自动给团队负责人发通知，超过 130% 时阻断迭代启动。这条阻断规则一开始被强烈反对，运行两个季度后，反对声消失了，因为它把"能不能排进去"从人情问题变成了规则问题。

另一个有用的视图是跨项目资源占用。一个后端工程师同时被三个项目组排了活，单看每个项目都合理，合起来是 180%。这个视图必须做在项目之上，否则永远看不到。

4. 准入闸门：把返工率控制在入口

准入闸门的具体形式是一份检查清单，通常 7 到 9 条，全部满足才能从"待评审"流转到"已就绪"。我们给客户配的默认清单是这样的：

1. 有明确的目标用户和使用场景描述
2. 有可验证的验收条件，至少 3 条
3. 已拆分到 10 人天以内，且依赖关系已标注
4. 已明确不做什么（范围边界）
5. 涉及外部依赖的，依赖方已确认时间
6. 涉及数据变更的，已评估迁移方案
7. 已确认不需要法务/安全额外评审，或已完成评审
8. 原型或交互稿已定稿
9. 规模已由执行者估算并团队校准

这九条里，最有杀伤力的是第 3 条和第 4 条。第 3 条强迫拆分，第 4 条强迫想清楚边界。我见过太多需求，做了一半才发现"其实我们不需要做这么多"，而这时候沉没成本已经产生。

5. 报表基线：用累积流图和吞吐量替代甘特图

甘特图适合表达计划，不适合表达现实。管理层真正需要的是三个东西：我们交付得多快（吞吐量）、交付一件要多久（周期时间）、现在堵在哪里（累积流图）。这三个指标都可以从工作项状态流转数据里自动生成，不需要额外填报。

我通常会要求客户做到一件事：每次排期承诺时，附上过去 6 个迭代的吞吐量均值、标准差和 P85 值。用这三个数去反推承诺，比任何估算方法论都可靠。因为它是这个团队真实交付能力的历史证据，谁也争不过数据。

6. 六个月后的数据

回到那家 320 人的企业服务公司。改造从第 1 个月的数据统一开始，第 2 个月上容量视图，第 3 个月上准入闸门，第 4 个月开始用吞吐量做承诺，第 5 到 6 个月稳定运行。六个月后的对比数据如下：

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

框架是通用的，落地必须分场景。下面按组织规模和业务形态分五类，给出可以直接执行的动作。

1. 10，30 人团队：先做时间账本，别做流程

这个规模不需要复杂的排期制度，默契和即时沟通的效率高于任何流程。唯一必须做的是时间账本，因为它是所有后续制度的基础数据。

• 让每人每天记录时间主分类，坚持 8 周，用最简单的表格即可
• 算出一张团队的可用产能系数表，写下来贴在显眼位置
• 迭代承诺容量按可用产能的 70% 排，剩下 30% 不排满
• 需求进入开发前必须写清楚验收条件，这一条不能省

这个阶段最该避免的，是照搬大厂的流程。三层评审、五级审批、双周汇报，在 20 人的团队里只会制造摩擦，不产生任何信息。

2. 100，500 人组织：先统数据，再上制度

这是本文重点覆盖的区间，也是最需要平台支撑的区间。我的建议路径是四步：

1. 第 1 个月，数据统一。把需求、任务、缺陷收敛到一套工作项体系，强制五个必填属性，清理历史脏数据。
2. 第 2 个月，容量可见。上成员负载视图和跨项目资源占用视图，先把超载暴露出来，不做任何考核。
3. 第 3 个月，闸门生效。上准入检查清单，先用"软闸门"（提醒）跑一个月，再切"硬闸门"（阻断）。
4. 第 4，6 个月，承诺改造。用历史吞吐量替代逐条估算做承诺，把承诺口径从点值改为 P50/P85 双区间。

像 PingCode 这类平台在这个区间的价值，主要不在功能多，而在于让 300 个人看同一份数据。排期冲突的根源往往是信息不对称，而不是利益冲突。信息对齐之后，很多争吵会自动消失。

3. 500 人以上矩阵组织：先定资源池，再定项目

这个规模的核心矛盾是矩阵双线管理：人属于职能部门，活来自项目。资源评估必须做在资源池层，而不是项目层。

• 按职能划分资源池（前端池、后端池、测试池、数据池），每个池有明确的容量口径和负责人
• 项目不直接占人，而是向资源池申请人天配额，配额按月结算
• 建立配额使用的看板，谁用超了、用在哪，全员可见
• 季度做一次池级别的产能规划，与业务规划对齐

矩阵组织最容易出现的问题是"项目都重要，资源都不够"。解法不是加人，是在资源池层做显式的优先级排序和配额切割，让取舍发生在有决策权的那一层，而不是压到执行层去消化。

4. 项目交付型/外包团队：以合同里程碑为锚

这类团队的特点是范围由合同锁定，变更是收入来源，所以排期制度的重点不是灵活性，而是变更的可计量性。

• 建立需求基线，基线内的变更是内部调整，基线外的变更是合同变更
• 每个变更都要估算人天影响并走书面确认，不确认不排期
• 缓冲比例提高到 40%，50%，因为外部依赖和客户确认周期不可控
• 里程碑承诺必须给区间，且明确区间的依据

我见过最惨的一个交付项目，做了 11 个月的免费变更，最后毛利率是 -18%。根因不是估算不准，是没有变更计量机制，每一次"顺手做一下"都没有被记录。

5. 零数据起步：用两周换一个起点

如果团队现在什么都没有，不要等数据积累，也不要先买工具。先做两周的极简记录：每人每天回答一个问题，今天主要在做哪一类事。两周后你就有了一份初步的产能系数，足以支撑第一次有依据的排期。

然后用这份数据排出第一个迭代，跑完复盘，修正系数，再排第二个。三个迭代之后，你就有了一套属于自己的参数体系，比任何外部模板都可靠。

七、不同情况下的取舍

制度设计的本质是一系列取舍。想把所有好处都拿到，最后一定什么都拿不到。下面六组是我在实践中最常需要做的选择，以及我的判断依据。

1. 精确 vs 快速

精确的估算成本很高。团队共识估算一条 3 人天的需求要 15 分钟，100 条需求就是 25 小时。蒙特卡洛模拟更贵，需要稳定的历史数据和工具支持。

我的取舍原则是：按决策的可逆性分配精度。可逆的决策（下个迭代做什么）用快速估算，错了改就是；不可逆的决策（对外合同承诺、重大资源投入、招聘计划）用高精度方法，值得多花时间。绝大多数团队的错，是在可逆决策上过度精确，在不可逆决策上拍脑袋。

2. 集中排期 vs 分散排期

集中排期（一个排期委员会统一分配资源）保证全局最优，但响应慢、离执行远。分散排期（各团队自己排）响应快、贴近实际，但容易局部最优、全局冲突。

我倾向的折中是：容量在集中层规划，任务在分散层安排。也就是说，"这个季度后端池给 A 项目 60 人天、给 B 项目 40 人天"这个决定在管理层做，"这 60 人天具体做什么、谁来做"在团队层做。分界线画在容量和任务之间，而不是画在项目和人之间。

3. 承诺制 vs 流动制

承诺制给管理层确定性，代价是灵活性。流动制给团队灵活性，代价是可预测性。这两者的取舍取决于你的业务对"确定日期"的依赖程度。

判断标准是：延期一天的代价有多大？如果是内部工具，延期一周没人关心，用流动制；如果是合约交付、市场窗口、监管截止，延期代价极高，用承诺制并配套缓冲。很多团队的问题是把内部工具当合约项目管，把合约项目当内部工具做，两个方向都错。

4. 缓冲放项目 vs 缓冲放资源池

项目缓冲保护单个项目的交付日期，资源池缓冲保护团队不被突发需求击穿。两者的区别是保护对象不同。

我的建议是两个都要，但比例不同。项目缓冲按关键路径的 30%，50% 放在项目末端，资源池缓冲按可用人天的 15%，20% 放在团队月度容量。前者应对项目内的不确定性，后者应对项目外部的插入。只做前者，团队会被外部需求拖垮；只做后者，项目内的风险没人吸收。

5. 制度刚性 vs 例外通道

制度太刚性会被绕过，太柔性等于没有。这个平衡点是所有制度设计里最难找的。

我的做法是：规则刚性，例外显式。规则本身不打折扣（比如"超过 10 人天必须拆"），但允许走例外通道，条件是记录理由、记录批准人、季度复盘时公开。这样既保住了规则的权威，又给了特殊情况出口，而且例外记录本身会成为改进的输入。

实践中有一条经验：如果某个例外在一个季度内出现超过 5 次，说明规则本身有问题，应该改规则而不是继续批例外。

6. 表格自建 vs 平台承载

30 人以下用表格完全够用，成本低、灵活、改起来快。但超过 100 人之后，表格的隐性成本会迅速上升：多版本流转、权限混乱、数据对不上、报表靠人工汇总。

分界线大致在"是否跨团队共享资源"上。如果资源只在团队内部分配，表格够用；一旦出现跨团队、跨项目的人员共享，就需要一个统一的数据源，否则每次排期都要先花两小时对齐"现在到底是什么情况"。这也是为什么 100 人以上的组织通常会用 PingCode 这类平台来承载工作项、迭代、版本、工时和负载视图，不是为了功能，是为了消除对账成本。

但要提醒一句：平台不解决制度问题，它只是把制度固化下来。没有清晰的容量口径和准入标准，上了平台只会让混乱变得更高效。

八、常见问题速答

最后整理几个在咨询里被问得最多的问题，直接给答案。

1. 团队从来没有估算数据，第一次排期怎么做？

不要试图一次做准。先做两周时间记录拿到产能系数，然后用"历史直觉 + 30% 缓冲"排出第一个迭代，跑完立即复盘偏差。前三个迭代的目标不是准，是建立校准机制。第四个迭代开始，你就有自己的数据了。

2. 老板要求给出确定的交付日期，怎么办？

给日期，但同时给条件。表述方式可以是："按当前范围和当前人力，85% 概率在 6 月 20 日前交付；如果范围增加 20%，日期后移 3 周。"这既满足了对方要日期的需求，也把范围和日期的联动关系显式化了。比起硬顶或者硬扛，这是唯一可持续的做法。

3. 需求总是插进来，排期永远被打乱怎么办？

插需求不是问题，免费插需求才是问题。建立插入池（迭代容量的 10%），池内的可以插，池满之后插入必须换出等量的已有需求。让插入有代价，插入的数量会自然下降一半以上。这一条我在四个团队里验证过，效果非常稳定。

4. 估算偏差应该控制在多少算合格？

单个条目的偏差控制在 ±50% 以内就算合格，不要追求更准，成本不划算。真正要控制的是批量偏差：一个迭代的总交付量对比承诺量，偏差在 ±15% 以内是健康水平，超过 ±25% 说明估算体系或者容量口径有问题。个体的不准可以被平均掉，系统性的偏移不能。

5. 要不要做个人维度的产能考核？

不要。个人产能考核会立刻引发三个后果：估算虚高、任务挑肥拣瘦、协作意愿下降。资源评估的颗粒度应该是团队或资源池，个人维度只用于发现明显的负载不均（比如某人长期 130%、某人长期 40%），用于调整分配，不用于评价人。

6. 制度上线后多久能看到效果？

按我的样本观察，产能口径统一后第 2 个月能看到排期会议时长下降，第 3 个月能看到返工率下降，第 5 到 6 个月才能看到按期交付率的明显改善。前两个月的数据通常会变差，因为记录成本增加、旧习惯被打破。这个阶段最容易放弃，需要提前和管理层对齐预期。

写在最后：排期制度的真正产出是共识

回到开头那家工业软件公司。他们后来做的事其实很简单：用两周记录时间去向，算出可用产能系数是 0.58；把需求清单从 68 条拆成 210 条，超过 10 人天的全部重拆；上线了一份 9 条的准入清单；把承诺口径从"6 月交付"改成"85% 概率 7 月中旬交付，范围锁定在当前清单"。

没有引入任何新方法论，没有换工具，没有加人。下一个版本按期交付率从 34% 提到了 79%。真正的变化不是数字，是开会时不再争论"当初谁说的"，而是讨论"这次的假设变了吗"。

我一直觉得，资源评估这件事最大的误解，是把它当成一个计算问题。它其实是一个共识问题：共识什么是可用的时间，共识什么算一个需求，共识什么条件才允许进入排期，共识承诺的是区间而不是点值。计算只能给出数字，共识才能让数字被执行。

如果你准备开始，我建议按这个顺序走三步：

1. 这周就做：拉一个 8 周的时间去向记录表，五类足够，让每个人每天填一次。这是所有事情的起点，成本最低，价值最高。
2. 两周后做：用记录数据算出你们的三个系数，写出第一份产能账本，然后在下一个迭代按 70% 容量排一次，看看会发生什么。
3. 一个月后做：把准入清单定下来（先定 5 条就够），选一个团队试点"软闸门"一个月，再决定要不要推广到全组织。

不要等制度设计完美了再开始。排期制度是在运行中长出来的，不是在设计室里画出来的。你唯一需要先确定的是分母，人到底有多少可用时间。这个数字一旦真实，后面的所有讨论都会变得比现在容易得多。