Capacity管理指南：跨部门团队如何做好资源负载，入门指南全流程

去年我们给一个 120 人规模的跨部门项目做季度容量规划，表格做得很漂亮：62 名研发、18 名测试、9 名设计、7 名运维，按每人每月 20 个工作日算，一个季度能排出接近 5,700 人天的"产能"。计划排到第 6 周就崩了。不是有人离职，也不是需求变多了，而是我们从第一行就把每个人当成 100% 可用的资源写进了表格。真实情况是：这 62 个人里，有 11 个人同时在两个项目上被重复计算，有 4 个人一半时间在做线上支持，还有几乎所有人每周要开 6 到 9 小时的会。

那张看起来精确到人天的容量表，实际误差超过 40%。

这件事让我彻底改变了对 Capacity 管理的理解。跨部门团队的容量管理，从来不是把人数乘以天数，而是把"名义人力"一层层折算成"可以被承诺的时间"，再把它和一份排好序的需求清单对齐。这篇文章会把这套折算逻辑、踩过的坑、用过的工具和三个季度的真实数据变化完整拆开讲，读完你应该能自己动手做出一张"能被质疑、也经得起质疑"的容量表。

一、先给结论：跨部门容量管理，管的不是人头，是可承诺时间

在展开细节之前，我先把最重要的五条判断放在前面。它们不是理论推导出来的，是我们在几个项目上反复撞墙之后留下来的东西。

1. 容量必须按"角色 × 周期 × 净可用时间"计算

按人头算容量是最常见的错误起点。同一个"1 个人"，在研发角色上和在测试角色上的可用时间完全不同；同一个角色，在冲刺周期内和在季度周期内的可用时间也完全不同。容量单位至少要同时锚定三个维度：什么角色、多长周期、扣掉非项目占用之后还剩多少。

我们后来的做法是把容量单位统一成"角色人天/双周"，并且明确规定这个数字是净值，已经扣掉了会议、线上支持、行政事务和法定假期，只保留真正能投到项目工作项上的时间。口径一旦统一，跨部门对齐的争议减少了大概七成。

2. 100% 利用率是一个负指标，不是目标

很多管理者潜意识里把"资源利用率"当成效率指标，看到 85% 就想往上推。但在有排队和波动的系统里，利用率越高，等待时间增长得越快，这不是经验，是排队论里的基本结论。当系统负载从 70% 推到 90% 时，平均排队等待时间不是增加 28%，而是可能翻好几倍。

跨部门协作的系统波动比单团队更大：需求到达不规律、交接环节多、每个部门的处理时间差异大。在这种系统里，把利用率顶到 95% 的唯一结果，是把所有波动都转化成延期和加班。我们现在的目标是"稳定在 75%~85% 的可承诺负载"，把剩下的部分当作系统的缓冲带，而不是浪费。

3. 跨部门真正的容量损耗发生在交接，不在执行

这是我们数据里最反常识的一条。我们原本以为研发执行阶段是最大的时间黑洞，把工时数据拉出来逐段分析后发现：一个需求从提出到上线，纯执行时间平均只占 38%，剩下 62% 花在等待上，等评审、等排期、等环境、等联调、等验收。而且交接次数越多，等待占比越高。

一个只跨 1 个部门的需求，平均周期是 9 个工作日；跨 3 个部门的需求，平均周期是 27 个工作日，但纯工作量只增加了 60%。也就是说，多出来的时间基本都消耗在交接的缝隙里。容量管理如果只盯着"每个人手上还有多少活"，永远看不到这部分损耗。

4. 没有优先级栈的容量计划，本质上是一张愿望清单

容量表回答的是"我们最多能做多少"，优先级栈回答的是"做不完的时候砍哪个"。只有前者没有后者，容量表在第一个冲突出现时就会失效，因为所有人都会主张自己的需求更重要。

我们现在的规则很简单：需求池里的每一项都带一个成本延迟排序分数，容量超载时从分数最低的开始自动出队，不需要开会讨论。这条规则省下来的协调成本，比任何效率工具都多。

5. 容量管理的产出是可预测性，不是更高的产出

如果只能用一个指标衡量容量管理是否成功，我会选"容量预测准确率"，上个季度承诺的交付量，实际完成了多少。这个数字从 60% 提到 85%，对业务方的价值远大于把团队产出硬拉高 10%，因为前者让业务敢做承诺，后者只会让所有人更不敢信计划。

二、为什么跨部门团队一算容量就失真

说完结论，回到现场。跨部门容量规划之所以难，不是因为公式复杂，而是因为每个部门都有一套自己的口径、自己的隐性工作、自己的时间尺度。下面三个场景，是我在三个不同组织里都遇到过的同一种病。

1. 场景一：三个部门、一张表格、四套口径

第一次做跨部门容量盘点，我们让研发、测试、设计各自报"本季度可用人力"。研发报的是"人数 × 工作日"，测试报的是"人数 × 工作日 × 0.8"（他们自己知道要留检修时间），设计报的是"按项目估算的人天"（不是按人算）。三份数据放进同一张表里，看起来都是人天，实际上根本不可加。

结果就是总量虚高。研发报的 1,240 人天里没扣会议和支持，测试报的 806 人天已经扣过，设计报的数字则是"需求需要多少"而不是"我们能提供多少"。一张混了三种口径的容量表，比没有容量表更危险，因为它会给你一种虚假的确定感。

2. 场景二：把支持性工作从容量里抹掉

几乎所有容量表都会漏掉同一类东西：线上问题处理、客户定制、数据修复、内部工具维护、面试、新人带教。这些工作不会出现在项目计划里，但它真实吃掉了团队的时间。

我们做过一次两周的工时抽样，让 34 个人逐条记录时间去向。结果是：计划内项目工作占 54%，计划外支持工作占 23%，会议与沟通占 14%，返工占 9%。也就是说，如果按"项目工作占 100%"来排容量，实际可用时间只有一半多一点。

更麻烦的是这 23% 的分布极不均匀。有两名核心后端工程师承担了全组 61% 的线上问题处理，他们的项目容量实际上只有同事的三分之一，但在表格上和别人长得一模一样。容量管理必须能看见这种"同岗不同量"的差异，否则关键路径永远排不准。

3. 场景三：项目制并行导致的隐形重复计算

跨部门组织最常见的结构是矩阵式：人属于部门，工作属于项目。在这种结构下，同一个人很容易被两个项目同时记为"50% 投入"，看起来刚好满负荷，实际上两个 50% 加起来并不是 100%，因为切换成本、上下文重建、会议重叠，会让两个半场工作的有效产出低于一个整场。

我们统计过一个季度里被两个以上项目共享的人员，共 27 人。他们的平均交付效率比专岗人员低 22%，而他们的容量在计划表上被计算为 100%。这是跨部门容量管理里最隐蔽的一类失真：数字上严丝合缝，现实里处处漏水。

4. 场景四：不同部门的时间尺度根本不同

研发按双周迭代排期，测试按版本节奏排期，运维按变更窗口排期，业务按季度目标排期。当这四种节奏被强行塞进一张季度容量表时，冲突不可避免。

我们的处理方式是承认差异而不是抹平差异：容量表以双周为最小颗粒度，以季度为汇总口径，每个部门可以有自己的内部节奏，但必须能映射到这两个公共尺度上。这比要求所有人改成同一种节奏现实得多，也更容易被接受。

三、六个误区：我们踩过的坑，以及为什么它们是坑

下面这六个误区，每一个我都在真实项目里见过，其中四个自己也犯过。把它们列出来不是为了罗列错误，而是想说清楚：很多容量管理失败，不是执行不到位，是判断本身反了。

1. 误区一：按人头算容量

这个错误最普遍，因为最省事。它的隐含假设是"人 = 可用时间"，而这个假设在知识工作里几乎从不成立。同样 20 个工作日，一个有 8 小时会议的人和一个有 2 小时会议的人，可用容量差 30% 以上。

正确的做法是按角色、按周期、按净可用时间算。一开始会觉得麻烦，但麻烦一次可以省掉后面无数次的"为什么又延期了"。

2. 误区二：把资源利用率当成效率指标

利用率高的团队看起来"很饱和"，但饱和不等于高效。一个 95% 利用率的团队，遇到任何一个插入需求都只能靠加班或者挤压测试时间来吸收，前者透支人，后者透支质量。

更糟的是，一旦利用率被写进考核，所有人都会开始调整分母：把估算时间拉长，把支持工作记成"杂项"，把学习时间藏起来。你得到的不是更高的效率，而是一份更漂亮也更失真的报表。

3. 误区三：不留缓冲，把计划排到 100%

缓冲经常被误解成"摸鱼空间"。但在跨部门系统里，缓冲的作用是吸收那些一定会发生但无法预知的事情：线上故障、需求临时变更、环境不可用、关键人请假。

我们现在的规则是把缓冲分成两块：项目缓冲 15%（针对单个需求的不确定性）和跨部门缓冲 10%（针对交接与排期冲突）。加起来 25% 看起来很多，但对比之前"计划排满、每月平均延期 3.2 个需求"的状态，实际交付量是上升的。

4. 误区四：没有统一的需求入口

只要有第二个入口，容量表就一定会失真。需求从邮件来、从群里来、从老板口里来、从客户成功那边来，每一个都绕过排序机制直接进入执行，容量规划就变成了事后记录。

统一入口不是为了管控，是为了让所有需求都进入同一套排序逻辑。没有入口统一，优先级机制无从谈起，容量表也就只能统计过去，无法预测未来。

5. 误区五：用容量数据做绩效考核

这是破坏性最强的一个误区。一旦"你的负载率"和绩效挂钩，所有人都会优化这个数字而不是优化工作：有人抢着接活把负载做高，有人把工作拆细显得很忙，有人拒绝协作以免自己的数字被摊薄。

我们的处理方式是把容量数据定位成"计划工具"，只在规划和排期场景使用，不进入个人评价。这条边界如果不划清楚，容量管理在第一年就会失去所有可信数据。

6. 误区六：只做年度规划，不做滚动校准

年度容量规划做完就锁进抽屉，是很多组织的常态。但跨部门环境里，人员、需求、优先级每个季度都在变，一份年度计划在第二个月就失去参考价值。

更实用的节奏是三层：季度定容量总量（人员与角色结构），月度做负载校准（需求进出与优先级），双周做排期确认（具体到迭代）。三层各有各的颗粒度，互不替代。

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

讲完误区，该给方法了。下面这套四层模型是我们在三个项目上迭代出来的，不复杂，但每一层都必须做，跳过任何一层都会让结果失真。

1. 第一层：口径统一，先定义尺子，再量东西

在算任何数字之前，先把四件事写进一份文档并让所有部门确认：容量单位、统计周期、角色划分、扣减项清单。这四件事不定清楚，后面所有数字都是各说各话。

我们的实际定义是这样的：

• 容量单位：角色人天（1 人天 = 1 名该角色成员 1 个标准工作日的有效投入）
• 统计周期：双周为最小颗粒，季度为汇总口径，年度只做趋势不做承诺
• 角色划分：后端、前端、测试、设计、运维、数据，允许一人多角色但需标注主角色与投入比例
• 扣减项清单：法定假期、会议、线上支持、行政事务、培训、面试、带教，逐项给出默认比例，部门可申请调整但需说明依据

这份文档最重要的作用不是精确，而是让争议有地方落。当有人质疑"为什么我们部门只有这么点容量"时，答案不是"我觉得"，而是"按第 3.2 条扣减项，你们的支持负载是 27%，可以拿工时记录来核"。

2. 第二层：净容量折算，把名义人力压成可承诺时间

这是整个模型里最需要动手的一层。核心是一个四步折算：名义工时 → 扣除非项目占用 → 乘专注系数 → 扣缓冲。每一步的系数都应该来自你自己的数据，而不是行业平均值。

from dataclasses import dataclass
@dataclass

class CapacityInput:

headcount: int          # 该角色人数

workdays: int           # 周期内工作日

hours_per_day: float = 8.0

meeting_ratio: float = 0.18      # 会议与沟通占比（来自工时抽样）

support_ratio: float = 0.15      # 计划外支持占比（来自工时抽样）

focus_factor: float = 0.75       # 专注系数：连续工作时间折算

buffer_ratio: float = 0.25       # 项目缓冲 15% + 跨部门缓冲 10%

def net_capacity(c: CapacityInput) -> dict:

gross = c.headcount * c.workdays * c.hours_per_day

after_meeting = gross * (1 - c.meeting_ratio)

after_support = after_meeting * (1 - c.support_ratio)

effective = after_support * c.focus_factor

committable = effective * (1 - c.buffer_ratio)

return {

"名义工时": round(gross, 1),

"扣除会议后": round(after_meeting, 1),

"扣除支持后": round(after_support, 1),

"有效工时": round(effective, 1),

"可承诺工时": round(committable, 1),

"折算率": f"{committable / gross:.0%}",

}

示例：62 名研发，季度 60 个工作日

print(net_capacity(CapacityInput(headcount=62, workdays=60)))

名义工时 29760 → 可承诺工时 9383，折算率约 32%

这个折算率看起来很低，但它是真实的。我们做过交叉验证：按可承诺容量排的计划，季度末的实际完成率是 87%；按名义容量排的计划，完成率是 54%。前者虽然数字小，但对业务的可用性高得多。

3. 第三层：需求侧排序，容量永远要和优先级配对使用

容量算完只是准备工作，真正的决策发生在"需求超过容量"的那一刻。这时需要的是一套不需要开会就能执行的排序规则。

我们用两层排序：第一层按业务价值分档（必须做、应该做、可以做），第二层在同档内按成本延迟排序，也就是"晚做一个季度会损失多少"。这个损失可以是收入、可以是合规风险、可以是客户流失，统一折算成一个分数。

排序机制的关键不是算法多精妙，而是所有人都提前认可规则，并且在超载时按规则出队而不是按声音大小出队。我们有一条硬规则：季度容量超载时，从分数最低的需求开始移出，移出清单在下个季度重新参与排序，不需要重新论证价值。

4. 第四层：负载调节，四种杠杆，用错顺序代价很大

当负载和容量不匹配时，可选的调节手段其实只有四种，但很多团队的默认顺序是反的。

把"加人"排在最后，是因为它是见效最慢、副作用最大的一种。新人上手需要 4 到 8 周，期间还会占用老人 20%~30% 的带教时间，短期内总容量甚至会下降。在跨部门系统里，加人还可能加剧交接复杂度，让原本就长的周期变得更长。

我们有个项目就是这样：进度落后时紧急加了 5 个人，两个月后复盘发现交付速度只提升了 8%，而协调会议时长增加了 40%。那次之后，我们把"先砍范围"写成了默认动作。

5. 判断标准：什么时候该做什么，我给三条线

第一条线：负载率低于 70%，说明容量有余量。这时候应该做的事是提前拉入下季度的中优先级需求，或者安排技术债与能力建设，而不是把余量当成团队懒散。

第二条线：负载率在 75%~85%，是健康区间。保持现有节奏，重点看交接等待和返工比例，这两个指标比负载率更能反映系统健康度。

第三条线：负载率持续超过 90% 两周以上，必须触发调节。这时候不要讨论"能不能扛一扛"，直接进入砍范围或延排期的决策流程。我们的经验是，超过 90% 之后每多撑一周，后续需要的恢复成本增加约 1.5 倍。

五、案例与数据观察：一个 200 人组织的三个季度

前面讲的是方法，这一节讲一个完整案例。这是一家 200 人左右的企业服务公司，产品、研发、测试、实施、运维分布在五个部门，长期存在"计划排得满、交付总延期、没人说得清卡在哪"的问题。以下数据来自三个季度的跟踪记录，部分为样本推演结果，用于说明趋势而非精确统计。

1. 起点：容量完全是个黑箱

介入之前，他们的容量管理方式是每月一次的资源协调会。各部门负责人在会上报"这个月大概能投入多少人"，项目经理凭经验分配。没有统一口径，没有工时数据，没有优先级机制。

第一个月我们做了一次基线测量：季度承诺的 68 个需求，实际按期交付 37 个，按期率 54%；平均交付周期 26 个工作日；跨部门交接平均等待 6.8 天；季度加班总时长 1,840 小时。最让人意外的是，被问到"卡在哪里"时，五个部门的答案完全不同，而且每个答案都能在局部数据上自洽。

2. 三个动作：统一入口、角色容量、跨部门负载视图

我们没有一上来就换工具，而是先改了三个机制，再用工具固化。

（1）统一需求入口

把所有来源的需求收进一个统一的需求池，每一条都带提出方、业务价值分档、预估工作量、涉及部门。邮件和群里提的需求不再直接进入执行，必须先入池。

这一步阻力最大，因为意味着业务方要等排期。我们的做法是给出承诺：入池的需求在 2 个工作日内一定得到明确答复，做、不做、还是什么时候做，而不是石沉大海。有了这个承诺，业务方逐渐接受了统一入口。

（2）建立角色容量基线

用两周工时抽样确定每个角色的扣减比例，然后把这个基线写进系统。这一步用的是 PingCode 的工作项工时字段和迭代容量设置：每个迭代开始时录入该迭代的角色可用工时，执行过程中按工作项记录实际投入，迭代结束时自动产生容量消耗对比。

对一家 200 人、多部门协作的组织来说，这套能力比较关键，容量数据必须落在具体工作项上，而不是靠月底手工填报，否则数据一定会被"整理"过。这也是我们选择在 PingCode 里做这件事而不是继续用表格的原因：表格能记录结果，但记录不了过程。

（3）跨部门负载视图

把五个部门的工作项汇总到一个跨项目视图里，按角色和周期查看负载率。这个视图每周更新一次，月度评审时作为唯一事实来源。

视图建立之后，第一个发现是：测试部门在三个项目上的负载叠加后达到 137%，而这三个项目的计划里，测试都被记为"50% 投入"。这个矛盾在原来的表格体系里完全看不见，因为每个项目各算各的。

3. 数据变化：三个季度的对比

三个季度之后，这组数字变成了这样：

需要说明的是，加班时长下降不是靠减少工作量实现的，同期交付的需求数量从 68 个增加到 79 个。真正的变化来自两处：一是负载从 137% 的测试瓶颈被摊平，二是有 23% 的返工被前置评审挡掉了。

4. 三个反常识结论

（1）加大投入不如减少交接

第一季度的改进里，有 4.4 天的周期压缩来自交接机制调整，只有 0.9 天来自增加人手。我们把测试介入提前到需求评审阶段，单个需求的交接次数从平均 3.2 次降到 1.8 次，效果远大于加人。

（2）负载不均是比负载过高更严重的问题

总负载率其实只从 96% 降到 82%，看起来变化不大。但内部结构从"研发 65%、测试 137%"变成了"研发 82%、测试 88%"。同样的总量，分布均匀之后，整体吞吐量提升了 27%。这解释了为什么有些团队看起来不忙却总是交付慢，瓶颈部门在拖整条链。

（3）工具的价值在于让数据无法被美化

这是我最想说的一点。用表格做容量管理，最大的问题不是算得慢，而是每个人提交的都是经过自我修饰的数字。当容量数据来自工作项的实际流转记录，而不是月底的手工填报，"我这个月大概能投入 80%"这类模糊表述就消失了。

在 PingCode 里做这件事的实际体验是：迭代容量在开始时录入，工作项在流转过程中自动累积实际投入，中间没有"填报"这个环节，也就没有修饰空间。对 100 人以上的组织来说，这种"过程即数据"的特性，比任何一张漂亮报表都重要。

5. 工具能解决什么，不能解决什么

把边界说清楚，比推荐工具更有价值。

工具能解决的：需求入口统一、容量与工作项绑定、跨项目跨部门视图聚合、负载超限预警、历史数据可比对。这些都是"记录与呈现"层面的问题，靠工具能一次性解决。

工具解决不了的：优先级规则谁来定、超载时谁让步、容量数据要不要进考核、部门墙怎么破。这些是治理问题，工具只能固化已有的共识，无法替代共识本身。

我们的教训是：先有机制，再上工具。反过来做的项目，最后都是在系统里重建了一套 Excel。

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

方法不能一刀切。下面按组织规模、组织类型和数据成熟度分成几类，给出可以直接执行的起步动作。

1. 50 人以下团队：不要做重型容量管理

这个规模下，人和事都在视野内，做复杂的容量模型收益很低。建议只做两件事：每周看一次"谁手上压了几件事"，以及把跨职能的活控制在每人不超过两件并行。

如果一定要量化，就用最简版本：每个人每周可承诺 3 个人天的项目工作，剩下的时间给会议、支持和意外。这个粗粒度数字比精心设计的模型更实用。

2. 100~300 人多部门协作：建立角色容量基线

这是容量管理收益最明显的区间。部门多了，口径必然分裂；人多了，靠记忆协调必然失效。起步建议按这个顺序：

1. 先做两周工时抽样，拿到本组织真实的扣减比例，不要用行业平均值
2. 定义角色容量单位和统计周期，写成文档并让各部门确认
3. 统一需求入口，配套"2 个工作日内答复"的承诺机制
4. 建立跨部门负载视图，每周更新，作为月度评审的唯一事实来源
5. 把容量数据明确排除在绩效考核之外，并公开说明

这个阶段用 PingCode 这类平台会比较顺，因为它能同时承载需求池、工作项工时、迭代容量和跨项目视图，不需要在四个工具之间倒数据。对 100 人以上的组织，数据搬运本身就是最大的失真来源。

3. 300 人以上多产品线：分层治理，不要追求一张总表

这个规模下最危险的想法是"做一张覆盖全公司的容量总表"。它要么粒度粗到没有决策价值，要么细到没人维护。建议改成三层结构：

• 产品线层：只做容量总量与需求总量的匹配，季度一次，颗粒度到角色
• 部门层：做角色的净容量与负载率，月度一次，颗粒度到人
• 团队层：做迭代容量与工作项分配，双周一次，颗粒度到任务

三层之间只传递汇总数字，不传递明细。这样既保证了上层有决策依据，又避免了下层被过度管控。

4. 项目型/交付型组织：按合同节点倒排容量

如果你的组织以交付项目为主，容量管理的锚点不是季度，而是合同节点。这时候要做的是"反向容量规划"：从交付日期倒推每个阶段需要的容量，再和实际可用容量对比，缺口提前暴露。

关键动作是把每个项目的容量需求提前锁定，形成跨项目的容量预约表。没有预约机制，多项目并行时一定会在最后一个月撞车。

5. 产品型组织：按价值流而非项目排容量

产品型组织的容量应该跟着价值流走，而不是跟着项目走。同一个价值流上的需求，即使来自不同业务方，也应该由同一批人连续处理，减少交接。

这时候容量表的重点从"项目占用"变成"价值流占用"。我们实践下来，按价值流组织容量的团队，平均交付周期比按项目组织的短 30% 左右，主要原因是上下文切换和交接次数都大幅减少。

6. 已经上了工具但数据不准：先修流程，别换工具

这是最常见的一种状态。数据不准的原因通常不是工具不好，而是三个流程漏洞：工作项没有真正流转（状态靠手工改）、工时没有真实记录（月底补填）、需求入口不唯一（一半的活在系统外）。

建议按这个顺序排查：先确认所有工作是否都在系统里，再确认状态流转是否反映真实过程，最后才看工时记录是否准确。顺序反了，就会一直在优化最不重要的那一层。

七、不同情况下的取舍

容量管理做到最后，会发现大部分决策不是"对与错"，而是"在哪一边多让一点"。这一节讲五组必须做的取舍，以及我们各自的选择和理由。

1. 精度 vs 成本：颗粒度越细，维护成本越高

容量可以精确到人天，也可以精确到小时，还可以精确到半天。每提高一档精度，维护成本大约增加 40%，而决策质量的提升往往不到 10%。

我们的选择是颗粒度停在"角色人天/双周"。理由很实际：决策发生在"这个双周我们能不能再接两个需求"这个层面，精确到小时对决策没有帮助，只会增加填报负担。

什么时候需要更细？只有当瓶颈部门的容量直接决定合同履约时，才值得把该部门做到半天粒度。按瓶颈精度配置颗粒度，而不是全组织统一精度。

2. 缓冲 vs 承诺：缓冲越多，对外承诺越保守

这是一组直接冲突。缓冲留 25%，对外承诺的容量就少四分之一，业务方会觉得你保守；缓冲留 10%，交付确定性下降，业务方会觉得你不可靠。

我们的取舍是对外承诺用 15% 缓冲口径，对内执行用 25% 缓冲口径。对外的 15% 是底线承诺，基本能兑现；对内的 25% 留出了调整空间，用于吸收突发需求。这样既保住了可信度，又保留了弹性。

关键是这个差异要公开说明，而不是偷偷留一手。一旦被发现有"隐藏缓冲"，所有承诺的可信度都会归零。

3. 集中管控 vs 部门自治：控制权放在哪一层

集中管控的好处是全局最优，坏处是响应慢、部门没有积极性；部门自治的好处是灵活，坏处是局部最优导致整体次优，前面那个"测试部 137%、研发 65%"的例子就是典型。

我们的做法是分层：容量总量和跨部门优先级集中管，部门内部的排期和人员调配自治。集中层只回答两个问题：总容量够不够、哪个需求先做。其他都不管。

这个划分能成立的前提是数据透明。如果集中层看不到部门的实际负载，就只能靠汇报，而汇报一定会失真。

4. 标准化 vs 灵活性：口径要不要统一到每个部门

理论上口径应该完全统一，实践中完全统一往往会失败，因为不同角色的工作性质差异太大。测试需要留回归时间，运维需要留变更窗口，设计的会议密度天然更高。

我们的折中是统一公式框架，允许系数差异。所有人都用同一套四步折算，但每一步的系数由各部门用自己的数据确定并公开。统一的是逻辑，不是数字。这样既保证了可比性，又尊重了差异。

5. 工具 vs 机制：钱该花在哪

很多组织的第一反应是买工具。但从我们的经验看，机制建设的投入产出比远高于工具采购。

顺序搞反的典型症状是：买了一堆报表，数据还是靠手工填；做了漂亮的容量仪表盘，超载时依然靠开会吵架决定砍谁。工具解决"看得见"，机制解决"改得动"，两者缺一不可，但机制必须先行。

八、结语：先做一张能被质疑的容量表

回到开头那个 120 人的项目。它最后没有靠加人解决，而是靠三件事：把 62 人的名义容量折算成 9,383 小时的可承诺容量、把测试提前介入把交接次数从 3.2 次压到 1.8 次、以及一份所有人都认可的出队规则。

如果这篇文章只能留下一句话，我希望是这句：好的容量表不是看起来精确的表，而是每一个数字都能被追问、也都能被追溯的表。能被质疑，说明它有依据；经得起质疑，说明它有数据。

下一步怎么做，我给一个 30 天的起步清单，按顺序执行，不要跳步：

1. 第 1 周：做一次两周工时抽样，只记四类，项目工作、计划外支持、会议沟通、返工。拿到你所在组织的真实扣减比例
2. 第 2 周：把容量单位、统计周期、角色划分、扣减项写成一页文档，发各部门确认。争议在这一步解决，不要留到算数的时候
3. 第 3 周：用文档里的系数做一次净容量折算，和名义人力对比，算出你们的折算率。这个数字本身就是最好的沟通材料
4. 第 4 周：挑一个跨部门需求，记录它从提出到上线的每个等待节点，算出等待占比。这个数字通常会让所有人重新理解"我们到底卡在哪"

这四步做完，你会得到两个数字：折算率和等待占比。它们不需要任何工具，不依赖任何模型，但足以让一场关于"资源不够"的争论变成一场关于"哪里在漏"的讨论。而后者才是容量管理真正要解决的问题。