Capacity怎么做？实施团队制度设计：资源负载从0到1

去年冬天，我陪一家做企业级软件交付的公司做年度复盘。他们有 180 多名实施顾问，分布在 6 个区域，一年同时跑 400 多个项目。复盘会上，交付总监说了一句话，我到现在还记得：“我们不是不知道人不够，我们是不知道人到底够不够。”这句话背后是典型困境：项目在系统里看着都有负责人，实际排期靠微信群接龙，谁的负载满了、谁快爆了，只有项目经理自己心里有数。等到项目延期，追溯起来永远是同一句解释，“资源冲突”。

而所谓“资源冲突”，其实是没有 Capacity 制度的必然结果。这篇文章要讲的，就是实施团队怎么把 Capacity 从 0 做到 1，以及在这个过程中必须同步设计的制度。它不是一张排班表的问题，而是一套关于“谁能承诺、承诺多少、超了怎么办”的规则。

一、先把结论说清楚：Capacity 是制度问题，不是算术问题

很多人第一次做 Capacity，下意识的动作是打开 Excel，列出所有人、所有项目、所有月份，然后开始填格子。填完发现表格很漂亮，但没人用它做决策。原因很简单：表格解决的是“算得出”，制度解决的是“算得算数”。算得出但不算数的 Capacity，只是又多了一份没人看的报表。

1. 核心结论一：Capacity 的第一产物是“承诺”，不是“报表”

Capacity 的本质是对外交付承诺的边界。当销售问“下个月能不能再接一个项目”，当客户问“能不能提前两周上线”，当老板问“再加 20% 的活行不行”，回答这些问题需要一个可被引用、可被追责的数字。

所以判断一套 Capacity 机制是否成立，标准不是表格多精细，而是：有没有人因为引用这个数字而改变过决策。如果销售照样承诺、项目经理照样接活、老板照样加需求，那这套机制就还没真正建立，只是增加了填报工作量。

我在做第一版 Capacity 时犯过的错，就是把 80% 的精力花在了模型精度上。我把折损系数细分到 11 类，做了加权算法，结果第一周就被现实打回来，没人愿意每周花 40 分钟填那张表，数据断供，模型再准也没用。

2. 核心结论二：从 0 到 1 只需要三个数字

0 到 1 阶段，不要追求完整指标体系。你只需要三个数字能在团队里形成共识：

• 这个人这个月还能承诺多少小时，可承诺产能，供给侧的答案。
• 他手上已经承诺了多少小时，已分配负载，需求侧的答案。
• 两者相除得到的负载率，决定了要不要干预、干预到什么程度。

这三个数字能跑通，Capacity 就完成了 0 到 1。剩下的技能维度、跨区域调度、产能预算、成本结算，都是 1 到 10 的事。反过来，一上来就做 10 个指标、5 张报表、3 个看板，大概率在第二个月就没人维护了。

3. 核心结论三：制度必须先解决“谁为超载签字”

这是我见过最多团队卡住的地方。负载超了，谁负责？项目经理说是资源经理排的人，资源经理说是项目经理接的活，销售说客户需求就是这样，老板说你们自己协调。责任不清，Capacity 就一定失真，因为每个人都会倾向于让自己的数字看起来正常。

制度设计的第一个动作，不是定公式，而是定签字权：谁有权把一个 95% 负载的人推到 110%，需要谁批准，批准后由谁承担延期风险。这个问题回答不了，后面所有计算都是自娱自乐。

4. 核心结论四：0 到 1 阶段要做减法，不要做精度

从 0 到 1 的正确姿势是：用一个粗糙但被遵守的模型，替换掉一个精确但不存在的模型。允许 ±15% 的误差，换取每周稳定更新的数据。等数据能稳定跑三个月，再谈精度提升。

我的经验值是：0 到 1 阶段，Capacity 预测误差控制在 20% 以内就算成功，因为这个精度已经足够支撑“接不接这个项目”“要不要外协”这类决策。追求 5% 以内的误差，是把成本花在了不需要的地方。

二、真实场景：实施团队的 Capacity 为什么总是从“拍脑袋”开始

要理解 Capacity 难在哪，得先看清实施团队的工作结构和研发团队有什么不同。研发团队的工作相对集中在一个产品上，需求可切分、迭代有节奏。实施团队面对的是多个客户、多套环境、多种交付形态，工作内容天然碎片化，而且大量时间消耗在“不可见的协调”上。

1. 一个周一早晨的三张表

我调研过的一家交付型公司，周一早晨同时存在三张表：

1. 销售侧的商机预测表，按签约概率排到未来 6 个月，用来预估需要多少实施人力。
2. 交付侧的项目排期表，按合同里程碑倒排，用来回答客户什么时候能上线。
3. 人事侧的人员花名册，记录技能标签和在职状态，用来做调配依据。

三张表各有各的维护人，各有各的更新频率，从来没有对齐过。销售表里的“预计投入 3 人月”和交付表里的“需要 5 人月”，差异从来没人核对。这就是最典型的 0 阶段：数据存在，但没有共同的计量单位。

这种状态下的“资源冲突”不是偶发事件，而是结构性的。因为三张表各自都在优化自己的局部目标，冲突只是被延迟发现而已。

2. 实施团队负载的四种来源

做 Capacity 之前必须承认一件事：实施顾问的工时不是被项目独占的。按我的观察，一个实施顾问的月度时间大致来自四类消耗：

如果排班只覆盖第一类，那么排出来的负载率天然偏低，实际执行时必然超载。我见过一个团队，排班显示平均负载 76%，看起来很健康，但把售后和售前拉进来之后实际接近 104%。这就是“账面健康、体感爆炸”的来源。

3. 我见过的三种“伪 Capacity”

在正式做之前，很多团队其实已经有一版 Capacity 了，只是它不工作。我把它们归成三类：

• 记账型：只有事后工时记录，没有事前承诺。特点是报表很丰富，但所有数字都是过去时，无法支撑决策。本质是成本核算，不是产能管理。
• 意愿型：让每个人自己报“我能不能接”。特点是尊重个人判断，但没人对整体负载负责，最后变成谁好说话谁被塞活。
• 口号型：墙上写着“平均负载不超过 85%”，但没有定义负载怎么算、超了怎么办。特点是开会时人人引用，执行时无人遵守。

三种伪 Capacity 的共同点是：它们都不产生约束力。约束力来自制度，不来自表格。

4. 组织跨过 100 人时的断点

10 个人的时候，谁忙谁闲，团队负责人一抬眼就知道，一张微信群接龙足够。30 个人的时候，开始需要一张共享表，但还能靠记忆补齐。真正出现断点是在 100 人左右：跨区域、跨产品线、跨项目类型，负责人的视野覆盖不到每一个人，靠人脑调度开始系统性失效。

我复盘过一个 120 人的实施组织，他们的排班失误集中爆发在跨区域借调上。本地项目经理只知道本地资源紧张，于是向总部申请支援；总部也不知道被申请的人在外地还有没有隐性承诺，就批了。结果同一个人被两个区域各排了 60% 的负载。

这个断点的本质是：当组织规模超过一个人的信息处理能力，Capacity 必须从“人际协调”升级为“制度协调”。这不是管理水平的进步，而是规模逼出来的必要动作。

三、把误区拆开：五种最常见的 Capacity 错法

做错 Capacity 的团队，往往不是不努力，而是方向从一开始就偏了。以下五种误区，我在过去几年里反复见到，每一种都有明确的识别信号和修正方向。

1. 误区一：把工时填报当成 Capacity

这是最普遍的一种混淆。工时填报是“已经发生了什么”，Capacity 是“还能承诺什么”。前者面向历史，后者面向决策。

识别信号很简单：如果你们团队的排班决策从来不引用工时报表，那么这份工时数据本质上只服务于成本核算和绩效，对产能管理没有贡献。

正确的做法是让两者形成闭环：承诺工时（事前）与实耗工时（事后）之间的偏差，是校准 Capacity 模型的唯一可靠依据。没有偏差分析，Capacity 永远停留在拍脑袋阶段，因为你不知道自己的估计错在哪里。

2. 误区二：把 100% 利用率当成目标

这是管理学上最经典的陷阱之一。利用率看起来越高越“高效”，但实施交付是存在排队和波动的系统，利用率接近 100% 时，任何一点波动都会直接转化为延期。

原理不复杂：当一个人手上没有任何余量，一个客户的临时变更、一次环境故障、一个关键人请假，都会沿着链条往后推。而在 80% 左右的利用率下，这些波动可以被吸收，不传导到交付里程碑。

我跟踪过的几个团队，利用率与结果呈现出明显的倒 U 关系：利用率从 60% 提升到 80% 的过程中，人均交付产出上升、项目周期下降；从 85% 继续往上，产出不再上升，返工和延期开始增加；超过 95% 之后，人员流失意愿显著上升，最终拖垮的是整体产能。

3. 误区三：把资源池当成无限池

很多团队做 Capacity 时只统计“人数”，不区分“能力”。结果排班时看起来很均衡，每个人负载都是 85%，但实际执行时发现：能做数据迁移的只有 2 个人，能独立对接客户的只有 4 个人，能做复杂权限配置的只有 1 个人。

这时所谓的 85% 是假的。真正的瓶颈不是总工时，而是稀缺技能的总工时。一个团队如果有 20 个人但只有 2 个人能做核心配置，那么这 2 个人的 100% 才是真实约束，其他人的空余产能无法替代。

修正方式是把资源池从“一维人数”改成“技能 × 等级”的二维矩阵，并且在计算负载时对稀缺技能做加权。这是我做 0 到 1 阶段第二个必须补上的动作。

4. 误区四：只算人，不算等待和切换

实施顾问同时跑 3 个项目的场景很常见。很多人算负载时只算任务工时总和，忽略了两个隐性成本：等待成本（等客户确认、等环境就绪、等第三方接口）和切换成本（在不同客户、不同系统之间来回切换的认知重建时间）。

我的经验估计是：同时并行的项目从 2 个增加到 4 个，有效产出会下降 10%-20%，即便总任务工时没变。这部分损失不会出现在任何一张表里，只会出现在“为什么他看起来很忙但进度很慢”的困惑里。

所以排班时除了看负载率，还要看并行度。一个简单规则：单个顾问同期主责项目不超过 2 个，参与项目不超过 3 个。这条规则对交付周期的影响，往往比精细的工时估算更大。

5. 误区五：先买系统，再想制度

这是最容易花钱的地方。团队一决定做 Capacity，第一反应往往是“买个工具”。但工具只能承载已经想清楚的规则，想不清楚的规则上了系统只会被更快地绕过。

我见过一个典型场景：某项目管理平台上线后，工时字段被设为必填，且与项目预算联动审批。结果一线很快学会了一件事，把工时填到“预算还剩多少”，而不是真实消耗了多少。系统里的负载率长期稳定在 82%，实际超过 100%，两个大项目同时延期才被发现。

度量一旦和考核或预算强绑定，就会立刻被优化。这不是道德问题，是制度设计问题。工具本身没有错，错在规则先于制度被固化。

四、专业判断逻辑：把 Capacity 拆成四个账户

讲完误区，需要一个能落地的计算框架。我的做法是把团队产能拆成四个账户，像财务一样管理：名义产能、可用产能、可承诺产能、已消耗产能。四个账户之间的差额，就是所有管理动作的抓手。

1. 账户一：名义产能（Nominal Capacity）

名义产能是最粗的一层：人数 × 工作日 × 每日标准工时。按国内常见口径，一个月按 21.75 个工作日、每天 8 小时计算，一个人月约 174 小时。

这个数字几乎从不等于真实产能，但它是所有折损计算的起点。它的价值在于提供一个统一的分母，让不同团队、不同区域之间可以对话。

2. 账户二：可用产能（Available Capacity）

可用产能是名义产能扣掉刚性折损后的结果。刚性折损包括法定假日、年假、病假、内部会议、培训、管理事务等不可避免的时间消耗。

按中间值测算，一个一线实施顾问的可用产能大约是 174 × 0.78 ≈ 136 小时/月。这个结果和很多团队的直觉一致：一个月真正能干交付活的时间，差不多是 130 小时上下。

3. 账户三：可承诺产能（Committed Capacity）

可承诺产能是可对外承诺的上限，等于可用产能再打一个缓冲折扣。缓冲的作用是吸收波动：客户变更、环境问题、临时插入。

缓冲比例取决于业务波动性。标准化程度高、变更少的交付，缓冲取 8%-10%；定制化程度高、客户配合度不稳定的交付，缓冲取 15%-20%。

按 12% 缓冲计算，可承诺产能约为 136 × 0.88 ≈ 120 小时/月。这个 120 小时，就是我建议写进制度里的“人均月度可承诺工时”。

4. 账户四：已消耗产能（Consumed Capacity）

已消耗产能包括已分配（排进计划但未执行）和已实耗（实际发生）两部分。这两者必须分开看，因为它们的用途完全不同：已分配用于判断未来风险，已实耗用于校准模型。

关键的对照关系是：已分配 ÷ 可承诺 = 负载率，这是排班决策的核心指标；已实耗 ÷ 已分配 = 兑现率，这是模型校准的核心指标。兑现率长期低于 85%，说明你的估算系统性偏乐观，需要下调可承诺产能。

5. 一张公式和一段可直接抄的配置

把四个账户写成一个可执行的公式，就得到了 0 到 1 阶段最核心的计算逻辑。下面这段是可直接抄走的口径定义，建议原文写进制度文档：

可承诺产能(月) = 工作日数 × 8 × (1 – 假期系数) × (1 – 协作系数) × (1 – 缓冲系数)
负载率 = Σ(已分配任务工时 × 技能稀缺度权重) ÷ 可承诺产能

兑现率 = 实耗工时 ÷ 已分配工时

偏差率 = (实耗工时 – 估算工时) ÷ 估算工时

参考取值（实施交付类团队）

假期系数 = 0.09

协作系数 = 0.14

缓冲系数 = 0.12

技能稀缺度权重：常规技能 1.0，稀缺技能 1.3，独家技能 1.6

红线

黄线 85%：需要资源经理确认后才能新增任务

橙线 95%：需要交付总监签字，且必须指定释放来源

红线 105%：禁止新增，除非走项目优先级评审

这段配置看起来简单，但它解决了三个过去一直模糊的问题：口径统一（所有人用同一个公式）、可比性（不同区域、不同技能可以横向比较）、可追责（红线对应明确的审批层级）。

五、制度设计：让 Capacity 有牙齿的七件套

公式只是骨架，制度才是让它运转的东西。以下七件事，是我在多个团队落地后总结出的最小必要集合。缺任何一件，Capacity 都会在三个月内退化成一份过期报表。

1. 责任矩阵：谁定义、谁维护、谁签字

Capacity 最常见的死法是“大家都在用，但没人负责”。必须把角色写清楚，并且和现有岗位对应上，避免造出一堆虚职。

这张表的关键是最后一行：销售必须参与承诺可行性确认。如果销售签合同时不需要引用 Capacity 数据，那么 Capacity 就永远只是交付部门内部的自我约束，对客户承诺毫无影响。

2. 三个节奏：周排、月调、季节

Capacity 不是一次性项目，而是有节奏的运营动作。我建议的最小节奏是三层：

• 周排（30 分钟）：资源经理与项目经理对齐下周排班，处理黄线告警，确认人员变动。输出是下周排班表。
• 月调（60 分钟）：复盘上月兑现率与偏差率，调整下月可承诺产能，处理橙线冲突，决定是否外协。输出是月度产能计划。
• 季节（半天）：审视技能矩阵与人员结构，决定招聘、培养、外协的年度配比。输出是产能预算。

节奏的价值在于把 Capacity 从“出问题时才想起”变成“固定动作”。每周 30 分钟的投入，换来的是避免每周 3 小时的救火，这是我见过性价比最高的一笔管理投入。

3. 负载红线与三级熔断

红线如果只是建议，就等于没有。必须设计明确的触发后果，也就是熔断机制。

这里有一个容易被忽略的设计细节：黄线的处理动作不是“确认一下”，而是“指定释放来源”。只确认不释放，负载不会下降，红线会一路被推高。我在第一版制度里就漏了这一条，结果三个月后全员平均负载 98%，红线形同虚设。

4. 技能矩阵：把“人”变成“能力单元”

当团队超过 50 人，只看总工时一定会失真。必须建立技能矩阵，把每个人的能力拆成可比较的单元。

我的做法是定义 5-7 个技能域（例如产品配置、数据迁移、接口集成、客户培训、方案设计），每个域分 4 个等级：不了解、可在指导下完成、可独立完成、可指导他人。等级直接映射到产能权重：

• 等级 1（可在指导下完成）：产能按 0.5 计，需要搭档。
• 等级 2（可独立完成）：产能按 1.0 计。
• 等级 3（可指导他人）：产能按 1.2 计，且可承担带教。
• 等级 4（专家）：产能按 1.2 计，但更重要的价值是可复用性，应限制被单一项目独占。

技能矩阵的真正用途不是评估人，而是识别结构性瓶颈：如果某个技能域等级 2 以上的人只有 2 个，而需求量对应的工时占比 30%，那么这个团队一定会在这一环堵住。

5. 与绩效解耦：这条不做，前四条全废

这是我认为最重要、也最容易被忽略的一条制度设计。如果负载率、工时数据直接进入个人绩效考核，数据质量会在两周内崩塌。

原因在于：负载率高低本身不是好坏，它取决于任务分配，而不取决于个人努力。把高负载等同于高绩效，会激励人们争抢“看起来忙”的任务；把低负载等同于不饱和，会激励人们虚报工时。

我的建议是：Capacity 数据只用于资源决策，绩效只看交付结果和质量。工时的准确性通过抽样核对来保障，而不是通过审批链条。这一点在后面第六节会有一个反直觉的数据支撑。

6. 数据口径唯一性：一个指标只能有一个算法

大组织里最常见的混乱是同一个词有两种算法。销售说的“人力占用”和交付说的“负载率”，往往连分母都不同。开会时吵得不可开交，其实双方都没错，只是口径不同。

解决办法是建立一份口径字典，把每个指标的定义、公式、数据来源、更新频率、责任人写死。这份字典不需要长，一页纸就够，但必须由一个人统一维护。

我通常会先锁三个口径：可承诺产能、负载率、兑现率。这三个锁住了，80% 的争论会自动消失。

7. 工具落地：在 PingCode 里怎么长出来

制度想清楚之后，才轮到工具。对 100 人以上的中大型实施组织，靠共享表格已经撑不住跨区域、多项目并行的复杂度，需要平台承载。这里以 PingCode 为例说明落地方式，它主要服务中大型企业及 100 人以上组织，在研发与交付一体的场景里比较常见。

落地的顺序建议是“先固化口径，再配置字段，最后做视图”，不要反过来。

（1）把可承诺产能做成人员维度的月度属性。每个人的可承诺工时不是填在脑子里，而是作为人员配置的一部分维护在系统中，按季度更新，技能等级变化时同步调整。

（2）用工作项类型区分负载来源。合同交付、售后支持、售前支持、内部事务分别建不同类型，这样负载率才能覆盖全部四类消耗，避免出现“账面 76%、实际 104%”的错觉。

（3）把负载率做成可筛选的资源视图。按区域、按技能域、按项目经理筛选，红黄绿三色直接对应熔断级别，周会就看这一个视图。

（4）把兑现率做成月度报表，但不进个人考核。兑现率的作用是校准模型，比如连续两个月兑现率只有 82%，说明可承诺产能估高了，应该从 120 小时下调到 110 小时左右。

（5）权限上做隔离。一线可以看自己的负载和团队公开视图，跨区域调配权限收在资源经理和交付总监手里，避免出现“谁都能拉人”的混乱。

需要强调的是，工具解决的是数据一致性和可视性问题，解决不了责任归属。如果第五条“与绩效解耦”没做，上任何平台都会得到一份被优化过的漂亮数据。

六、数据观察：12 个月，我们记录到了什么

以下数据来自我参与的一个 130 人实施组织的 12 个月改造复盘。涉及具体数值的部分属于内部观察口径，用于说明趋势和量级关系，不作为行业统计引用。他们的起点很典型：有工时填报，有项目排期，但没有统一的 Capacity 定义。

1. 三个阶段的基线

我们把 12 个月分成三段：M1-M3 建口径、定红线；M4-M8 跑周排月调节奏；M9-M12 引入技能矩阵与产能预算。三个阶段的核心指标变化如下：

这张表里最值得注意的不是改善幅度，而是倒数第二行：排班管理耗时是先上升的。M6 时达到 13 人天/月，比基线高出两倍多，当时的质疑声最大。M9 之后随着视图固化和技能矩阵成型，回落到 9 人天/月。

这个曲线说明一件事：制度建设的成本是前置的，收益是滞后的。如果在 M5 因为“管理成本上升”而放弃，就永远拿不到 M12 的结果。

2. 一个反直觉发现：填报复核率降了，准确率反而涨了

这是整个项目里最出乎我意料的观察。改造前，工时填报实行 100% 项目经理复核，所有工时单都要审批通过才生效。改造后，复核改为 20% 随机抽样，其余直接生效。

结果：工时数据准确率（与客户工单记录、系统操作日志交叉比对）从 71% 上升到 88%，而填报平均耗时从每人每周 35 分钟降到 12 分钟。

原因不难解释。全量复核制造了一个“写好看的数字”的激励：既然每个数字都要被人看，那不如填一个不会被追问的数字，于是所有异常都被抹平在提交之前。抽样复核 + 明确的抽查后果，反而让真实数据成为成本最低的选择。

这件事改变了我对制度的理解：复核的目的不是拦住错误，而是让说真话比说假话更省事。任何提高“说真话成本”的制度设计，最终都会得到一份漂亮但无用的数据。

3. 一个失败案例：系统上线后 Capacity 反而失真

同期我还跟进过另一个团队，走了相反的路径。他们先采购了某项目管理平台，把工时字段设成必填，并与项目预算联动：某项目工时超出预算 10%，系统自动冻结新增工时提交。

上线三个月后，报表显示全团队平均负载 82%，非常健康。但同期有两个合同金额最大的项目同时延期，客户投诉升级。

事后复盘发现问题出在激励结构上：项目经理为了让项目不超预算、不被冻结，会让团队把超出部分填到“内部事务”或“售后支持”类型下。于是主项目负载看起来正常，实际消耗被转移到了别的分类里。总量没变，结构被扭曲了。

这个案例的教训不是“不要用系统”，而是：当度量与预算、考核直接挂钩时，任何分类边界都会被人为利用。修正方式是取消工时与预算的硬冻结，改为超预算触发一次复盘对话，只讨论原因，不做自动惩罚。

4. 中大型组织的额外变量（PingCode 观察）

在服务中大型实施组织的过程中，我观察到几个在小团队里不存在、但在 100 人以上必然出现的变量，做 Capacity 时必须提前考虑：

• 多事业部口径不一致：不同事业部对“一个项目需要多少人力”的定义不同，横向比较会失真。解决方式是先统一到工时口径，再谈人月。
• 跨区域借调的隐性承诺：被借调的人往往在原区域还有未结任务，需要在系统中强制显示“全量负载”而非“本区域负载”。
• 共享专家资源被过度占用：少数专家会被所有项目争抢，需要在系统中单独标记并设置占用上限，例如单人同时参与不超过 3 个项目。
• 售前支持的不可预测性：售前投入随商机波动，建议按季度预留固定比例（如 8%-12%）的产能作为售前池，而不是让售前临时抢人。

这些变量的共同特点是：它们都不是算错的问题，而是结构问题。结构问题只能靠制度解决，算得再细也没用。

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

Capacity 没有通用模板，团队规模、业务形态、组织成熟度不同，起点和动作完全不同。以下按规模分层给出建议，可以直接对照自己的情况取用。

1. 10-30 人：一张表，一条红线

这个阶段不要引入任何系统。一张共享表足够，重点是把口径和红线定下来。

• 口径：可承诺产能按 120 小时/人月，全员统一，不做细分。
• 红线：85% 提醒、100% 禁止新增，两条线就够。
• 节奏：每周一次 30 分钟排班会，负责人主持，全员参加。
• 投入：约 1.5 人天/月，不需要专职角色。

这个阶段最容易犯的错是过度设计。我见过 20 人的团队做了一套 11 类折损系数、5 个技能域、3 张看板的模型，结果负责人自己都维护不动，两个月后彻底废弃。

2. 30-100 人：技能矩阵 + 周节奏

这个阶段开始出现“总工时够但活干不出来”的问题，必须引入技能维度。

• 技能矩阵：5-6 个技能域，4 个等级，每半年校准一次。
• 角色：设一名资源协调人（可由交付经理兼任 0.5 FTE），负责周排和维护数据。
• 口径：按技能域分别计算负载，识别稀缺技能瓶颈。
• 投入：约 6 人天/月，其中协调人占大头。

这个阶段的关键判断是：如果一个技能域等级 2 以上的人不足 3 个，就要立刻启动培养或外协，因为单点依赖在 50 人以上的组织里是系统性风险。

3. 100-500 人：角色分工 + 系统固化

这个阶段人脑调度已经失效，必须上平台，同时把责任矩阵固化下来。

• 角色：资源经理（每 100-150 人配 1 名）、交付总监（审批橙线以上）、项目经理（提供需求工时）。
• 系统：把可承诺产能、工作项类型、负载视图、兑现率报表四件套配置到位。
• 制度：三级熔断 + 月度产能预算 + 季度技能盘点。
• 投入：约 1 FTE 加 15 人天/月。

这个阶段最容易出问题的地方是跨部门博弈。资源经理手里有产能，项目经理手里有客户承诺，销售手里有合同压力。三者必须有一个共同的决策场，通常是月度产能评审会，没有这个场，Capacity 会变成三个部门互相甩锅的工具。

4. 500 人以上：产能预算制

到这个规模，Capacity 已经不是排班问题，而是资源配置和成本核算问题。核心动作是把产能当作预算来管理。

• 产能预算：每季度按事业部下达可承诺产能总量，事业部内部自行分配。
• 结算机制：跨事业部借调按内部结算价计费，让占用产能产生成本感知。
• 数据治理：设立专门的数据口径负责人，维护口径字典，定期审计数据质量。
• 投入：3-5 FTE，属于独立职能。

这个阶段的核心矛盾从“人不够”变成“产能配置效率低”。我见过一家 800 人的交付组织，总负载率只有 74%，但客户满意度持续下滑，原因是产能被配置在了低价值项目上，而不是产能不足。

5. 项目型、运维型、混合型的不同起点

除了规模，业务形态也决定了起点。三类典型形态的差异很大：

混合型最容易出事，因为运维的紧急性会不断侵蚀项目的计划性。我的建议是明确切分：例如 70% 产能给合同项目、20% 给运维支持、10% 作为机动池。切分比例本身可以调整，但必须有切分，否则项目永远输给“更急”的工单。

八、不同情况下的取舍

Capacity 的每一处设计都是取舍，没有全赢的方案。理解取舍的边界，比记住某个最佳实践更重要。以下五组取舍，是我在实际落地中反复遇到的。

1. 精度 vs 参与成本

精度提升的边际成本上升得很快。从 ±30% 提升到 ±20%，可能只需要统一口径；从 ±20% 提升到 ±10%，需要细化到任务级估算；从 ±10% 提升到 ±5%，往往需要历史数据积累两三年。

我的判断是：0 到 1 阶段目标定在 ±20%，1 到 10 阶段定在 ±10%，不值得为了 ±5% 投入一个专职团队。因为决策本身对精度的敏感度有限，接不接一个项目，±10% 的误差通常不改变结论。

例外情况是合同金额巨大、违约金条款严格的战略项目，这时值得单独做细颗粒度估算，但那是项目级动作，不是团队级制度。

2. 集中管控 vs 一线自主

集中管控的好处是全局最优，坏处是响应慢、容易脱离实际。一线自主的好处是灵活，坏处是本地最优、全局失衡。

我的经验分界线在 100 人：100 人以下，一线自主的效率更高，因为信息传递成本低；100 人以上，必须有集中管控，否则跨区域借调一定混乱。

更实用的设计是混合制：红线以下由一线自主调配，红线以上收归集中审批。这样既保留了日常灵活性，又守住了系统性风险的边界。

3. 硬红线 vs 缓冲区

硬红线（例如 105% 绝对禁止）执行起来清晰，但会牺牲灵活性，尤其是在突发项目上。软红线（例如超过后需说明）灵活，但容易被逐步侵蚀。

我的做法是分层：黄线和橙线用软约束（需审批、需说明），红线用硬约束（默认拒绝）。同时在红线之上留一个极窄的例外通道，由优先级评审会控制，且所有破例必须登记并公示。

关键在于破例要留下痕迹。没有痕迹的例外，第二个月就会变成常态。

4. 自建表格 vs 采购平台

这不是技术选择，而是组织选择。核心判断标准是：你的 Capacity 数据需要被多少个角色、多少个系统引用。

反过来说，如果满足左边三条以上，硬上平台只会增加成本。我见过 40 人的团队花半年实施一套平台，最后核心排班还是回到 Excel，因为平台的学习成本超过了他能获得的收益。

5. 一个我至今没完全解决的取舍

坦诚讲一个没解好的问题：售前支持的产能占用，到底该不该进排班。

不进排班，售前会无序挤占交付产能，导致交付延期；进排班，由于商机不确定性高，大量预留会浪费产能，而且销售会倾向于虚报商机概率来抢资源。

我目前的做法是折中：按季度预留固定比例（8%-12%）的售前池，由售前负责人统一申请，交付侧只对池子总量负责，不逐单排班。这个方案降低了摩擦，但没有解决根本问题，商机转化率波动大的时候，池子要么不够要么浪费。

如果你的组织有更好的解法，我很想听。这也说明 Capacity 不是一个能被彻底解决的问题，而是一个需要持续调参的机制。

九、把 0 到 1 走完：接下来 30 天、90 天、12 个月

最后给一份可以直接执行的时间表。它的设计原则是：每个阶段只解决一个问题，不并行推进，避免组织消化不良。

1. 前 30 天：只做口径和一条红线

• 第 1 周：定口径字典，写死可承诺产能、负载率、兑现率三个公式，指定唯一维护人。
• 第 2 周：拉出上个月的实耗数据，反推团队的实际兑现率，作为模型校准的基线。
• 第 3 周：定一条红线（建议 85%），明确超线后的处理动作和签字人。
• 第 4 周：开第一次周排会，跑通一个完整循环，输出下周排班表。

这 30 天的成功标准不是数据多准，而是周排会开了四次且没有中断。节奏一旦建立，后面加什么内容都能承载；节奏没建立，加什么都是负担。

2. 第 31-90 天：补齐技能维度和负载来源

• 把负载来源从一类扩到四类（合同交付、售后支持、售前支持、内部事务），消除“账面健康”的错觉。
• 建立 5-6 个技能域的矩阵，完成第一轮等级评定。
• 识别结构性瓶颈：哪个技能域等级 2 以上的人少于 3 个，列入季度招聘或培养计划。
• 开始记录估算偏差，为后续模型校准积累数据。

这个阶段最容易被跳过的是技能矩阵，因为它的收益不直接。但没有它，负载均衡就永远只是总工时的均衡，遇到稀缺技能冲突时会立刻失效。

3. 第 4-12 个月：固化、校准、扩面

• 把口径、红线、视图固化到平台（如 PingCode 这类面向中大型组织的平台），减少手工维护。
• 每月复盘兑现率，按偏差调整可承诺产能，形成校准闭环。
• 把 Capacity 数据接入销售承诺流程，让“能不能接”有据可依。
• 引入产能预算，按季度分配，处理跨区域、跨事业部的调配。

到第 12 个月，判断是否完成 1 到 10 的标志是：Capacity 数据开始被销售、财务、HR 引用。如果只有交付部门自己在用，说明它还是一个内部工具，不是一个组织机制。

4. 三个不要做

最后列出三条我认为最容易踩的坑，作为反向清单：

1. 不要一上来就全员全量填报。先在一个区域或一条产品线跑通，再扩面。全量推行一旦遇阻，回退成本极高。
2. 不要把工时数据接进绩效考核。这是我见过导致 Capacity 项目失败最多的单一原因，没有之一。
3. 不要在制度还没跑顺时采购系统。系统会把你当前的混乱固化下来，而且改起来比表格贵十倍。

回到开头那个交付总监的困惑：“不知道人到底够不够。”其实答案不在数字里，而在制度里。当每个人知道自己能承诺多少、超过之后会发生什么、谁有权打破规则、打破之后谁承担后果，Capacity 就从一张表变成了组织能力。

我的核心观点是：Capacity 的 0 到 1，本质上是一次关于“承诺权”的制度建设，而不是一次数据建模。公式可以两周写完，制度要跑一年。绝大多数团队失败，不是因为算错了，而是因为没人认账。

如果你正准备开始，下一步不用做太多：本周把可承诺产能的公式定下来，找一个人签字负责，下周开一次 30 分钟的排班会。做到这三件事，你就已经站在 0 到 1 的起跑线上了。剩下的，交给十二个月的节奏。