Capacity流程与规范：PMO资源负载制度设计关键指标

Capacity制度最容易失灵的时刻，不是团队没有人，而是每个人看起来都很忙，项目却仍然延期：同一位架构师被三个项目按“百分之五十投入”重复占用，研发经理看到的负载是百分之九十，项目经理看到的却是百分之一百五十。PMO如果只统计工时，不定义需求、可用产能、优先级和冲突处置规则，Capacity表格就会变成一份精致的争论记录。本文的核心判断是：Capacity管理不是把人填进计划，而是让组织用一致口径决定“有限的关键能力先服务什么、何时调整、由谁承担取舍”。

一、先讲结论：Capacity制度要管决策，不只是管数字

1. Capacity的管理对象是有限能力，不是日历空格

Capacity通常译为产能、容量或资源能力。放到项目组合管理中，它不是某位员工日历上剩余的小时数，而是组织在一段时间内、针对某类技能和职责，能够稳定交付的有效工作量。比如，团队有十名工程师，不代表任意技能都能提供十个人的产能；其中两名工程师掌握关键数据迁移能力，另外八人未必能在本季度替代他们。

因此，我建议PMO至少把Capacity拆成四层：人员名义容量、扣除常规损耗后的可用容量、按技能或角色划分的能力容量，以及经优先级决策后分配给项目的容量。只看总人天，会把技能瓶颈和关键角色过载隐藏起来。

2. 制度的最小闭环是“预测，承诺，校准，决策”

Capacity制度不应停留在每月更新一次资源表。有效闭环要明确四件事：谁提交需求，PMO如何校验供给，谁有权批准超载，计划偏差出现后如何重排。四个环节缺一不可。需求不校验，数字会膨胀；供给不扣除日常工作，容量会虚高；超载没人决策，项目经理只能私下抢人；偏差不回看，制度就无法学习。

我通常把流程划分为三个时间尺度：年度或季度层面做能力配置和组合取舍，月度层面做滚动预测与资源平衡，周度层面处理执行偏差和短期冲突。不同层级解决的问题不同，不应要求周会决定战略优先级，也不应等季度会才处理下周的关键岗位冲突。

3. 衡量制度是否有效，要看决策质量而非表格完整度

一份表格有姓名、项目、工时和百分比，不代表制度成熟。更有价值的判断是：PMO能否提前识别技能瓶颈；项目负责人能否解释需求依据；业务负责人能否在多个优先事项之间作出明确取舍；管理层能否看到变更的影响范围。

我建议把Capacity制度的结果指标分为三组：预测质量、资源健康、组合结果。预测质量看供需偏差和需求变更；资源健康看关键角色负载和连续超载；组合结果看项目里程碑稳定性、延期原因及优先级调整后的价值兑现。负载率本身不是成绩，负载率支撑的决策才是。

二、背景和真实场景：为什么“每个人都分配了”仍然会延期

1. 典型场景：同一名专家被多个计划重复认领

以一个中大型产品组织的情景模拟为例：产品、研发、交付和内部运营同时推进十余项工作。季度规划中，一个数据平台专家被三个项目分别安排百分之四十、百分之三十五和百分之二十五投入，表面合计百分之一百，似乎合理。但这份计划没有计入故障支持、评审、跨团队答疑、技术方案复核和请假。

到了执行阶段，三个项目都认为自己的工作已经获得确认。专家一周内参加多场会议，连续切换上下文，实际能用于深度设计的时间远低于计划。项目进度报告却把延期归因为“资源配合不足”，因为没人能指出最初的资源承诺是如何形成的。

这类问题不一定是员工效率不足，往往是组织把“分配比例”误当成“可交付容量”。一项工作需要多次切换、依赖评审或集中连续投入时，百分之二十的碎片时间未必等于每周完整的一天。Capacity制度要记录工作类型和连续性约束，否则比例看似精确，执行却无法落地。

2. 组织规模越大，平均数越容易掩盖局部风险

百人以上组织常常同时存在多个产品线、共享平台团队和交付项目。总工程师人数可能充足，但某个区域的安全审核、数据治理、架构评审或客户迁移能力仍然只有少数人掌握。把所有人相加后计算一个平均负载，会将局部短缺稀释掉。

尤其在共享职能中，工作并不都以项目编号出现。生产故障、合规评审、客户支持、招聘面试、技术债治理和内部赋能，可能分散在不同系统或邮件里。若Capacity模型只收集项目经理提交的需求，PMO看到的只是“项目占用”，不是完整工作负荷。

3. 工具能提高透明度，但不能替代制度口径

在涉及项目组合、研发协作或跨部门资源计划的场景中，PingCode这类面向中大型企业和百人以上组织的平台，可以帮助团队集中管理项目、任务、计划和执行状态。它能降低信息分散带来的核对成本，但前提是组织先约定字段定义、责任人和更新节奏。

如果不同部门对“投入百分比”的定义不一致，有人填计划工时，有人填可用时间，有人填主观忙碌程度，再好的系统也只会更快地汇总不一致的数据。我的做法是先用少量字段跑通一个规划周期，再逐步扩充，而不是先搭一套看起来无所不包的资源主数据模型。

三、常见误区：看上去量化，实际上让判断更模糊

1. 误区一：把每周工时当作可承诺容量

一周五个工作日并不意味着每人有五个完整工作日可以用于项目。团队成员还要处理例会、辅导、评审、支持、行政流程和不可预见事项。如果用名义工时直接承诺项目，计划从第一天起就建立在虚高供给上。

可用容量应由组织实际工作方式估算，而不是套用一个看起来精确的固定系数。不同角色差异很大：开发人员可能有较长的专注工作时间，经理和架构师则会承担更多协调、评审与决策。把所有岗位统一按百分之八十折算，容易造成另一种误差。

2. 误区二：所有岗位使用同一套负载阈值

对于某些稳定、可拆分的工作，较高负载短期内未必造成严重影响；对于需要连续专注的架构设计、事故响应或复杂客户迁移，名义上百分之七十的分配也可能已经无法有效执行。负载阈值必须结合角色、任务切换成本和工作可替代性来解释。

更重要的是，负载率不是员工绩效分数。把高负载当成积极贡献的证明，会诱发需求膨胀、隐瞒风险和资源争抢。制度要让管理者看到的是系统风险，而不是给个人贴上“高效”或“低效”标签。

3. 误区三：把任务数量、故事点和人天直接换算

不同团队的故事点尺度可能不同；同样一个“开发任务”，在新系统、遗留系统和强合规场景中的不确定性也不同。若PMO把故事点直接换算为工时，再用换算结果分配人员，精确数字可能只是把经验假设包装成事实。

对于尚未形成稳定估算能力的团队，可以先使用容量区间、相对规模或历史周期数据，而不是强行精算。估算的作用是让不确定性可见，不能用来掩盖未知。尤其是探索性工作，应明确预留验证窗口，不能要求团队在信息不足时给出伪精确承诺。

4. 误区四：只按项目统计，不统计非项目工作

若团队每周用两天支持线上问题，却没有把支持容量纳入计划，项目预算会被反复侵蚀。项目经理认为资源被临时调走，运维负责人认为这是日常职责，PMO却没有基线可查。最后每个部门都能解释自己的数字，组织仍然无法判断真实供需。

可以将工作至少分为项目交付、运营支持、内部治理、能力建设和不可预见事项。分类不必过细，但要覆盖主要时间去向，并明确哪些类别进入容量基线。对运维和客户支持比例较高的团队，非项目工作不是“杂项”，而是必须显式安排的容量。

5. 误区五：把资源冲突留给项目经理私下协商

项目经理之间当然可以协作，但当两个项目都被高层列为优先事项，冲突就不再是项目经理之间的沟通问题，而是组合层面的取舍问题。没有升级规则时，最会争取资源的人可能赢，最重要的工作不一定赢。

PMO的价值之一，是提供统一的冲突证据：哪些里程碑受影响、延迟成本是什么、能否替代角色、调整需要多久、牺牲哪项工作。PMO不一定拥有最终裁决权，但必须保证有权决策的人面对的是同一张事实地图。

四、专业判断逻辑：先定义指标，再设计审批与纠偏

1. 建立清晰的容量口径

我建议制度里明确四种容量，避免多个部门用同一个词表达不同含义。

• 名义容量：特定周期内按工作日、排班或合同口径计算的理论时间。
• 可用容量：扣除休假、固定职责、运营支持和其他已知工作后的时间。
• 计划容量：经过角色匹配和优先级确认后，可安排给项目或产品工作的部分。
• 承诺容量：由责任团队确认、进入交付计划并接受周期性复核的容量。

名义容量是输入，不是承诺；可用容量是估算，不是保证；计划容量是分配结果；承诺容量则应有责任人、时间范围和变更规则。区分这四者，才能定位计划偏差究竟来自供给估算、需求变化还是执行损耗。

2. 建立指标字典，避免一个指标多种解释

每个指标至少要写清定义、公式、数据来源、更新频率、责任人和使用边界。比如“利用率”必须说明分母是名义容量还是可用容量，分子是否包括运营支持；否则，两个部门的百分之九十可能完全不是一回事。

3. 设定负载区间，不设一个全员通用红线

制度可以使用绿、黄、红区间作为管理信号，但阈值要通过历史数据校准。以下区间可作为试运行起点，不是行业标准：常规岗位在滚动周期内安排百分之七十五至百分之八十五，关注区间为百分之八十五至百分之九十五，连续高于百分之九十五则触发复核；关键专家和事故响应岗位需要额外预留缓冲。

这里的关键不是红线取百分之九十还是百分之九十五，而是阈值触发后必须做什么。若超限只产生一条颜色提示，没有责任人、决策期限和处置选项，指标就没有治理价值。红区应触发优先级复核、范围拆分、替代人员评估或交付日期重估。

4. 把不确定性纳入容量，不把所有计划当作确定承诺

项目需求的确定程度不同。已拆解、依赖清晰的交付工作可以进入承诺容量；尚待技术验证的工作应以区间或探索预算表达；外部审批、客户输入和供应商交付等依赖项，应标出条件和风险，而不是直接计入无条件承诺。

我倾向于把容量计划分成“已确认”“条件性”“待评估”三档。已确认工作进入正式承诺；条件性工作在依赖满足后再转入承诺；待评估需求只进入需求池，不能拿来挤占已经承诺的容量。这样可以防止早期意向在排期表中被误读为正式工作。

5. 让资源决策和项目优先级使用同一套证据

资源冲突不能仅看谁先提交需求，也不能只看项目的政治声量。至少要比较战略关联、法定或客户期限、预期价值、延迟成本、风险暴露、资源稀缺程度和替代方案。每项标准不一定都要量化成分数，但必须显式呈现。

当两个项目争夺同一名专家时，PMO应把问题从“谁先拿到人”改写为：“若项目甲延后四周，成本和风险是什么；若项目乙采用替代方案，质量或范围会损失多少；是否可以先完成高风险验证，再释放专家给另一项工作？”这样的问法能把资源争论转化为业务决策。

五、制度流程设计：从需求录入到冲突裁决的操作步骤

1. 需求录入：先说明为什么需要这项容量

项目负责人提交资源需求时，不能只填“需要两名工程师、投入百分之五十”。至少要说明工作成果、时间窗口、所需技能、需求依据、交付依赖、估算置信度，以及若资源未能满足时的影响。

1. 描述具体交付物或阶段目标，避免仅填写岗位名称。
2. 说明开始时间、结束时间和是否需要连续投入。
3. 标明必需技能、可替代技能及替代后的质量影响。
4. 提供估算依据，例如历史相似工作、拆解结果或验证结论。
5. 说明资源不足时可接受的范围、时间或质量调整方案。

这样做的目的不是增加审批负担，而是让需求从“要人”变为“要完成的工作及其约束”。如果项目负责人无法解释资源需求与交付物的关系，PMO就不应直接把需求计入正式供需平衡。

2. 供给盘点：由职能经理确认可提供能力

项目经理通常最了解交付需求，职能经理或团队负责人则更了解人员能力、轮值安排、休假、运营任务和培养计划。两方信息不一致时，PMO要组织核对，而不是默默选择一方数据。

供给盘点应按角色或技能族分层。对技能覆盖面广的岗位，可以先按团队级别管理；对稀缺专家、强制审批人和单点职责，则要落实到个人或明确的替代机制。透明度应服务于风险管理，不应演变为对员工每小时活动的监控。

3. 匹配校验：检查总量、技能、时间和连续性

需求与供给匹配不只是把总人天加总。PMO至少需要检查四个维度：总容量是否够、技能是否匹配、时间窗口是否重叠、工作是否需要连续投入。再增加一个常被忽略的维度：依赖顺序。前置任务延期后，后续人员的空闲时间是否能真正转移到其他工作？

如果人员在不同项目之间频繁切换，日历上的分配比例可能看似合理，实际交付却被上下文切换吞噬。对高复杂度工作，宁可安排较少项目、较完整的时间块，也不宜将同一专家切成许多小比例分配。

4. 冲突裁决：按权限升级，而不是无限协调

冲突可以分成团队内、部门间和组合级三个层次。团队内的短期调整由团队负责人处理；跨部门但影响有限的冲突由业务负责人或资源委员会处理；涉及战略优先级、重大交付和多条业务线的冲突，则必须由有权调整组合优先级的管理层拍板。

每个层级都要规定升级时限。例如团队内冲突在两个工作日内解决；跨部门冲突在下一次周度资源例会处理；涉及重要里程碑的重大冲突应立即升级，不能等例会。具体时限要符合组织节奏，但规则应写明。

5. 滚动校准：比较预测和实际，不只更新未来计划

每个周期结束后，PMO要区分预测偏差的来源：需求变化、估算偏差、人员不可用、运营事件、依赖延期、决策延迟或执行效率变化。不同原因对应不同改进方式。把所有偏差都归为“资源不足”，只会推动更多需求进入系统，不会提高预测质量。

更新计划时保留版本和变更原因。至少要能回答：原计划是什么、何时发生变化、谁批准、哪些项目和岗位受到影响。没有变更记录，组织无法判断是外部环境变了，还是计划从来没有被认真确认。

六、指标体系：用一组互相校验的指标替代单一利用率

1. 预测质量指标：判断计划有没有参考价值

供需覆盖率回答已评审需求中有多少得到有效供给匹配；预测误差回答需求或容量估算与实际发生的差别；计划变更率回答已经确认的安排有多大比例在周期内发生实质变化。

这三个指标要结合解释。覆盖率低，可能意味着需求超过供给，也可能意味着需求还不成熟；变更率高，可能是计划能力弱，也可能是外部环境剧烈变化。PMO应按原因分层，不能因为数字不好看就压制合理调整。

2. 资源健康指标：发现瓶颈与不可持续安排

关键岗位超载周数比某一周的峰值更能揭示长期风险。某位专家短期超过计划容量，可能是在关键节点进行集中支援；若连续多个周期都处于超载状态，则说明组织依赖结构或组合优先级存在问题。

还可以观察关键人员集中度、单点技能覆盖率、需求转移时间和上下文切换次数。集中度高并不一定立刻意味着失败，但意味着离职、请假、故障或紧急任务发生时，项目组合更容易受到冲击。

3. 结果指标：检查资源安排是否改善了交付

Capacity制度最终要服务交付和业务结果。建议结合里程碑准时率、延期归因、关键路径稳定性、已承诺范围完成情况和重大风险关闭周期进行评估。若负载数据更加齐全，里程碑却没有改善，PMO要检查问题是否在需求治理、决策速度或技术不确定性，而不是继续加密填报。

要避免把项目按期率单独当作制度成败指标。团队可能通过削减质量、延后缺陷处理或压缩测试来“按期”，这不代表资源治理有效。结果指标必须配合质量、风险和范围数据共同解读。

4. 指标之间的验证关系

当容量利用率持续上升、预测误差也在扩大、关键岗位超载周数增加时，组织可能正处于“需求过量且缓冲不足”的状态。若利用率较低但交付周期仍长，问题更可能出在依赖等待、决策排队或任务切换，而不是人力总量。

当需求覆盖率偏低、关键技能集中度高，但里程碑稳定时，可能说明组织谨慎地控制了并行工作，也可能意味着需求还没进入成熟阶段。不能只看一个月的数据作结论，至少要观察多个滚动周期，并结合计划变更原因。

七、具体案例推演：如何处理共享专家引发的项目冲突

1. 场景与初始数据

设想一家约三百人的产品与交付组织，季度内有三个重点项目同时需要数据治理专家。项目甲涉及客户数据迁移，项目乙需要平台性能治理，项目丙计划推进内部报表改造。三项工作都声称“本季度必须完成”，但专家每周可用于项目工作的时间只有二十二小时，其余时间用于运营支持、评审和团队协作。

项目甲申请每周十二小时，项目乙申请十小时，项目丙申请八小时，合计三十小时。若直接把需求加总，超出可用容量约三成六。更重要的是，三项工作分别在不同周进入关键阶段，不能简单通过平均分配化解冲突。

2. 先辨别需求性质，而不是按比例砍工时

PMO把三项需求拆解后发现：项目甲的迁移方案需要专家在前两周集中完成风险验证，之后团队可以按检查清单执行；项目乙的性能治理可以由另一位工程师先完成数据收集，专家只需在评审节点投入；项目丙的内部报表改造没有外部期限，且有替代方案。

这时，“十二、十、八”并不是三项工作不可调整的事实，而是未经验证的初始请求。通过拆解工作内容，组织可以识别专家必须亲自完成的判断工作，以及能够由其他角色承担的准备、执行和复核工作。

3. 形成分阶段资源安排

情景模拟中的安排是：前两周将专家主要投入项目甲，项目乙由替代人员完成数据采集，并在第三周安排专家评审；项目丙延后一个月，同时指定一名工程师参与报表方案准备。这样既没有简单平均分配，也没有把两个项目的需求全部否决。

PMO同时为项目甲设定了退出条件：两周内完成风险验证并形成可执行迁移清单。如果验证发现数据质量风险超出预期，项目负责人须提交范围、时间和额外容量方案，由组合决策层重新评估。这个条件避免了“临时支援”无限延长。

4. 用回顾数据改进下一轮计划

周期结束后，应核对专家实际投入、评审等待时间、替代人员完成质量、项目里程碑变化和临时支持事件。若项目乙的准备工作比预期多花一周，不应直接认定替代安排失败，而应分析是技能差距、文档不足还是任务拆分不合理。

一个Capacity制度的价值，常常不在于第一次就算准，而在于第二次能否少犯同一种错。若每次都依赖专家临时救火，说明组织还没有把隐性知识转为团队能力；若专家投入降低、评审质量稳定，才表明替代和培养机制开始有效。

八、不同组织阶段的行动建议：先解决最贵的失真

1. 刚开始建设：用简化模型建立共同语言

如果组织过去没有统一资源计划，不建议一开始就要求所有团队提供精确到个人、精确到小时的全年预测。先选择一个季度、两个至三个关键技能族和少量核心项目，验证容量口径、需求审批和冲突升级路径是否可执行。

首轮制度的目标是发现数据断点，而不是追求数据漂亮。PMO应记录哪些角色没有可用容量基线、哪些非项目工作没有进入计划、哪些需求经常临时变化。完成一次滚动周期后，再决定是否扩大覆盖范围。

2. 并行项目较多：优先治理关键技能与组合优先级

当项目并行数快速增加，最有价值的工作通常不是进一步拆细全员工时，而是识别共享瓶颈、关键路径和低价值并行。若项目超过团队稳定交付能力，PMO应推动组织减少并行或延后低优先级工作，而不是要求团队通过加班填补数学上无法成立的容量缺口。

可先建立关键岗位清单，标记替代人员、替代所需时间和培养计划。对单点角色，必要时采用任务轮换、配对工作、文档化和审批分层，逐步降低组织对个别专家的依赖。

3. 需求频繁变化：用区间和情景计划代替虚假的确定性

当产品方向、客户输入或外部政策变化较快，固定季度计划很容易过时。此时可以同时维护基准计划与变化情景：基准计划说明已确认的承诺，变化情景说明需求增加、优先级调整或依赖延期时会影响哪些资源和里程碑。

滚动窗口也可以缩短，但要避免每天更新所有人的计划。只对近期进入执行的工作做细化，对更远期需求保留区间和置信度。计划粒度应与信息成熟度匹配，不应让表格更新频率制造新的管理负担。

4. 强运营或客户支持团队：把服务负荷纳入供给模型

若团队承担大量线上支持，应使用历史事件量、平均处理时长、季节性和重大版本风险估算运营容量。把运营支持当作不可预测的“剩余时间”，项目安排就会在每次故障后失控。

可以根据事件等级设置不同的响应预留，并观察实际支持容量与预测之间的差异。对于突发事件较多的组织，预留缓冲不是浪费；它是维持交付稳定性所需要的保险成本。

5. 多地域或矩阵组织：建立统一口径，但保留局部解释权

多地域团队需要统一核心定义，例如可用容量、关键技能、正式承诺和变更记录；但不同地区的节假日、劳动安排、客户支持时区和外部合规要求可能不同。统一的是数据语义和治理原则，不一定是所有角色使用相同的固定折算率。

PMO可以维护组织级指标字典，各业务单元则负责记录本地工作约束。只要能映射到统一口径，局部规则就可以存在。强行统一所有细节，可能让数据更整齐，却离实际工作更远。

九、不同情况下的取舍：容量制度没有一种通用最优解

1. 精细到个人，还是按团队汇总

个人级计划能发现单点瓶颈和具体冲突，适合关键角色、近期执行计划和高风险里程碑；但它维护成本高，也容易被误解为人员监控。团队级计划更适合早期规划和能力池估算，成本较低，却可能掩盖局部超载。

我的建议是分层管理：远期需求先按团队或技能族汇总，近期执行计划再对关键岗位细化到个人。只有在存在明确决策用途时才收集更细颗粒度的数据，避免收集无法用于管理的信息。

2. 高利用率，还是保留缓冲

提高利用率可能提升短期资源表上的“饱和度”，但越接近满负载，越难吸收紧急任务、需求变化和估算误差。保留缓冲会让部分时间看起来未被项目占用，却能降低突发事件对关键路径的冲击。

低风险、可替代、节奏稳定的工作可以采用较紧的安排；高不确定性、强依赖和关键专家工作则需要更多缓冲。管理层应比较缓冲成本与延误风险，而不是把空余容量一律视为浪费。

3. 统一阈值，还是岗位差异化阈值

统一阈值有利于快速沟通和跨团队比较，但岗位差异化阈值更符合实际工作方式。成熟组织可以在统一的指标定义下，允许不同岗位使用不同预警区间；同时要求团队解释阈值依据并定期校准。

若组织数据尚不稳定，可以先用统一的预警规则做观察，不要立即绑定奖惩。等积累多个周期的数据后，再区分岗位、团队和工作类型，减少因为样本太少造成的误判。

4. 全部需求进计划，还是先做组合筛选

所有需求都进入计划池，有利于看见总需求，但容易让未经评审的意向被误认为组织承诺。先筛选再规划能减少噪声，却可能漏掉尚未被高层识别的新机会。

更实用的做法是建立分层需求池：意向需求可被观察但不占用承诺容量；经评审需求进入资源评估；获得优先级和供给确认后，才进入正式计划。这样既保留需求可见性，又不会把全部想法都转化为“必须完成的工作”。

十、落地与治理：让制度能运行，而不是只在文件里正确

1. 明确角色责任与决策权

职责边界应写在流程中。PMO负责让事实可见和程序可追溯，业务负责人负责价值排序，团队负责人确认现实供给。若组织把最终裁决责任留空，冲突就会回到私下协商和非正式权力。

2. 设定会议节奏和必备输入

月度资源平衡会不应从逐个念项目状态开始。会议材料应提前列出供需缺口、关键岗位超载、优先级变化、依赖风险和待决策事项。会议时间用于选择方案，不用于现场补齐基础数据。

1. 会前由项目负责人更新需求、阶段和变更原因。
2. 由团队负责人核对容量、技能和运营负荷。
3. PMO生成供需缺口及其对项目里程碑的影响。
4. 决策层针对冲突确认优先级、替代方案或日期调整。
5. 会后记录责任人、期限、决策依据和受影响项目。

若会议每次都重复收集同样的信息，说明数据责任没有落实；若所有议题都无法当场决策，说明参会者权限不足或升级路径不清。会议频率不是制度成熟度，决策闭环才是。

3. 把数据质量和隐私边界写清楚

Capacity数据涉及人员安排，应限定使用目的。管理者需要的是团队负荷、关键技能风险和计划承诺，不一定需要持续记录个人每小时活动。过度追踪会降低信任，也会诱发为了指标而填报。

系统字段应尽量服务具体决策，例如岗位技能、可用窗口、工作类别、估算置信度和变更原因。建立权限规则、保存周期和数据纠错渠道；发现异常数据时，应允许责任人核实，而不是仅凭系统红色提示作出人事判断。

4. 用试点验证字段和流程的实际成本

在正式扩大前，可选一个跨部门项目组合试运行六至八周。记录提交需求所需时间、PMO核验工作量、资源冲突数量、决策等待时间和计划变更原因。试点并非为了证明制度一定成功，而是找出哪些字段无人使用、哪些审批节点过多、哪些信息无法可靠取得。

如果团队平均每周花数小时维护资源数据，却没有任何决策因此改变，应先简化数据，而不是要求团队更认真填表。反过来，如果一次关键岗位冲突的提前识别避免了数周延期，说明这类数据具有明确价值，值得继续投入。

十一、结尾：先把取舍说清，再把容量算准

Capacity制度最深的价值，不是告诉组织每个人还能多做多少，而是把“我们同时承诺了什么、关键能力被谁占用、延误会落在哪里、谁能决定取舍”变成一套共同语言。数字有误差并不可怕；可怕的是误差无人负责，冲突无人裁决，计划变化没有记录。

如果你准备开始设计制度，下一步不必先采购或配置复杂系统。先挑出三个最常发生的资源冲突，核对需求、供给和实际投入；再确定容量口径、关键岗位、升级权限与滚动节奏。用一个季度验证指标能否改变决策，然后逐步扩展到更多团队。

我的最终判断是：先治理关键技能和优先级，再追求精确到人的容量数据；先确保每个超载信号能触发行动，再讨论阈值是否足够漂亮。当组织能够坦诚地说出“这项工作优先，因此另一项工作延期”，Capacity才从资源表格变成真正的管理制度。