资源负载Capacity教程：跨部门团队入门指南，避坑指南

去年第四季度，我帮一家做工业软件的公司做交付复盘。他们有一个 6 人的数据平台小组，同时支撑 5 条业务线。季度初排期时，5 个业务负责人分别在自己的计划表里写了"数据平台支持 20%"，看起来一切正常。季度末复盘，这个小组实际投入的时间是各业务线申报总和的 2.3 倍，换句话说，他们的 Capacity 被重复计算了两遍多，而没有任何一张表显示"超载"。

这不是个例。资源负载（Resource Load / Capacity）这件事，难点从来不是"算不出来"，而是算出来的数字彼此不可加、不可比、不可信。跨部门场景会把这个难点放大一个数量级：不同团队有不同的日历、不同的计量单位、不同的优先级来源，还有一个隐形的共享专家池。这篇文章把我这几年在跨部门容量治理上踩过的坑、用过的模型、验证过的数据判断，完整拆一遍。

一、核心结论：资源负载不是"人够不够"，而是"能不能承诺"

先把结论摆出来。如果你只想记住一句话，那就记这句：Capacity 是你在某个置信水平下敢于对外承诺的工作量，而不是你手上人头数乘以工时。前者是一个带概率区间的承诺能力，后者只是一个加法结果。把后者当前者用，是绝大多数跨部门排期崩盘的第一块多米诺骨牌。

1. 结论一：Capacity 是区间，不是数字

我在做容量评估时从来不输出单一数字，只输出三档：P50（一半概率能完成）、P80（大概率能完成）、P95（几乎确定能完成）。原因很朴素，需求侧的不确定性和供给侧的不确定性会相乘，而不是相加。

举个例子：一个团队净容量 520 小时，某需求预估 480 小时。表面看余量 40 小时，很安全。但实际上需求侧有 30% 的估算偏差、供给侧有 15% 的临时插入，两者叠加后的实际分布里，这个需求按期完成的概率大约只有 55%。用点估计做排期，等于用平均值去赌一个必然有波动的系统。

在跨部门场景里，这个偏差还会被"交接"进一步放大。每增加一次跨团队交接，就多一次理解损耗和等待损耗。4 个团队串行接力，单环节 90% 的准确率，端到端只剩 66%。

2. 结论二：容量损耗随协作团队数量超线性增长

很多管理者有一个直觉：多加一个团队进来协作，成本是线性增加的。实际不是。协作通道数按 n(n-1)/2 增长，而每个通道都需要同步、对齐、确认，这些动作消耗的是同一批人的净容量。

我做过一个粗略的回归：把"参与团队数"作为自变量，"单个团队的有效产能系数"作为因变量，在我经手的 20 多个跨部门项目里，2 个团队协作时有效产能系数约 0.88，4 个团队约 0.74，6 个团队约 0.63，8 个以上掉到 0.5 附近。这不是因为人变懒了，而是协调本身成了工作量的主要构成。

3. 结论三：负载失控的根因在需求入口，不在排期表

我见过太多团队花两周做出一张漂亮的资源负载热力图，然后第三周就被打回原形。原因不是图做得不好，而是需求入口没有闸门。只要任何人都能随时往队列里塞活，容量模型就永远追不上变化。

正确的顺序是：先控制"进多少"，再计算"能做多少"，最后才谈"谁来做"。很多团队反过来做，先算容量，再被动接收需求，结果是容量表每月重算一次，每月都不准。我在后面第四部分会给出一个具体的入口控制办法。

4. 结论四：计量单位不统一时，任何汇总都是伪精度

研发用故事点，设计用设计稿张数，测试用用例条数，运维用工单数，交付用现场人天。这五组数字加在一起，除了让你在汇报 PPT 上看到一个大数，没有任何决策价值。

跨部门容量汇总必须先落到一个共同分母。我的做法是统一折算到"净投入人时"这一个口径，其余单位只作为内部估算工具保留，不进入跨部门汇总层。这个取舍有代价，第六、七部分会具体讲什么时候不该这么做。

二、背景与真实场景：跨部门容量为什么会系统性失真

理论讲完，进入现场。跨部门容量失真不是某个人算错了，而是四个结构性原因叠加的结果。这四个场景我在不同公司反复遇到，几乎每次复盘都能对上号。

1. 场景一：共享专家池被每个需求方各自计一次

架构师、DBA、安全工程师、UX 设计师、数据分析师，这些角色天然是共享的。问题在于，每个业务负责人在做自己的容量规划时，都会把这位专家按"我需要他投入多少"写进去，而没人做跨表的加总校验。

于是出现一个荒诞的局面：某平台工程师在 A 团队的表里占 30%，在 B 团队占 40%，在 C 团队占 35%，三张表都显示"未超配"，加起来却是 105%。单表正确、全局错误，这是跨部门容量治理里最常见也最隐蔽的失真。

2. 场景二：日历不一致带来的隐性缺勤

跨部门容量最容易忽略的一项，是各团队的日历根本不同。研发团队有版本封版期，测试团队有集中回归周，交付团队有现场实施窗口，运维团队有值班轮换。这些在各自的表里都是"正常安排"，汇总到项目层就变成"某个时间段里没人可用"。

我做过一次统计：一个名义上 100% 可用的季度，扣掉法定假期、公司统一活动、团队专属封版期、值班轮换、以及无法避免的临时支持后，真正可用于计划内需求的净容量只有名义工时的 52% 到 58%。这个数字在很多团队里是让人惊讶的，他们做规划时用的基准往往是 85% 甚至 90%。

3. 场景三：支持性工作没有入口，只能从容量里"偷"

线上问题、客户答疑、内部咨询、临时评审，这些工作有一个共同特征：它们不经过需求管理流程，但真实消耗容量。有些团队的做法是"不算进去，反正是零碎的"，结果就是每个迭代都有一块说不清去向的时间黑洞。

谷歌 SRE 团队公开过一个著名的容量原则：运维与支持类工作不应超过团队总时间的 50%，超过就必须把一部分支持工作推回给开发团队。这个 50% 不是随便定的，它的逻辑是，如果支持工作吃掉一半以上，工程改进就永远排不上，技术债会进入不可逆的累积。

我的经验值是：支持性工作至少要按 10% 到 20% 显式预留，而且必须是"有名有姓的容量条目"，不能是"留点余量"。写进模型和留在脑子里，是两种完全不同的管理强度。

4. 场景四：承诺制排期与容量制排期的混淆

这是最根本的一个场景差异。承诺制排期是"客户要这个日期，我们倒推要多少人"；容量制排期是"我们有多少净容量，能装下多少需求"。跨部门项目里，这两种模式经常被混着用，而且没人说清楚用的是哪一种。

结果就是：业务方以为按容量制在排（所以随时可以加需求），交付方以为按承诺制在排（所以日期不能动）。两种模式本身都没错，混用才是灾难。后面第七部分我会给出选择标准。

三、拆解常见误区：六个看起来合理、实际在制造失真的做法

以下六个误区，我在评审会上见过太多次。它们的共同点是：每一个单独看都有道理，放在跨部门场景里就会系统性失真。我按"看到的现象 → 真实的代价 → 该怎么改"三段来拆。

1. 误区一：把 FTE 当容量

现象：计划表里写着"投入 1.0 FTE"，于是认为这个人有 1.0 的全部产能。

真实代价：FTE 是雇佣口径，不是产出口径。1.0 FTE 在扣掉假期、会议、支持、切换损耗之后，净可用往往只剩 0.5 到 0.6。用 FTE 做汇总，等于系统性地高估 60% 以上的可用量。

怎么改：把 FTE 只作为"编制核对"用，容量模型里一律使用净人时。如果一定要用 FTE 表达，就明确写"1 FTE = 每周 X 净人时"，并把这个换算系数固定在制度里。

2. 误区二：追求 100% 利用率

现象：管理者看到某团队利用率只有 78%，第一反应是"还有 22% 的产能没释放出来"。

真实代价：排队论里有个结论，服务系统的利用率接近 100% 时，平均等待时间会趋于无穷。这不是理论洁癖，而是可以在任何共享资源池上观察到的现象，利用率 85% 之后，交付周期的方差会急剧放大，一个 2 天的小任务可能要等 9 天。

怎么改：把利用率当作风险指标而不是效率指标。跨部门共享资源池的目标利用率区间我一般设在 70%-85%，超过 85% 就要触发扩容或需求削减的动作，而不是庆祝。

3. 误区三：把"分配比例"当"实际投入"

现象：一个人被标注为"A 项目 50%、B 项目 50%"，于是认为投入是均衡的。

真实代价：50/50 的分配在现实中几乎从不存在。人不是按比例切片工作的，而是按"当前最紧急的那件事"整体投入。同时挂两个项目的人，真实分布往往是 80/20 或 90/10，而且这个比例每周都在变。

怎么改：用切换成本模型替代比例模型。我用的经验系数是：同时参与 1 个项目，有效产能 100%；2 个约 88%；3 个约 78%；4 个约 68%；5 个及以上约 60%。这个系数不是精确科学，但它比"按比例线性切分"更接近真实。

4. 误区四：用故事点跨团队汇总

现象：把三个研发团队的故事点加起来，得到"本季度总产能 480 点"。

真实代价：故事点是团队内部的相对估算单位，不同团队的 1 点没有任何可比性。A 团队的 1 点可能是 4 小时，B 团队的 1 点可能是 12 小时，如果两个团队的历史速率恰好接近，汇总出来的数字会显得"很合理"，这反而更危险，因为它没有暴露问题。

怎么改：跨团队汇总一律走净人时。故事点只在团队内用于估算和速率跟踪。如果一定要保留故事点体系，就在每个季度做一次"点，人时"的换算校准，把换算系数作为显式参数管理。

5. 误区五：把容量规划当年度动作

现象：年初做一次全面资源规划，然后一整年按这张表执行。

真实代价：跨部门环境的参数变化速度远高于年度周期。组织调整、客户结构变化、技术栈迁移、外包比例变化，任何一项都会让年初的模型失效。我见过最典型的失败案例是：模型做完两个月后就已经完全不匹配现实，但团队还在用它做决策，因为"这是正式批准的规划"。

怎么改：分层更新。年度只定结构性参数（编制、外包比例、共享资源池规模），季度校准净容量系数（出勤、支持占比、切换损耗），双周更新可调度容量。三层更新频率不同，但必须在同一套口径下。

6. 误区六：没有为不可见工作留缓冲

现象：容量模型算到"净可用 520 小时"，然后把 520 小时全部排满需求。

真实代价：任何真实团队都有 10% 到 20% 的不可预见工作，线上故障、临时评审、法务合规检查、客户现场救火。把净容量排满，等于默认这些工作不存在。结果是每个迭代都延期，而延期的原因每次都"很合理"，于是没人去改模型。

怎么改：在净容量和可承诺容量之间，强制插入一个显式缓冲层，比例 15%-25%，并且这个缓冲不能因为"这个季度特别忙"而被临时征用。它的存在本身就是容量模型可信度的一部分。

四、专业判断逻辑：我实际在用的四层容量模型

把上面所有坑绕开之后，需要一个可执行的结构。我用的是一个四层漏斗：毛容量 → 净容量 → 可承诺容量 → 可调度容量。每一层都有明确的扣减项和明确的用途，不能跳层，也不能混用。

1. 第一层：毛容量（Gross Capacity）

定义：名义可用工时 = 人数 × 标准工作日 × 每日标准工时。这一层只用于编制核对和对外报价的初始基准，绝不能用于排期。

我之所以坚持保留这一层，是因为它能和 HR 系统、财务预算对得上。跨部门容量治理要想推得动，第一件事就是让数字能和财务口径对齐，否则你永远在跟"预算里明明有这么多人"这句话打架。

2. 第二层：净容量（Net Capacity）

定义：毛容量扣掉出勤损失、固定占用、支持性工作、切换损耗之后的真实可用量。这是供给侧的核心数字，也是我最常对外沟通的一个数。

扣减项要按"可预测性"排序处理：可预测的（假期、封版期、值班表）直接扣；半可预测的（会议、评审）按滚动均值扣；不可预测的（线上故障、临时支持）用显式缓冲覆盖，而不是塞进净容量里。

3. 第三层：可承诺容量（Committed Capacity）

定义：净容量 ×（1 − 缓冲率）。缓冲率我一般设 15%-25%，具体取决于两个因素：需求侧的波动程度和支持性工作的历史占比。波动越大、支持占比越高，缓冲越靠上限。

这一层是对外承诺的唯一合法来源。任何跨部门承诺，都必须从这一层出，不允许直接从净容量出。这条规则听起来形式主义，但它是把"承诺"和"能力"解耦的关键动作。

4. 第四层：可调度容量（Schedulable Capacity）

定义：可承诺容量减去已承诺的工作量，剩下的才是可以接新需求的量。这一层是需求入口的闸门依据，新需求进来时，先看这一层还剩多少，而不是先看谁"看起来比较闲"。

很多团队缺的就是这一层。他们能算出总容量，也能算出已用量，但没有把"剩余可调度量"作为准入条件固化下来，于是新需求永远能进来，容量模型永远是事后解释工具。

5. 四个参数的敏感度：改哪个最有效

模型建好之后，管理者最常问的问题是"要提高产出，先动哪个参数"。我做过一次敏感度分析：把每个参数在 ±10% 范围内单独变动，看最终可调度容量的变化幅度。

结论有点反直觉：影响最大的不是增加人数，而是降低切换损耗和压缩固定会议占用。人数增加 10% 带来的可调度容量提升约 9%，而把并行项目数从 4 个降到 2 个，可调度容量能提升 20% 以上，成本为零。

6. 一个可直接跑的计算脚本

下面这段代码是我在评估单个团队净容量时用的简化版本。它不追求精确，只追求把扣减项显式化，每一行扣减都对应一个可以被质疑、被调整的业务参数，这比一个黑箱数字有用得多。

# capacity.py ， 单团队净容量与可调度容量计算（简化示例）
SWITCH_LOSS = {1: 0.00, 2: 0.12, 3: 0.22, 4: 0.32, 5: 0.40}

def team_capacity(headcount,      # 人数

weeks=5,        # 周期周数

hours_per_week=40,

attendance=0.94,   # 出勤系数：扣除假期与调休

freeze_ratio=0.09, # 封版期/回归周占比

oncall_ratio=0.12, # 值班与线上支持占比

meeting_ratio=0.10,# 会议与评审固定占用

parallel_projects=2,

buffer_ratio=0.20):

gross = headcount * weeks * hours_per_week

net = gross * attendance * (1 - freeze_ratio - oncall_ratio - meeting_ratio)

net *= (1 - SWITCH_LOSS.get(parallel_projects, 0.40))

committed = net * (1 - buffer_ratio)

return {

"gross": round(gross, 1),

"net": round(net, 1),

"committed": round(committed, 1),

"coefficient": round(net / gross, 3),   # 净容量系数，用于快速横向对比

}

示例：20 人团队，同时挂 4 个项目

print(team_capacity(20, weeks=5, parallel_projects=4))

输出约：{'gross': 4000.0, 'net': 1767.0, 'committed': 1413.6, 'coefficient': 0.442}

注意最后那个 coefficient 字段，净容量系数。这个系数是我做跨团队横向对比时最常用的一个数：它把不同规模的团队拉到同一尺度上，系数 0.55 的团队和系数 0.40 的团队，差异往往不来自努力程度，而来自并行项目数量和会议密度。把系数暴露出来，管理动作才有落点。

五、具体案例与数据观察：一个 120 人组织的跨部门负载治理

下面这个案例来自一家做企业级软件的公司，规模约 120 人，包含研发、产品、测试、交付四条线，跨 7 个团队。我参与了他们的容量治理改造，前后跨度约两个季度。数据是该公司的实际观测值，出于保密做了取整处理。

1. 治理前的状态：数据齐全，但不可用

他们原本有一套完整的资源管理流程：每个团队用表格维护人员分配，项目经理每周汇总，月度出一份资源负载报告。表面看流程健全，实际有三个硬伤。

第一，共享角色被重复计入。两位架构师和一位数据工程师被 5 个团队同时申报，合计占用 240%，但没有任何一张表显示超配。第二，版本冲突导致的数据不一致。7 个团队各自维护表格，月度汇总时经常出现三个版本的"最终版"，项目经理要花 2 天手工对齐。第三，负载数据与工作实际脱节。表格里填的是计划分配，实际工作量记录在另一套系统里，两边从来没有对账。

2. 改造动作：先把口径统一，再谈工具

很多团队一上来就换工具，结果是把错误的流程固化成系统配置。我们的顺序反过来：先花两周统一口径，再花两周配置工具。

1. 统一计量单位。跨部门汇总层一律使用净人时，各团队内部保留原有估算单位（故事点、用例数、人天），但必须提供到人时的换算系数。
2. 建立共享资源台账。把所有被 2 个以上团队使用的角色单独列出来，只允许在一处维护，其他团队引用而非复制。
3. 定义四层容量口径。把毛容量、净容量、可承诺容量、可调度容量写进制度，明确每一层由谁维护、多久更新一次。
4. 设置需求准入闸门。新需求进入前必须校验可调度容量，超出即进入等待队列，不允许"先接再想办法"。
5. 配置工具承载。在项目管理平台里把上述口径落地成工作项字段、迭代容量和跨项目资源视图。

3. 工具落地：以 PingCode 为例的配置思路

这家公司最终选了 PingCode 作为承载平台。选它的原因不是功能清单最长，而是它的数据模型能把"工作项，迭代，团队，人员"这几层关系串起来，容量口径可以直接落在字段和视图上，不需要二次开发。对于 100 人以上、跨部门协作的组织，这种"口径可直接配置"的能力比"功能多"更重要。

具体配置上有四个关键动作，我认为是可复用的：

（1）把净容量写进迭代。每个迭代设置容量上限时，直接使用可承诺容量，而不是毛容量。这一条改动看起来简单，但它把"承诺从哪来"这件事制度化了，迭代容量一旦填错，整个季度的排期都会歪。

（2）用工作项字段承载估算单位。保留各团队原有的估算字段，同时增加一个统一的"净人时"字段，由团队在迭代规划时填写。跨部门视图只读净人时，不看原始估算。

（3）共享角色单点维护。把架构师、DBA、安全、UX 这类共享角色建成独立的资源条目，各团队的分配以引用方式挂载，任何一处修改全局同步。这一条直接消灭了重复计入。

（4）跨项目资源视图作为周会材料。每周用同一张跨团队负载视图开协调会，不再各自准备表格。这一条把"数据对齐"从月度动作变成周度动作，超配识别延迟从 23 天压缩到 4 天以内。

4. 改造后的数据变化

两个季度之后，几个关键指标的变化如下。需要说明的是，这些改善不是单一动作的结果，而是口径统一、共享台账、准入闸门、工具承载四件事叠加的效果。

5. 反例：表格方案在什么规模开始崩掉

这家公司在治理前一直用表格，也曾经争论过"是不是非得上工具"。我的观察是：表格方案的崩溃点不在人数，而在"共享资源数 × 维护者数量"。

粗略判断标准是：共享资源超过 5 人、且维护者超过 3 人时，表格方案的版本一致性成本会快速上升；共享资源超过 8 人、维护者超过 5 人时，靠人工对齐已经不可能保证准确，超配识别延迟会稳定超过两周。

六、不同情况下的行动建议：按组织规模分档

容量治理没有通用方案，只有匹配规模的做法。下面按组织形态分五档给建议，每一档我都标注了最小可行动作和不必做的事，后者同样重要，很多团队是被过度设计拖垮的。

1. 三个团队以内、共享资源少于 5 人

最小可行动作：一张共享的净容量表 + 每周一次 30 分钟的对齐会。表里只维护三个字段：净人时、已承诺人时、可调度人时。共享资源单独列一行，只在这里维护。

不必做的事：不需要上系统，不需要做四层模型，不需要引入缓冲率的精细计算。这个规模下，20% 的经验缓冲足够用，把它写死在表里就行。

判断依据：共享资源 5 人以内、维护者 3 人以内时，版本冲突的次数还在可人工管理的范围内。此时引入工具，收益抵不上配置和维护成本。

2. 五到十五个团队、存在跨团队共享角色

最小可行动作：共享资源单点维护 + 分层容量口径 + 需求准入闸门。这三件事是这一档的核心，缺任何一件都会导致模型失效。

具体做法：先建一张共享资源台账，把所有被 2 个以上团队引用的角色列出来，只允许在一处维护。然后把容量口径固化成四个字段，写进迭代规划模板。最后设置准入门槛：可调度容量低于 10% 时，新需求一律进入队列，由协调会决定插队还是延后。

工具建议：这一档是工具收益最明显的区间。用 PingCode 这类支持跨项目资源视图的平台，把共享角色、迭代容量、跨团队负载放在同一套数据模型里，能直接消灭重复计入和版本冲突。配置成本大约两周，之后每月的维护成本能降一半以上。

3. 十五个团队以上、多项目组合管理

最小可行动作：在上一档基础上增加组合层容量视图和容量，战略对齐机制。这个规模下，单个项目的容量准确已经不够，必须看组合层的总量分配是否符合战略优先级。

具体做法：把容量按"战略投入 / 维持性投入 / 支持性投入"三类切分，每季度校验三类比例是否符合战略意图。如果战略上说要投新产品，但容量分配显示 70% 在维持性工作上，那说明战略没有落地。

不必做的事：不必追求所有团队用同一套估算单位。这个规模下强行统一会引发大量抵触，用净人时做汇总层、保留团队内部单位是更实际的选择。

4. 强合规或外包结算场景

最小可行动作：容量模型必须可审计。这意味着每个扣减项都要有来源凭证，工时记录要能追溯到具体工作项，缓冲率的使用要有审批记录。

这一档的特殊性在于：容量数据不只用于内部排期，还用于对外结算或合规证明。所以精度要求更高，但代价是维护成本显著上升。我的建议是接受这个成本，不要为了省事用估算替代记录，一旦涉及结算争议，估算值没有任何说服力。

5. 研发与交付混合、存在现场实施

最小可行动作：把交付侧容量单独建模，不要和研发容量混在一张表里。原因很直接：交付的容量波动远大于研发，受客户现场因素影响，用同一套系数会互相污染。

具体做法：研发侧用标准的四层模型，交付侧用"可派单人数 × 现场可用天数"的简化模型，两侧只在组合层通过净人时汇总。这条边界划清楚，能避免大量口径争论。

七、不同情况下的取舍：五个必须做选择的岔路口

容量治理的本质是一连串取舍，而不是一连串最佳实践。下面五个岔路口，每个我都给出两边的代价，你自己判断落在哪边。

1. 精度 vs 维护成本

提高精度的每一档都要付出维护成本。从"按月估算"到"按周校准"，准确率大约能从 65% 提到 82%，但维护工作量会翻倍；从"按周校准"到"按天实时"，准确率只能再提 5 个百分点，维护成本却再翻一倍。

我的判断：停在按周校准。再往上走的边际收益远低于成本，而且实时数据会带来一个副作用，管理者开始盯着日粒度的波动做决策，反而制造了大量噪音干扰。

2. 统一单位 vs 尊重专业差异

强行统一估算单位的好处是汇总简单，代价是各团队失去熟悉的估算语言，估算质量短期会下降。保留差异的好处是团队效率高，代价是汇总层需要维护换算系数。

我的判断：汇总层统一，团队层保留。换算系数由团队自己申报并季度校准，汇总层只认净人时。这个方案的隐性成本是换算系数可能被"美化"，所以每季度要用实际工时做一次反向校验。

3. 集中调度 vs 团队自治

集中调度能最大化全局效率，但会牺牲团队的自主性和响应速度；团队自治响应快、士气高，但容易出现局部最优、全局次优。

我的判断：按资源类型分。共享稀缺资源（架构、安全、数据）集中调度，因为这些资源一旦被局部占用就会造成全局瓶颈；常规资源团队自治，因为这些资源的调度成本高于收益。

4. 工具 vs 流程

这是最容易做错的一个取舍。工具能降低数据维护成本、消灭版本冲突，但不能替代流程，如果需求入口没有闸门，再好的工具也只是把混乱记录得更清楚。

我的判断：流程先行，工具跟进，间隔不超过一个月。间隔太长，流程会因为缺乏数据支撑而流于形式；间隔太短，工具会把还没想清楚的流程固化下来，之后改起来更贵。

5. 缓冲 vs 承诺

缓冲率高，交付确定性高，但可承诺容量下降，业务方会觉得"你们明明有人却不接活"；缓冲率低，短期承诺量好看，但延期概率上升，长期会失去信任。

我的判断：缓冲率跟波动率挂钩，不做统一规定。需求波动小的团队用 15%，波动大的用 25%，并且把"为什么是 25%"的理由写进制度。有理由的数字比拍出来的数字更容易被接受。

八、30 天落地清单：从明天开始能做的动作

最后给一份可以直接照着做的清单。我不建议一次性全推，按周推进、每周只做一件事，这样每一步都有验证窗口。

1. 第一周：先把数字算对

选一个团队做试点，用第四部分的四层模型算出它的毛容量、净容量、可承诺容量。关键动作是把所有扣减项显式列出来，让团队成员逐项确认，共识比精度更重要，因为后续所有讨论都建立在这组数字上。

这一周最容易出现的分歧是"支持性工作到底占多少"。不要争论，直接让团队回看过去四周的实际记录，用数据说话。

2. 第二周：建共享资源台账

把所有被 2 个以上团队使用的角色列出来，统计每个团队对它的申报占用，然后加总。超过 100% 的，逐个确认实际投入，并确定唯一的维护位置。

这一周通常会挖出最多问题，也是最容易推动的一次，因为超配是客观事实，不需要说服。

3. 第三周：设置需求准入闸门

把"可调度容量"作为新需求的准入条件写进流程。规则要简单到不需要解释：可调度容量低于 10% 时，新需求进入队列，由周度协调会决定优先级。

这一周会遇到最大阻力，因为闸门直接限制了业务方的自由度。关键是把阻力转化为规则讨论，而不是个案通融，只要开了第一个口子，闸门就会失效。

4. 第四周：固化节奏与口径

确定三件事：谁维护容量数据、多久更新一次、在哪个会上用这份数据。然后把四层容量口径写进迭代规划模板，让下一次规划自然使用新口径。

如果这一周发现团队规模已经超过表格能承载的临界点（共享资源 6 人以上、维护者 3 人以上），就该考虑把口径落到系统里了。工具选择上不必追求功能最多，能承载"共享资源单点维护 + 跨项目资源视图 + 迭代容量字段"这三件事就够了。

5. 一份可直接对照的自查清单

• 我们用的是净人时还是毛容量做排期基准？
• 共享角色是否只在一处维护，其他团队引用而非复制？
• 缓冲率是否显式写进模型，而不是"留点余量"？
• 利用率超过 85% 时，我们触发的是扩容还是削减？
• 同时挂 3 个以上项目的人有多少，切换损耗是否计入？
• 新需求进来时，第一件事是看可调度容量还是看谁比较闲？
• 容量数据的更新频率是周还是月，超配多久能被发现？
• 支持性工作是否有独立容量条目，还是从项目容量里"偷"？

这八个问题里，如果有三个以上答不上来，容量模型目前还只是报表，不是决策工具。

结语：容量治理真正治理的是"承诺的可信度"

回到开头那家工业软件公司。他们后来最大的变化不是容量算得更准了，而是业务方开始相信容量数字了。相信之后，"再加一个小需求"的请求自动减少，因为大家知道那意味着另一样东西要被推后，这个因果链一旦透明，很多争论就消失了。

所以如果你只从这篇文章带走一件事，我希望是这个判断：容量治理的价值不在于把工时算到小数点后一位，而在于让"能做什么、不能做什么、代价是什么"变成组织里的公共知识。数字准不准是技术问题，数字被不被相信是管理问题，后者才是瓶颈。

下一步建议：不要先买工具、也不要先做全公司推广。找一个 20 人左右、跨 3 个团队的试点，用四周时间把四层模型跑一遍，拿到第一组真实的净容量系数。有了这组数字，后续所有讨论，加人、减并发、调优先级、上系统，才有共同的参照系。没有这组数字，任何容量治理都会退化成一次关于"到底忙不忙"的立场之争。