资源负载如何做好Capacity？PMO落地方案与操作步骤

资源负载做 Capacity，最常见的误判不是“人不够”，而是把每个人日历上的可用工时都当成可交付产能。一个团队名义上有 20 名工程师，每人每月按 160 小时计算，表面容量是 3,200 小时；扣掉会议、支持、休假、跨团队协作和技能不匹配后，真正能用于关键项目的时间可能只剩一半左右。PMO 的任务不是把工时填满，而是建立一套能回答“谁在什么时间、凭什么技能、以多大把握完成什么”的决策机制。

一、先讲结论：Capacity 不是排满工时，而是管理承诺边界

1. 把“容量”定义为可交付能力，而不是在岗时间

我建议 PMO 先统一一个定义：Capacity 是一个团队在指定周期内，扣除不可避免的运营负担后，能够稳定承接的工作量。它不是员工合同工时，也不是资源表中剩余的空格，更不是项目经理争取到的预算人天。

这个定义有三个限定。第一，周期必须明确，例如周、月或季度；第二，工作量必须经过统一口径换算；第三，容量必须和技能、角色及不确定性绑定。一个前端工程师空出 40 小时，并不等于团队多了 40 小时数据工程能力。

因此，PMO 在讨论 Capacity 时，应同时呈现三个数字：理论容量、可计划容量和已承诺容量。它们的差值比单独的“剩余工时”更有用，因为差值能暴露团队的运营负担、排期风险和资源冲突。

2. 先看负载率，再看绝对工时

容量管理的核心指标可以从负载率开始：已承诺工作量除以可计划容量。若某个岗位组本月可计划容量为 100 人天，已承诺 115 人天，负载率就是 115%。但这并不意味着团队会自动多产出 15%；更可能意味着延期、加班、质量下降或其他工作被隐性挤出。

我不会把 100% 视为理想目标。知识工作存在沟通、返工、突发支持和估算偏差，排期贴满意味着没有吸收波动的空间。对于需求变化频繁、线上支持较重的团队，PMO 应根据历史数据设定可承诺上限，而不是把理论容量全部分配出去。

下图是一个用于说明口径的情景模拟，不代表行业统计。它展示了从理论工时逐步扣除非项目时间后，计划空间如何收缩。实际企业应以至少数个周期的工时、迭代和缺勤记录校准。

3. Capacity 应服务于取舍，而不是制造精确感

容量表不可能让未来变得确定。它的价值在于把过去靠口头协调的资源冲突，转成可讨论的选择：延期哪个里程碑、减少哪个范围、借调哪类技能，或者接受多大风险。

如果一个看板只显示“某人负载 132%”，却不能说明负载来自哪些事项、哪些承诺可以调整、由谁做决策，那么它只是可视化了焦虑。PMO 应把资源数据接到治理动作上，确保每一个超载都能触发明确的处理路径。

二、背景与真实场景：为什么项目多了，团队反而更难交付

1. 矩阵组织里的资源冲突，通常先表现为时间碎片化

在中大型组织中，同一个专业人员可能同时服务多个项目：参与需求澄清、技术评审、线上问题、专项治理和部门例会。项目计划往往把他分配给四个项目，每个项目各占 25%，但真实工作并不会按比例整齐切分。上下文切换、等待决策和临时插单会侵蚀可用时间。

我在梳理资源计划时，会特别追问“这个人每周有几段连续可工作的时间”。如果一位架构师每周被拆成 10 个短时段，即使总工时看起来合理，也可能无法完成需要连续专注的设计任务。Capacity 不仅是时间总量，还包括时间块的完整性和依赖关系。

例如，某产品团队计划在一个月内完成接口改造，开发估算为 20 人天，测试估算为 8 人天。表格上总量只有 28 人天，但如果接口负责人每周仅能投入半天、测试环境又要等另一团队排期，项目可能持续数周。单看工时总量，会低估等待和协调造成的周期延长。

2. PMO 面对的不是一张资源表，而是一条需求到承诺的链路

容量问题通常从多个入口同时发生：业务部门提出需求，产品团队排路线图，项目经理确认里程碑，职能经理安排人员，运营团队还要承担故障和例行工作。每一方都可能使用不同口径，导致同一名员工在不同计划里被重复计算。

落地时，我会把链路拆为五个节点：需求进入、优先级判断、能力评估、资源承诺、周期复盘。需求没有通过优先级判断前，不应占用正式项目容量；评估没有确认技能和依赖前，不应承诺交付日期；承诺之后，变更必须说明替代项。

以服务中大型企业和百人以上组织的项目管理平台为例，PingCode 可以作为需求、项目、迭代与工作项协同的业务场景载体：组织可以把需求优先级、负责人、预计投入和迭代安排关联起来，再由 PMO 定期核对资源承诺。工具本身不会自动解决容量治理，关键在于先定义字段、权限、审批与更新责任。

3. 容量管理的成熟度，取决于组织是否愿意暴露冲突

不少组织的资源表看起来整齐，是因为冲突没有被记录。项目经理私下借人、员工晚间补工时、职能经理口头承诺支援，这些动作让报表暂时平衡，却让真实容量越来越不可见。

PMO 应把“没有冲突”与“冲突被解决”区分开来。前者可能只是没有上报，后者才代表管理有效。资源会议要允许团队说明不可行性，并要求决策者在范围、时间、资源和风险之间做明确选择。

三、常见误区：为什么资源表越精细，预测反而越不可信

1. 用 100% 利用率作为管理目标

把利用率拉到 100%，看上去像是消除了闲置，实际是把系统缓冲也一并消除了。只要需求波动、线上问题或估算偏差出现，团队就只能通过加班、延期或降低质量吸收冲击。

对稳定、重复、可替代的工作，较高利用率可能可行；对高度依赖专家判断、跨团队协作或创新探索的工作，满载会明显增加交付风险。PMO 应监测的是产出稳定性和承诺兑现率，而不是单独追求每个人的忙碌程度。

2. 把人天当成跨岗位的通用货币

一个人天可以描述投入时间，却不代表不同岗位产出可以互换。两名测试人员的 10 人天、一个架构师的 10 人天和一个业务专家的 10 人天，不能简单相加后推断项目一定能完成。

容量模型至少要区分关键角色或技能组。常见维度包括产品、研发、测试、数据、安全、运维和业务专家。角色划分不必无限细，但必须能识别关键路径上的稀缺能力。

3. 只看个人负载，不看团队吞吐和依赖

个人负载视图容易制造“谁忙谁不忙”的讨论，却不一定能解释项目为什么卡住。真正影响交付的可能是代码评审积压、测试环境共享、决策等待，或者某个外部接口迟迟没有确认。

我会把个人负载与团队层面的工作流指标一起看，例如在制工作项数量、等待时间、返工比例和周期完成量。若工程师看似有空，但工作项长期停在“等待验收”，新增人手可能只会把堵塞推向下游。

4. 把估算数字当成事实，把风险缓冲当成浪费

新项目的估算通常包含假设，而不是事实。需求清晰度、技术方案、数据质量、供应商配合和测试环境都会影响实际投入。若计划只呈现一个数字，例如 120 人天，决策者就容易误以为结果确定。

更好的做法是记录估算范围、依据和置信度。对于依赖较多的项目，可以用区间表达，例如 100 至 140 人天，并说明中位估计和触发上限的条件。缓冲不是随意加码，而是对明确不确定性的管理。

5. 把员工填写的投入时间直接等同于未来产能

实际工时可用于识别投入结构，却不能机械外推。某个周期加班较多，不代表下一周期也可以按同样节奏安排；某团队过去低投入，也可能是因为项目等待外部依赖，并不意味着它有可自由调度的空闲。

历史数据必须结合结果解释：投入增加是否带来完成量增加，还是只带来返工和缺陷？计划偏差来自估算、范围变更、人员缺席还是依赖等待？不追问这些原因，历史平均值很容易把异常固化成“标准容量”。

6. 用平均值掩盖关键人的单点风险

一个团队平均负载 80%，并不代表风险低。如果唯一熟悉核心系统的工程师负载 150%，其他成员即使有余量，也无法立即接手。平均数会遮蔽技能集中、知识单点和审批瓶颈。

PMO 应同时检查岗位组负载、关键技能覆盖和替补能力。短期内不能消除单点时，至少要把风险登记出来，并通过结对、文档、轮岗或范围调整降低依赖。

四、专业判断逻辑：PMO 如何把容量从“表格”变成“可决策模型”

1. 先建立四层容量口径

我建议从组织、团队、技能组和个人四个层级建模。组织层用于观察总体需求是否超过供给；团队层用于比较产品线和部门的承诺；技能组层用于识别瓶颈岗位；个人层只用于排期协调和风险核验，不应成为单纯的绩效排名依据。

层级越往下，信息越敏感、更新成本越高。PMO 不必要求每名员工精确填报每小时去向，而应按决策需要收集最小必要数据。季度资源组合管理关注技能组和项目群；两周迭代计划才需要落实到个人工作项。

2. 用历史交付校准容量，不从标准工时倒推承诺

如果团队已经稳定运行迭代，可以参考过去数个周期的完成量和承诺兑现情况。对采用故事点的团队，观察团队自身完成量，不要把不同团队的点数直接比较；对按人天管理的团队，结合实际投入、范围变化和完成情况判断估算偏差。

历史数据不应被当作机械预测器，而是容量假设的校验器。比如某团队连续六个周期，原计划平均 50 个工作项，实际完成 38 个，不能直接把未来计划改成 38 个；要先拆清楚未完成原因。如果 12 个差额大多由需求临时变更造成，解决入口治理可能比增加人手更有效。

对于新团队、新技术或历史数据不足的项目，我会采用区间估算，并把关键假设写在计划旁边。容量模型可以先不精细，但必须诚实呈现不确定性，避免小数点精确、判断却没有依据。

3. 负载率之外，至少联合观察五类信号

• 承诺兑现率：按期完成的承诺量占周期承诺量的比例，需同时标注范围是否发生变更。
• 在制工作量：正在进行但尚未完成的事项数量，过高通常意味着注意力被拆散。
• 等待时间：工作项处于等待评审、验收或外部输入的时长，用于识别非人力瓶颈。
• 计划外工作占比：突发支持和紧急事项占总投入的比例，可用于调整下一周期缓冲。
• 关键技能覆盖率：关键岗位是否有可替补人员，识别单点依赖及交付连续性风险。

这些信号需要组合解释。例如，负载率 90% 且兑现率稳定，可能说明团队运行健康；负载率 70% 但等待时间很长，则可能是流程或依赖阻塞；负载率 110% 且计划外工作持续增加，通常意味着当前承诺已不可持续。

4. 把“容量缺口”拆成四种可处理的问题

同样是容量不足，处理方式可能完全不同。第一种是总量不足，可能需要缩小范围、延期或补充人员；第二种是技能缺口，适合培训、借调、外部支持或调整技术方案；第三种是时间冲突，适合重排里程碑和减少并行工作；第四种是流程阻塞，应优先解决审批、环境或决策等待，而非立即增加人手。

PMO 不能只给出“缺 30 人天”的结论，还要说明缺口属于哪一类、影响哪个里程碑、有哪些备选动作，以及每个动作的代价。这样管理层才能进行真正的组合取舍。

5. 采用情景计划，而不是争论唯一日期

对于高优先级但不确定性较大的事项，我更倾向于准备三个情景：基准方案、保守方案和加速方案。基准方案说明正常资源与范围下的预计交付；保守方案说明依赖延期或计划外工作增加时的影响；加速方案说明额外资源能换来什么，以及是否存在学习和协作成本。

这不是给同一个项目同时报三个日期，而是把管理层真正需要做的选择显性化。例如，若增加两名人员只能在一个月后到位，短期内可能还要承担熟悉系统的成本，不能简单按两个人天数直接折算成新增产能。

五、具体案例与数据观察：从容量表看出真正的瓶颈

1. 案例口径：用一个虚构团队演示完整计算

以下案例是用于说明方法的情景模拟，不是客户实测，也不应被引用为行业平均值。假设某数字化产品团队共 20 人，成员分布在产品、研发、测试和运维支持岗位，周期为一个月。团队每人按 20 个工作日计算，理论容量为 400 人日。

团队根据过去数个周期的排班和工作记录，估计休假与节假日占用 32 人日，例会和跨团队协作占用 55 人日，线上支持及维护占用 70 人日。再为需求变化、临时缺陷和依赖波动保留 15% 的缓冲。扣除后，可用于新增承诺的容量约为 206 人日。

这个计算并不意味着所有岗位都可以互相替代。实际排期仍要拆成角色容量：产品 24 人日、研发 112 人日、测试 42 人日、运维支持 28 人日。四类相加为 206 人日，但只要其中一个关键角色超载，项目就可能无法按整体总量推算的日期交付。

2. 从表面缺口追到角色瓶颈

假设团队已承诺两个产品项目和一个合规专项，共 218 人日，整体超出可计划容量 12 人日。单看总量，管理层可能会要求团队“再挤一挤”；拆分后发现，研发剩余容量为 112 人日、计划投入 125 人日，缺口 13 人日；测试尚有 5 人日余量，运维则因专项任务短期过载。

此时，平均负载并不能解决问题。若新增一名测试人员，研发缺口仍然存在；若从研发抽调人员补运维，核心开发工作可能继续延期。合理动作可能是缩小一个项目的非关键范围，把合规专项中的可延后任务移出本周期，再安排架构负责人集中支持两周。

容量会议要把代价写清楚。比如：方案 A 不扩人，合规专项延后两周；方案 B 暂停产品项目的两个非关键功能，保留里程碑；方案 C 临时借入研发人员，但需要一周熟悉系统，短期产出有限。选择哪个方案，不是 PMO 单方面决定，而是由业务价值责任人和交付负责人共同确认。

3. 观察承诺与实际偏差，找到缓冲该放在哪里

假设团队连续三个周期的计划外支持分别占可计划容量的 12%、17% 和 14%。若 PMO 仍按 5% 预留支持缓冲，项目计划会持续被突发工作打断。合理的做法不是把 14% 永久固化成标准，而是区分其中多少是必要值班、多少是重复故障、多少是临时流程缺陷。

进一步看，如果计划外工作中 60% 来自同一类线上问题，修复根因可能释放未来容量；如果主要来自不稳定的业务入口，则应调整需求优先级和应急机制。容量数据因此不仅用于排期，也能帮助识别“持续吞噬产能”的系统性问题。

下图中的数据为情景模拟，用来示范不同类型投入如何影响剩余容量。实际企业应按工作类别记录至少数个周期，再决定缓冲比例。

4. 从案例里得到的三个判断

第一，团队容量不是“人数乘以标准工时”的静态结果，而是会被支持、协调和变更持续影响的动态供给。第二，资源总量够不够，与关键岗位够不够，是两个不同的问题。第三，计划外工作不是只能被动接受的噪声，长期重复的计划外工作可能是流程、产品质量或治理机制的改进信号。

我会要求项目负责人提交资源申请时至少写清三项内容：希望获得的技能和时间窗口、该资源对应的业务结果、如果无法获得资源时优先调整的范围或日期。缺少第三项的申请，往往仍停留在“希望全部照常完成”的愿望层面。

六、PMO 落地方案：从制度、数据到会议机制逐步建立

1. 第一步：确定管理边界和决策对象

先明确 Capacity 管理覆盖哪些团队、哪些工作和哪些周期。试点时不建议把所有部门、所有非正式协作都纳入系统。可以先选一个项目密集、跨职能明显、负责人愿意参与的产品线，覆盖正式项目、运营支持和已批准的改进事项。

同时确定哪些事项占正式容量：已批准项目、法律合规任务、线上支持、部门固定运营是否纳入；探索性想法和待评审需求是否只进入候选池。边界不清会使团队既要录入大量低质量数据，又无法判断哪些数字真正影响承诺。

2. 第二步：统一数据字段，但避免过度收集

PMO 的初版模型可以包含：周期、团队、技能组、工作事项、负责人、计划投入、实际投入或估算完成量、优先级、状态、外部依赖、风险等级和变更原因。字段的目的不是把管理变成填表，而是让容量计算和资源决策有依据。

如果企业使用 PingCode 等项目管理平台，可将需求、项目、迭代和工作项关联起来，并通过权限与流程控制正式承诺的入口。对于已有工时或财务系统的组织，不要急于重复录入；先确认数据来源权威性，必要时通过接口同步，避免同一个人同时维护多份资源台账。

个人层面的投入记录尤其要谨慎。只收集决策需要的信息，说明数据用途和查看权限，不把容量规划数据直接当成员工绩效排名。否则员工会倾向于填报“看起来合理”的数字，系统最终获得的是表面精确、无法用于预测的数据。

3. 第三步：做一次基线测量，而不是先设理想目标

试点开始时先测量 4 至 8 周，或覆盖两个以上可比较的交付周期。基线阶段不必急着规定“每人每周必须录满多少小时”，而应关注计划和实际之间的差异：计划外工作占比、等待时间、承诺兑现率、关键岗位负载和范围变更次数。

样本不足时必须标注限制。例如，刚成立的团队、重大版本发布周、集中休假月都可能造成偏差。PMO 应把数据按团队类型解释，不要拿一个团队的数值直接作为全公司的考核线。

4. 第四步：设计滚动规划节奏

建议把长期组合规划、中期容量确认和短期排期分开。季度或月度层面决定哪些事项进入承诺池；每两周或每月复核人员与技能容量；每周只处理临近工作的冲突、缺勤和依赖变化。所有事项都在同一个会议里讨论，会让治理成本快速上升。

在滚动规划中，远期承诺可以更粗，越接近交付，信息越细。未来一个季度只需确认技能组供需与关键里程碑；下一个月确定团队投入；当前迭代才落实到具体负责人和任务。这种逐步细化比一次性排满三个月更符合信息成熟度。

5. 第五步：明确超载阈值与升级规则

阈值不应只看单一百分比。组织可以设置管理提示区间，例如岗位组负载接近可计划容量时要求负责人复核，超过可计划容量时必须提交调整方案；关键岗位连续多个周期过载则升级到组合治理会议。具体阈值要用试点数据校准，不宜照搬其他企业的数字。

升级规则需要回答：谁能批准新增承诺，谁有权调整范围，延期由谁确认，紧急事项如何插入，插入之后原有哪项工作被挤出。若“紧急”没有定义，也没有替代机制，所有需求都会争取成为紧急事项。

6. 第六步：建立会议产出，而不是只建立会议

容量评审会的产出应是一份决策记录，而不是一张讨论纪要。记录至少包括：当前缺口、涉及项目和岗位、选项、被调整的工作、责任人、决定日期及复核时间。没有决策人的超载清单，只会重复提醒同一问题。

会议中应优先讨论三类例外：负载显著超出计划的岗位、关键里程碑可能失守的项目、计划外工作持续上升的团队。其他稳定事项通过数据看板异步处理，避免所有项目都花时间重新汇报一遍。

7. 第七步：每个周期做偏差复盘，持续校准模型

周期结束后，PMO 应比较计划、实际和完成结果，并将偏差归类：估算偏差、范围变更、人员缺席、技能不匹配、外部等待、计划外支持和质量返工。分类的目标是找到可改变的原因，而不是追究“谁填错了数字”。

如果某种偏差连续出现，就要调整流程或容量假设。例如，测试阶段总被压缩，可能是开发计划过于乐观，也可能是测试环境准备太晚；不应简单把测试容量下调后接受更长的排队时间。

七、按组织情况选择行动：轻量试点与规模化治理不能照搬

1. 团队小、项目少：先做简单的供需表

人数少、协作关系简单的团队，不需要一开始搭建复杂的资源管理系统。用统一的项目清单、技能分组和周期容量表，就能识别主要冲突。重点是明确哪些工作是正式承诺，并固定每周或每两周检查一次。

小团队的最大风险通常不是数据不足，而是负责人兼任多种角色、突发事项无法区分。先记录计划外工作和关键人员依赖，比精细记录每小时投入更有价值。

2. 多项目并行、矩阵协作明显：优先治理技能瓶颈

项目多、人员共享明显时，应从技能组容量切入。先识别架构、安全、测试、数据和业务审批等稀缺能力，建立跨项目资源视图。项目组合会议要解决“先做什么”，团队层会议再解决“怎么排”。

这类组织常见的陷阱是让每个项目经理分别向职能经理要人，最后所有项目都得到部分承诺，却没有项目获得完整可用的时间。PMO 应推动资源负责人对完整时间块做承诺，并记录借调起止日期。

3. 运营和突发工作占比较高：先把不可预测工作显性化

若团队承担值班、客户支持或线上保障，不要把所有人员都按纯项目产能排满。应区分固定运营、可预期专项和真正突发事件，分别测量其时间与波动。可以通过轮值、专人支持或故障治理，减少项目团队被持续打断的比例。

但为突发事件预留容量也有代价：缓冲过大可能使短期项目承诺偏少。PMO 应根据历史周期校准，并定期检查预留时间是否被实际使用，以及未使用部分是否能用于提前处理技术债务或改进工作。

4. 数据基础薄弱：从少量关键指标开始

如果项目状态、工时和范围变更都没有统一口径，不要急着做精美的负载热图。先确保每个正式工作有负责人、优先级、周期和状态，再记录计划外工作与关键依赖。数据质量提高后，再增加投入量和技能容量字段。

最初几个月应把数据用于校准而非考核。团队需要知道为什么要提供数据、数据会被谁查看、哪些决策会据此改变。没有信任和用途说明，系统就会变成重复填报的负担。

5. 百人以上、中大型企业：把平台配置和治理规则一起设计

当组织达到多个业务线、多个项目群并行的规模，单靠共享表格容易出现版本冲突、口径分裂和审批不可追溯。此时可以使用项目管理平台串联需求、工作项、项目、迭代和资源信息，但需要先完成角色权限、数据字典和升级规则设计。

以 PingCode 的企业项目协作场景为例，PMO 可以将需求进入、评审通过、项目立项和迭代承诺设置为不同状态，并在工作项中维护负责人、计划投入和依赖关系。要特别避免把“平台里有资源字段”误认为容量治理已经完成。字段的更新责任、正式承诺的批准人和超载后的处理规则必须明确。

八、取舍与避坑：哪些数字值得追，哪些流程应该克制

1. 时间精度与维护成本之间要取舍

按小时记录能提供细节，却会增加填报和核对成本，也容易鼓励员工把注意力放在工时拆分上。按人天或工作项估算更轻，但不适合所有财务结算场景。PMO 应按决策用途选择粒度，不要为了看起来精确而要求团队维护没有实际用途的数据。

如果目标是项目组合预测，周或迭代级别通常足以支持取舍；如果涉及客户计费、合同交付或严格审计，可能需要更细的工时记录。两类用途应明确分开，避免把运营记录直接当作容量预测模型。

2. 统一口径与团队自主性之间要取舍

统一口径让组织能够汇总，但过度统一会忽略团队差异。稳定运营团队、研发团队、咨询交付团队和实验型产品团队，工作节奏并不相同。组织可以统一“可计划容量”“计划外工作”等定义，同时允许团队选择适合自己的估算方式。

PMO 的职责不是强迫所有团队使用同一套工时单位，而是确保汇总层能解释数据的含义、边界和可比性。不能直接比较的指标，应明确标注，而不是制作一张看似统一的排行榜。

3. 透明度与心理安全之间要取舍

资源透明有助于发现冲突，但如果个人负载数据被用于简单排名，员工可能会隐藏工作、夸大投入或回避帮助他人。建议默认以团队和技能组为主要管理视图，个人级数据仅用于具体排期、冲突核验和经授权的管理需要。

公开资源冲突时，应聚焦工作安排、决策权和系统性瓶颈，而不是把个体描述成“效率低”。Capacity 是组织承诺是否合理的工具，不是给员工贴标签的工具。

4. 缓冲与承诺之间要取舍

缓冲太少，稍有变化就延期；缓冲太多，组织可能觉得团队低效。解决方式不是争论一个放之四海而皆准的比例，而是区分不确定性的来源，并建立可复核的缓冲假设。

例如，固定值班、历史故障波动、需求变更和新技术探索应分别处理。可预测的运营工作应纳入基线；突发风险用缓冲吸收；重复发生的故障则通过改进减少。把所有不确定性都塞进一个“预留 20%”，既不透明也难以改进。

5. 工具自动化与管理判断之间要取舍

平台可以汇总负载、提醒冲突、关联项目状态，却不能替组织判断哪个需求更有价值、哪个风险可以接受、哪项工作应该延期。自动化适合减少重复统计和遗漏，不适合替代优先级讨论与责任承担。

先把管理规则设计清楚，再自动化执行。若规则本身鼓励所有项目并行、所有需求都紧急，系统只会更快地放大混乱。

九、最终落地清单：接下来四周可以怎么做

1. 第一周：统一定义与试点范围

• 明确理论容量、可计划容量和已承诺容量的计算口径。
• 选择一个项目密集、跨职能协作明显的团队或产品线试点。
• 确认哪些工作纳入正式容量，哪些只进入候选需求池。
• 指定业务负责人、资源负责人和 PMO 数据维护责任人。

2. 第二周：建立基线数据

• 整理人员、技能组、周期和已批准工作事项。
• 记录休假、固定运营、计划外支持与关键依赖。
• 给每项承诺补充优先级、预计投入和变更责任人。
• 标注数据缺失和估算不确定性，不为追求完整而填入虚假精确值。

3. 第三周：召开首次容量评审

• 按团队和技能组展示可计划容量与已承诺容量。
• 优先讨论超载岗位、关键里程碑和持续上升的计划外工作。
• 为每个缺口准备至少两个可选方案，并说明成本。
• 记录决策人、被调整事项、责任人和复核日期。

4. 第四周：复盘并修正模型

• 比较原计划、实际投入、完成结果和范围变化。
• 把偏差归类到估算、技能、等待、支持、人员变化或流程问题。
• 确认哪些字段真正影响决策，删除没有使用价值的填报项。
• 决定是否扩大试点，以及扩大前需要补齐的治理规则。

四周结束后，不要急着宣布全公司上线。先回答三个问题：容量数据是否改变过一次真实取舍？团队是否愿意持续维护关键字段？管理层是否按约定处理过超载和插单？如果答案是否定的，优先修正决策机制，而不是继续增加报表和系统配置。

十、结语：Capacity 的本质，是让组织对“做多少”负责

资源负载管理的独特价值，不在于把每个人的日历填得更满，而在于让组织停止把所有工作都当成同时可交付。理论工时只能描述供给上限，可计划容量才接近现实；总量平衡只能说明表面供需，技能瓶颈、时间碎片和外部等待才决定交付是否可行。

我建议 PMO 下一步先选一个真实项目组合，按“理论容量，可计划容量，已承诺容量”重算一次，并把超载拆成总量、技能、时间冲突和流程阻塞四类。然后在下一次资源评审中，要求每个新增承诺同时说明它要替代什么。当组织能够公开做出取舍，Capacity 才从资源表变成治理能力。