Capacity流程与规范：跨部门团队资源负载制度设计关键指标

跨部门项目会上，产品、研发和市场负责人都说团队“已经满负荷”，但项目延期时，没人能回答：究竟是关键岗位过载、计划预留不足，还是同一批人被多个项目重复占用？Capacity 流程的价值，不是把每个人的日历填满，而是建立一套可核对的资源负载制度，让组织能在承诺工作之前识别约束、在执行过程中调整优先级，并在项目结束后验证预测是否可靠。

一、核心结论：Capacity 管的是承诺，不是把人填满

1. 先把容量定义成“可承诺的有效产能”

我设计 Capacity 制度时，通常先问一个容易被忽略的问题：团队说的“有空”，到底是合同工时、可用于项目的工时，还是已经扣除会议、支持、休假和不确定工作的时间？这几种口径如果混在一起，表格可以很精确，决策却会很不准确。

容量应指一个团队或角色在特定时间窗口内，经过合理扣减后，能够承诺给已排定工作的有效产能。它不是员工每天工作时长的监控值，也不是希望团队达到的利用率目标。把容量理解为“可承诺多少”，比理解为“能忙到什么程度”更适合跨部门决策。

最基础的计算可以写成：有效容量 = 可用工作时间 × 计划可投入比例 − 已知非项目工作 − 风险预留。其中，可用工作时间要扣除法定休假和已确认休假；非项目工作包括值班、客户支持、例行运维和必须参加的管理活动；风险预留则吸收需求不确定、依赖等待和突发事件。

例如，一个 8 人研发小组每人每周名义工作时间按 40 小时计，名义容量是 320 小时。但若会议与支持平均占 20%，已知休假折算 16 小时，另为不确定工作保留 10%，则可承诺容量约为 320 × 80% − 16 − 32 = 208 小时。若仍按 320 小时接活，超出的不是“效率空间”，而是未被显式承认的延期风险。

2. 制度的目标是提前暴露冲突，而不是追求满载

容量流程要回答四个问题：谁提供容量数据、谁确认需求、冲突由谁裁决、计划变化后何时重新预测。只发布一个利用率仪表盘，没有这四个答案，通常只是把问题可视化，却没有建立治理机制。

在我看来，合理的 Capacity 制度至少要同时满足三个条件：需求有来源、容量有口径、冲突有决策人。缺少需求来源，负载只是主观估算；缺少容量口径，部门之间无法比较；缺少决策人，超载信息会被反复讨论，却不会改变承诺。

对于 100 人以上、由产品、研发、测试、设计、数据、安全、市场等团队共同交付的组织，容量治理尤其重要。以 PingCode 这类面向中大型企业的项目管理平台为例，平台可以帮助团队汇总需求、计划和任务负载；但软件不会自动消除优先级冲突，流程仍需明确由谁决定“做什么、何时做、什么暂缓”。

3. 用四类指标构成决策闭环

不要只用利用率判断团队是否健康。我通常把指标拆成四类：输入指标检查需求质量，过程指标检查计划和变更，结果指标检查交付与预测，风险指标检查过载是否集中在关键角色。四类指标要相互解释，不能把单个数字直接当作结论。

这套结构的重点是把“忙不忙”转成“当前承诺是否可兑现”。若负载率在安全区间，但临时插单率持续上涨，团队可能正在被未登记工作侵蚀；若按期交付率很高，却长期依靠加班，也不能据此认定容量规划成功。

二、背景与真实场景：跨部门负载为什么容易失真

1. 一个项目的工时，往往分散在多个组织的账本里

在跨部门项目中，需求通常从业务或产品侧提出，技术方案由研发评估，测试与安全团队在后段加入，市场和客户成功又可能在发布日期前提出支持需求。每个部门都能说清自己的任务，却未必有人能看见同一资源被几个项目同时预订。

典型场景是：产品经理在季度计划中为功能项目预留设计资源，市场团队同时把同一位设计师排入发布物料，研发负责人又在临近上线时提出紧急交互调整。三个计划分别看都合理，放到人员日历上却发生冲突。问题不在个人“不配合”，而在组织没有统一的容量窗口和承诺入口。

还有一种更隐蔽的失真：共享岗位被按团队人数平均摊薄。例如，安全工程师只有 2 人，却被多个产品线的计划同时列为“可支持”。若每个项目都按 50% 预留，表面上每个计划都不超载，合并后却可能达到 200%。因此，容量要按约束角色和共享服务合并核算，不能只看项目团队自身的人员编制。

2. 周、月、季度三个时间尺度不能混成一个数字

季度容量适合判断投资组合是否可行，月度容量适合滚动调整，周度负载适合协调任务和依赖。三者不能互相替代：季度计划里的“一个人月”并不意味着这个人下周有空，周计划里的一次空档也不代表一个季度项目就有稳定资源。

我建议对不同层级使用不同精度。季度层面按团队、角色和工作类别估算，不要伪装成个人级精确预测；月度层面确认已知假期、里程碑和跨团队依赖；周度层面才处理具体负责人、任务顺序和短期插单。计划越远，表达越应是范围和置信度，而不是精确到小时的承诺。

如果组织用个人小时填满未来三个月，常见结果是“精确的假设”。需求还没冻结，依赖还没确认，估算却写成 37.5 小时。数字的小数位并不会提高预测质量，反而容易诱导决策者把预测当作承诺。

3. 真正的瓶颈通常不是总人数，而是稀缺能力

多数组织并非所有人都同时短缺，而是某些能力成为排队点：架构评审、数据治理、安全审查、特定平台开发、用户研究或发布审批。团队总容量可能有余量，但关键岗位的任务队列已超过交付窗口。

因此，容量数据至少要能按团队、角色或技能类别切片。若只显示“研发总体负载 82%”，管理者可能看不到后端开发还有空间、测试已超载、数据工程师被四个项目共同预约。对资源治理来说，平均数经常是最具迷惑性的数字。

对跨部门负责人而言，最有用的问题不是“团队还剩多少工时”，而是“哪一个关键角色会在什么时间段形成排队，以及哪些承诺依赖它”。这个问题会把容量从统计表转成依赖治理工具。

三、常见误区：看起来在算容量，实际在制造错觉

1. 把利用率越高越好，当成管理目标

高利用率不等于高产出。知识工作中存在切换成本、等待成本和返工成本；当团队把所有时间都预先分配，任何紧急缺陷、需求澄清或依赖延误都会迫使人员加班，或挤掉原有工作。系统表面满载，实际交付反而更脆弱。

把 100% 当目标还会引发行为扭曲：任务被故意拆小以填满空档，估算被压低以通过计划审查，例行支持被隐藏到“非项目时间”，而跨团队协助被视为个人效率损失。最终，数据越完整，真实负载反而越难看见。

我更愿意把利用率视为诊断信号，而不是绩效指标。低利用率可能表示需求不足，也可能是依赖阻塞、技能错配或预留设计合理；高利用率可能表示需求旺盛，也可能意味着组织没有留出处理变化的空间。要结合计划达成、变更和加班等结果判断。

2. 用平均人数掩盖关键角色超载

一个项目组有 20 人，其中 16 人负载率为 70%，4 名关键岗位负载率为 130%，整体平均仍可能看起来正常。但项目的交付路径由关键岗位决定，未完成的架构、安全或测试工作不会因为其他岗位有空而自动消失。

解决办法不是把每个人的工时都精确到分钟，而是识别关键能力与关键时段。对共享岗位，计划要显示需求窗口、预计工作量、优先级和替代方案；如果两个项目争同一个窗口，必须由有授权的组合负责人做取舍。

3. 把未确认的工作当作已承诺工作

路线图上常有“可能要做”“业务希望做”“等待审批”等项目。如果把这些工作全部当成确定负载，会让团队看起来长期超载；若全部不计，又会低估潜在需求。比较可行的办法，是分层标记需求的确定程度，并用情景容量表达影响。

例如，将需求分为已承诺、待决策和探索性三类。已承诺工作进入基线负载；待决策工作进入容量情景分析，标注最迟决策日期；探索性工作只记录规模范围，不占用正式承诺额度。这样既不会假装不确定性不存在，也不会让未知需求污染正式基线。

4. 把估算误差全部归咎于执行团队

预测偏差可能来自技术复杂度，也可能来自需求反复、等待审批、环境不稳定、跨团队交接和临时插单。只问“为什么没按估算完成”，容易把系统问题变成员工解释问题，下一轮计划依然使用相同的错误假设。

复盘时应把偏差拆解为可区分的来源：工作量估算偏差、范围变化、等待时间、返工、资源缺席和外部中断。团队可以对估算负责，但业务决策者也需要对频繁变更负责；依赖方需要对交付窗口负责；制度负责人则需要对统计口径负责。

5. 认为上了工具，容量治理就会自动成立

项目管理平台能够提高计划与任务的可见性，但前提是工作入口、字段口径、角色映射和审批责任已经确定。若不同部门仍用各自的优先级、工时单位和状态定义，系统只是更快地汇总互不兼容的数据。

使用 PingCode 等项目管理平台时，我会先确认三个问题：能否区分计划工作和非计划工作，能否按团队或角色汇总时间窗口负载，需求变化能否留下决策记录。若这三项尚未建立，先统一管理规则通常比先配置复杂仪表盘更重要。

四、专业判断逻辑：建立可运行的 Capacity 流程

1. 第一步：确定容量对象和统计口径

制度启动前，先决定容量按什么对象管理。小团队可按团队管理；多项目共用稀缺岗位时，应增加角色或技能视图；组织已具备稳定工作流并有可靠数据时，再考虑关键人员的细粒度计划。不要一开始就把所有人、所有任务、所有时段都要求按小时填报。

接着统一“工作量”的单位。可以使用人天、小时、故事点或团队吞吐量，但不要在同一张决策表里把不同单位混算。若使用故事点，它应服务于相对规模与团队计划，不应直接换算成跨团队的统一工时；若使用小时，则应明确记录的是估算工时、实际工时还是容量预订。

容量还应区分工作类别。产品交付、客户支持、运维、技术债、治理活动和休假最好不要混成一个“项目工作”字段。类别不是为了多做报表，而是让管理者知道容量被什么消耗，是否可以调整，是否需要新增资源或改变承诺。

2. 第二步：建立需求进入与分级机制

容量计划的入口应是经过最低限度评审的工作项，而不是所有口头请求。每项工作至少需要负责人、预期结果、优先级、目标窗口、估算范围、依赖团队和需求确定性。缺少这些信息的需求可以登记，但不能直接变成已承诺负载。

我通常建议设置三个门槛。第一，需求是否有明确业务结果；第二，是否存在完成定义和验收人；第三，是否知道关键依赖和最迟决策时间。未通过门槛的工作进入待澄清队列，不应与已批准的工作争夺同等容量。

分级机制不等于增加繁琐审批。对低风险、低成本的维护工作，可以采用轻量规则；影响多个部门、触及关键系统或占用稀缺能力的工作，则需要组合层面评审。制度应该把决策成本放在真正可能造成资源冲突的工作上。

3. 第三步：从名义容量推导可承诺容量

每个计划窗口开始时，先计算团队的名义容量，再扣除已知不可投入时间和长期责任。公式可以保持简单，但扣减项必须有一致口径。假期按日历计算，例行支持按历史或排班估算，会议按团队约定处理，风险预留则结合需求成熟度与交付环境确定。

风险预留不应成为“随手加一个百分比”的黑箱。需求稳定、依赖少、工作类型重复时，预留可以较低；新技术、跨部门依赖多、外部审批不确定时，预留应较高。初期没有足够历史数据，先明确标注为建议基准，运行数个周期后再用实际偏差校准。

需要特别避免双重扣减。例如团队已经把支持工作单独纳入工作计划，又在容量计算中再次扣掉同一批支持比例，就会低估可用容量；反过来，若支持工作既没进入容量扣减，也没进入工作计划，就会高估容量。每项时间只能在一个位置体现。

4. 第四步：按优先级和约束条件分配，而非按部门平均切分

当需求超过可承诺容量时，先看价值、时效、风险和依赖，不要默认所有部门按比例削减。平均削减看似公平，却可能让所有项目都变慢，却没有任何一项真正按期完成。优先级需要能转化为明确决策：哪些工作继续、哪些缩小范围、哪些延后、哪些取消。

我更倾向于用“优先级加约束”做组合判断。高价值但依赖未解决的项目，不应因为优先级高就无限挤占已具备交付条件的工作；低价值但法规或安全时限明确的工作，也不能只按商业收益排序。决策记录应说明收益、时间窗口、依赖风险和被牺牲的工作。

多个项目争夺同一角色时，负责人要看到资源曲线而非只有项目清单。管理者可以调整里程碑错峰、拆分交付、减少范围、临时借调或引入外部能力；但每个选项都有成本，不能只把负载从一张表转移到另一张表。

5. 第五步：设置滚动预测与变更触发条件

季度计划不是一次性预算。实际工作会受需求变化、人员缺席、事故和依赖延误影响，因此应建立滚动预测。较远窗口关注方向与情景，近期窗口确认可执行承诺；每次滚动时保留原计划版本，以便分辨是预测不准，还是决策改变。

变更不必每次都触发高层审批，但必须有明确触发条件。例如，关键角色负载连续两个周期超过警戒线、单个插单占用超过团队可承诺容量的一定比例、里程碑预测偏差超过约定范围，或需求变更影响已批准交付，都应触发复评。

复评的输出不能只是“大家再努力一下”。至少要记录决策、责任人、影响窗口、受影响工作和下一次检查时间。若选择接受超载，就应同时说明承担的风险以及何时退出超载状态。

6. 第六步：复盘预测质量，而不是用容量指标打分个人

每个周期结束后，把预测与实际进行比较，重点看团队层级的系统偏差。若某类工作连续低估，可能是估算模型、需求定义或依赖管理有问题；若实际耗时波动很大，可能是工作类型混杂、插单未记录或流程等待过长。

个人层面的工时数据需要谨慎使用。它可以帮助安排协作和识别负载冲突，但如果直接用于绩效排名，员工就会优化填报而不是改善交付。Capacity 制度首先是资源决策工具，不能悄悄变成个人劳动强度排行榜。

至少每季度检查一次制度本身：字段是否过多、数据是否仍能被用来做决策、会议是否缩短了冲突解决时间、预测误差是否下降。流程只有在减少盲目承诺和重复协调时才有价值；如果只是增加填表和汇报，就需要简化。

五、案例与数据观察：一个 120 人组织怎样识别“平均不超载、关键岗位已失控”

1. 案例口径与观察边界

下面用一个情景模拟展示判断方法，不把它伪装成某家企业的实测数据。设某数字化产品组织约 120 人，产品、研发、测试、设计、数据和安全团队共同支持多个产品线；每月进行一次组合计划，每周更新短期负载。

过去，负责人用项目总工时和部门人数判断资源是否够用。四个项目的总计划容量看起来低于组织可用容量，但交付仍连续延误。复盘后发现，安全评审和数据工程两个角色被多个项目重复预订；客户支持和紧急缺陷也没有进入容量基线。

我们把容量拆为已承诺交付、固定运行责任、风险预留和剩余可决策容量，并按角色查看峰值窗口。这个动作没有立刻增加任何人，但能把“谁都很忙”的争论转成“哪一周、哪类能力、哪些项目发生冲突”。

2. 计划前后的差异并非单纯来自效率提升

在情景模拟中，团队上线容量核算后，计划达成率从 68% 提升到 84%，但不能简单归因于工具或制度本身。关键变化是：待决策需求不再直接进入承诺；安全与数据资源按时间窗口合并；临时插单需要指定被替换的工作；每次滚动计划保留前一版基线。

与此同时，团队没有追求把利用率推到满载。相反，短期可承诺容量保留了风险余量，少数低优先级项目被明确延后。管理层看到的是更少的“所有项目都在进行”，以及更多关于何时能够兑现的真实信息。

这个例子说明，容量制度的收益首先体现为承诺质量，而不是每个人的工时突然增加。管理者如果只看任务完成数量，可能会误判为产出下降；如果同步观察按期交付、插单挤出和预测偏差，就能看出组织是在减少隐形延期。

3. 为什么不能把示意数据直接当作行业基准

上表是为了展示指标如何相互解释的情景推演，不是公开行业统计，也不能直接作为团队考核目标。不同组织的工作类型、支持责任、研发成熟度和需求波动差异很大。同样的 84% 计划达成率，对一个长期维护型团队和一个探索型团队，含义可能完全不同。

实际落地时，我会先收集至少三个完整计划周期的数据，保证跨越正常波动，而不是用某个“表现最好”的月份设目标。数据口径也要保持稳定：计划变更要留痕，未排期工作要有分类，未完成任务要区分工作量剩余和等待时间。

如果组织目前没有可靠的历史数据，可以使用建议基准做试运行，但必须注明这是初始假设。管理者应在复盘中逐步回答：实际支持工作占比是多少？哪些角色最常过载？什么类型的需求最容易低估？什么变化最常导致计划失效？这些答案比照搬一个利用率数字更有价值。

4. 用平台支撑数据流，但不把平台当裁决者

在 100 人以上的组织里，计划、需求、工作项和跨团队依赖常分散在多个团队。采用 PingCode 这类项目管理平台时，可以将需求来源、责任团队、计划窗口、优先级和工作状态关联起来，减少靠个人表格汇总的延迟。

实施时我会先限定最小可用字段：工作项类型、所属团队或角色、需求状态、计划窗口、负责人、估算口径、依赖关系、变更记录。只有当一个字段能支持具体决策，才值得要求全员填写。字段数量越多不等于治理越成熟，关键是数据能否支持一次真实的资源取舍。

平台中的容量视图应回答问题，而不是堆叠图表。例如，当某角色在未来四周超出可承诺容量时，系统要能追溯是哪几个项目占用、各项工作优先级如何、谁批准了新增需求。若只能看到一条红色曲线，却找不到冲突来源和决策人，管理价值有限。

六、不同情况下的行动建议：先处理最可能失真的环节

1. 团队规模较小、项目数量有限

小团队不需要复杂的资源系统。先用一页共享计划记录未来四至六周的工作、负责人、预计投入和固定支持责任，每周短会检查是否出现关键岗位冲突。重点是把口头承诺登记下来，而不是做个人级工时审计。

容量按团队或核心角色估算即可。若任务类型重复，可以用相对工作量或历史吞吐量规划；若工作差异很大，则用人天范围表达，并明确估算置信度。小团队最该避免的是为了追求精细管理而引入大量字段，导致计划维护成本超过决策收益。

2. 多个项目共用稀缺岗位

如果安全、数据、架构、设计研究或发布岗位被多个产品线共享，应把角色容量集中核算。各项目团队不能自行假定共享资源“会有空”；必须提交需求窗口、工作范围、优先级和不做的后果，再由资源责任人或组合委员会确认。

此时最有用的做法往往不是把估算做得更细，而是把需求错峰。若同一安全专家的评审窗口集中在发布前一周，提前安排设计评审、采用风险分级或拆分上线范围，可能比临时要求该专家加班更有效。

3. 临时需求频繁、业务变化快

不要假设所有临时需求都能消失。先定义一个可观测的“中断容量”，并记录实际消耗。如果临时工作长期稳定占用某部分容量，就应该把它纳入基线；如果是偶发事件，则保留机动空间并设定升级规则。

每次插单都要回答一个简单问题：它将替换什么？如果答案是“什么都不替换”，组织其实是在默认加班或延期。紧急程度可以决定谁来批准，但不能让代价隐形。对客户事故、法规要求或重大安全问题可开快速通道，同时保留事后复盘。

4. 需求成熟度低、探索项目多

探索型项目不适合用确定性很高的个人工时承诺。可以采用阶段门：先给探索阶段划定时间盒和角色上限，阶段结束后根据证据决定继续、调整或停止。此时衡量的不是“做了多少功能”，而是是否降低关键假设的不确定性。

容量计划应显示置信度，而不是用一个精确数值掩盖未知。对于方向不确定的工作，可提供低、中、高三种资源情景；把继续条件和停止条件写清楚，避免探索项目因已投入成本而长期占用稀缺资源。

5. 组织已经长期超载

如果关键角色负载持续高于可承诺容量，先暂停新增承诺，再按价值、法规时限、客户风险和依赖关系排序。不能只靠“优化流程”解决所有超载：若需求长期大于真实产能，最终仍需缩小范围、延后目标、改变服务承诺或增加能力。

增加人手也不是立即有效的答案。新成员需要培训和协作时间，短期可能增加已有团队的指导负担。对于高度专业、上下文复杂的岗位，优先考虑减少并行项目、改进自助能力、建立替补梯队或将低价值工作自动化，再评估招聘与外部支持。

6. 已有管理平台，但数据可信度不高

先不要扩大采集范围，而要抽样核对。随机选取几个团队和一个完整计划周期，核对系统里的工作项是否覆盖实际工作，容量扣减是否重复，临时支持是否有记录，负责人和角色映射是否正确。

如果数据误差主要来自字段含义不一致，就先改口径和培训；如果来自任务状态长期不更新，就简化状态并明确更新责任；如果来自工作绕过系统，则修复入口和管理要求。只有当数据来源稳定，仪表盘才值得成为治理例会的依据。

七、不同情况下的取舍：制度不可能同时最大化所有目标

1. 计划稳定性与响应速度

计划冻结得越严格，团队越容易聚焦，但对外部变化的响应越慢；插单通道越宽，业务越灵活，但原有承诺越容易被挤压。二者没有通用最优点，关键是明确哪些工作可以打断计划，哪些必须进入下一窗口。

高可靠性系统、法规时限和严重客户事故通常需要较快响应；长期产品建设则需要保护连续工作时间。成熟制度不是禁止插单，而是把插单分级、记录影响，并要求决策人明确承担被替换工作的后果。

2. 个人级精度与维护成本

按个人和小时排期能更快暴露直接冲突，却带来较高的数据维护成本，也可能被误读为个人绩效监控。按团队或角色汇总更轻量，但会隐藏个体不可替代性和具体窗口冲突。

选择原则是“精度跟着决策走”。如果决策是季度投资组合，团队级容量往往足够；如果要安排两周内的关键专家评审，则需要个人或具体资源窗口；如果没有人会根据个人级数据采取行动，就不应为了看起来精细而强制采集。

3. 高利用率与韧性空间

高利用率在需求稳定、工作重复、替代能力强时可能提高单位资源产出；在高不确定、依赖复杂、故障代价高的环境中，它会显著降低恢复能力。管理层要决定愿意为多少响应能力付出显性成本，而不是把缓冲当作浪费。

预留容量应该可解释、可复盘。若预留长期没有使用，可以检查比例是否过高，或是否被其他计划偷占；若预留每个周期都被耗尽，说明它不是冗余，而是组织实际需要的正常能力。

4. 统一标准与部门自主权

跨部门组织需要统一核心概念，例如计划窗口、需求状态、容量扣减和插单记录，否则数据无法合并。但不同职能的工作方式不同，不应强行统一所有估算技术。研发、客户支持、研究和运营可以保留适合自己的局部指标，只要能映射到共同的决策口径。

可采用“统一词典、分层规则”的方式：组织统一描述什么算承诺、什么算非计划工作、如何记录变更；部门自行选择工作量估算方式与操作节奏。这样既保留可比性，也避免把一种职能的管理方式套到所有团队。

5. 软件自动化与人工判断

工具适合汇总、提醒、追踪版本和呈现负载趋势；人仍然需要判断需求价值、风险承受度、工作替代关系和组织优先级。把所有冲突交给自动排程，可能得到数学上可行、业务上错误的计划。

因此，软件应让决策更快、更有依据，而不是替管理者隐藏取舍。系统提出超载预警后，应能让负责人追溯原因、比较选项并记录决定。自动化的目标是降低重复计算和信息遗漏，不是取消责任。

八、把制度变成习惯：一套可启动的 30 天实施顺序

1. 第一周：统一定义，不急着做仪表盘

先和业务、产品、研发、交付及支持团队确定容量对象、工作类别、计划窗口和承诺定义。挑选几个最常发生冲突的角色作为试点，不要求全组织一次性迁移。把需要回答的决策问题写出来，删掉暂时无法支持任何决策的字段。

这一周的交付物不是一套复杂报表，而是一页口径说明：谁提供数据、用什么单位、哪些工作计入、哪些工作扣减、如何记录临时变化。口径简洁且可执行，比字段完整但无人维护更重要。

2. 第二周：用历史计划做一次影子核算

选择最近一个完整周期，把已排工作、支持工作、休假、插单和实际交付进行回看。不要马上用结果考核团队，先识别重复扣减、漏记工作和估算偏差。若历史记录不完整，就把缺失项标出来，不要用臆测填补。

影子核算的价值在于验证流程能否看见实际冲突。例如，同一个人是否被两个项目同时预订，支持工作是否总在周末发生，测试需求是否集中到发布前。发现的问题应转成口径修订或计划规则，而不是单纯要求大家填得更认真。

3. 第三周：运行一次真实的组合决策

把未来四到八周的已确认需求按团队或角色汇总，找出超过可承诺容量的窗口。对每个冲突准备至少两个方案：延后、减范围、错峰、调配、增加支持或接受风险。让有授权的人在会议上作出决定并记录受影响工作。

会议的产出不是一张所有项目都排满的计划，而是一张组织认可的承诺清单。没有选择的工作仍然可以保留为候选需求，但必须标注状态和最早决策时间，避免在后续沟通中被误认为已批准。

4. 第四周：复盘并决定扩大还是简化

试点结束后，检查数据维护时间、冲突发现时间、插单影响是否可追溯、预测是否比过去更清楚。若一个字段从未被用来做决定，可以删除；若某类工作持续漏记，应调整分类或入口；若管理会议仍在重复核对数字，则需要改善数据责任和同步方式。

扩大范围时先复制稳定规则，再允许部门对工作估算方式作局部适配。不要把试点团队的缓冲比例、角色结构或交付节奏直接推广到所有部门。推广的是治理原则和数据口径，不是每个团队都应采用同一组数值。

九、结论：Capacity 的成熟度，体现在敢于说清楚“不做什么”

1. 用预测可信度替代表面忙碌度

容量管理最容易走偏的地方，是把它变成“让每个人更满”的制度。真正有效的流程应减少重复承诺、显式标记风险、提前发现关键角色冲突，并让组织知道哪些工作需要延后。负载数字只是证据，决策质量才是制度产出。

我判断一套 Capacity 流程是否成熟，会看三个结果：团队能否解释容量从哪里来，管理者能否在超载时做出有代价说明的取舍，复盘能否把预测偏差转化为下一轮改进。若这三件事成立，即使模型仍然粗糙，制度也已经有实际价值。

2. 下一步从一个瓶颈角色和一个计划周期开始

如果你准备启动这项工作，不必先覆盖全组织。选一个跨项目共享、经常导致延期的角色，回看最近一个计划周期，核对它被哪些工作占用、哪些请求临时进入、哪些承诺被挤出。然后统一容量口径，跑一次影子核算，再让负责人基于真实冲突作出取舍。

最值得保留的判断是：容量不是“有多少人”，而是“在给定时间、约束和风险下，组织愿意承诺什么”。当团队开始记录被推迟的工作、接受的风险和承诺变化的原因，Capacity 才从一张负载表变成跨部门的资源治理制度。