人力资源计划如何做好投入比例？PMO制度设计与操作步骤

人力资源计划最容易失真的地方，不是“人头数算少了”，而是把所有人的时间都当成可以投入项目的时间：一个团队有 20 人，就按 20 人月承诺交付，结果会议、支持、请假、跨项目切换和突发事项一层层挤占容量。要把投入比例做好，PMO不能只发一张资源表，而要建立一套能核算、能协商、能预警、能滚动调整的规则：先定义可计划容量，再按工作性质分配比例，最后用实际记录持续校准。

一、先讲核心结论：投入比例不是人头分摊，而是容量治理

1. 先把“投入比例”说清楚

“某员工投入项目 50%”听起来很明确，实际可能代表每周两天、每天半天、关键节点支援，或者只对某个交付结果负责。若不先定义口径，同一个比例在部门计划、项目计划和员工日历里会变成三种含义。

我建议把投入比例定义为：某人在一个明确周期内，可用于某类工作或某个项目的计划工时，占其有效可计划工时的比例。它必须同时包含人员、周期、工作类型、产出责任和调整规则。只有百分比，没有这些字段，不能作为可靠承诺。

例如，“产品经理投入项目 A 30%”仍不够可执行。更完整的表达是：“产品经理李某在 4 月至 5 月，每周可计划容量为 30 小时，其中 12 小时用于项目 A 的需求澄清、评审和验收，遇到上线事故时由部门负责人批准调整，并在周例会上重新确认。”

2. 计划分母应该是有效容量，不是合同工时

常见的错误分母是“每月工作日 × 每天 8 小时 × 在岗人数”。这个算法把法定假期、休假、例会、内部管理、客户支持和不可避免的协作成本全部当成项目产能，计划从一开始就偏乐观。

更稳妥的做法是从日历工时出发，扣除已经确定的不可用时间，再单独识别结构性工作。公式可以写成：有效可计划容量＝日历工作容量－休假及法定假日－固定职责占用－必要缓冲。再根据职责类型拆分项目、产品维护、运营支持和组织建设等工作。

这里的缓冲不是“闲置”，而是应对需求波动、紧急缺陷、跨团队依赖和估算误差的保护带。若组织几乎没有突发工作，可以把缓冲设得较低；若处于频繁上线或高支持压力阶段，就不应照搬同一个比例。

3. PMO要管规则与冲突，不要替业务部门编造产能

PMO的责任不是把所有人的工时填满，也不是替职能经理决定谁应该加班。PMO应负责统一口径、维护资源视图、发现供需冲突、推动决策留痕，并让项目组合的承诺与实际容量相匹配。

部门负责人最了解岗位日常职责，项目负责人最了解交付需求，员工最了解实际执行中的摩擦。三方必须共同确认计划。PMO掌握的是治理机制，不是对每个人时间的单方面支配权。

• 职能经理：确认人员可用时间、专业能力、日常职责和替补安排。
• 项目负责人：提出按阶段、按角色拆分的需求，并说明交付物和峰值时间。
• PMO：校验容量、识别冲突、提出情景方案、记录取舍和风险。
• 员工：反馈实际投入、不可预见工作和计划不可执行的原因。

所以，好的投入比例不是“大家都填 100%”，而是让每个比例都有来源、有责任人、有适用周期，并能在偏差出现时触发行动。

二、背景和真实场景：为什么资源表看起来完整，项目仍然缺人

1. 多项目矩阵组织里的“重复承诺”

在中大型企业里，一个专业人员往往同时承担项目交付、产品维护、技术支持、内部改进和部门事务。项目负责人看到的是“这个人每周能投入两天”，部门负责人看到的是“他还要维护线上系统”，员工看到的则是“每天都有会议，真正完整的工作时间所剩不多”。三种视角都可能真实，却没有被同一套计划规则连接起来。

这种冲突在需求密集的季度尤其明显。项目立项时，每个负责人都认为自己的事项优先；月度排期时，专业资源却只有一份。资源表若只记录“张某：项目 A 50%、项目 B 50%”，却没有工作日历、优先级和冲突裁决机制，两个项目就可能同时把张某当作全职成员。

2. “有空”不等于“能产出”

投入比例还有一个容易忽略的维度：任务的连续性。每天分给项目两小时，不一定等价于一周完整投入一天。需要长时间专注的架构设计、复杂分析和联调工作，频繁切换可能显著增加恢复上下文的成本。

因此，容量计划不能只算工时，还要关注工作块是否连续、依赖是否就绪、决策是否及时。一个人名义上投入 40%，如果每天被多个项目拆成零碎任务，实际交付效率可能低于集中投入 30% 的安排。

3. 资源冲突常常是项目组合问题，不是个人效率问题

当关键岗位长期超配时，管理者容易把问题归结为员工执行慢，继而要求提高利用率。但如果所有项目都依赖同一名架构师、测试负责人或数据专家，个人再努力也无法同时处理彼此冲突的任务。真正的约束可能是优先级没有排序，或项目启动数量超过组织的交付容量。

这也是 PMO 需要把单项目计划上升到项目组合层面看的原因。局部把某个项目的投入比例调高，可能只是把延误转移给另一个项目；整体容量视图才能看清哪些承诺可以兑现，哪些必须延期、缩范围或补充资源。

4. 先区分岗位容量、技能容量与人员容量

“团队有 10 个开发人员”并不意味着任何开发任务都能由这 10 人平均承担。不同技能、领域知识、系统权限和经验水平会形成不同的容量池。某个关键技术领域只有一名熟悉人员时，团队总工时富余也不能消除该岗位的瓶颈。

我通常会要求计划至少拆到“角色或技能组”，关键项目再拆到具体人员。这样既避免过早把员工时间切得过细，也能识别真正的稀缺角色。容量核算应先看技能组，再看个人可用性，而不是先把总人数汇总成一个看似充足的数字。

三、常见误区：比例算得很精细，计划仍然不可信

1. 把 100% 利用率当作效率目标

利用率高并不自动代表交付好。若所有人的日历都排满，任何突发问题都只能通过加班、延期或打断别的工作来解决。计划看起来很“充分”，系统却没有吸收波动的能力。

尤其要避免把利用率目标直接压到个人层面。个人利用率可以帮助观察容量是否被安排，但不宜被当作绩效指标单独考核。员工可能因主动暴露风险、承担团队支持而呈现较低的项目工时，却对整体交付有很高贡献。

2. 把比例平均分配给每个月

项目投入通常随阶段变化。需求澄清期需要产品、业务和架构人员集中参与；开发期对研发投入较高；集成测试期测试和运维角色负荷上升；上线后又需要值守与问题处理。把全年投入均摊，容易在峰值阶段缺人，在低谷阶段又看不清可释放的容量。

比较好的做法是按阶段做滚动计划，至少把未来一个季度细化到月，近期两到四周再细化到周。远期计划表达的是需求趋势和预留区间，近期开工承诺才需要精确到角色和工作包。

3. 用“百分比精度”掩盖需求不确定性

在需求尚未澄清时，要求项目负责人承诺“测试投入 27%”并没有增加计划准确度，只是给不确定性套上了精确数字。高精度的比例若缺少工作量依据，反而容易制造虚假的确定感。

对不确定工作，我更倾向于用区间、容量预留和阶段门。例如把需求评估为 20 至 35 人时，先预留一个区间，在范围明确后再收敛；若依赖条件未满足，就不要把预估投入写成正式承诺。

4. 只看计划工时，不看切换成本与依赖等待

多个项目并行时，员工可能要在不同代码库、业务场景、审批流程和会议节奏之间来回切换。计划表上每个项目只占 20%，但切换频次和等待决策的时间可能让产出远低于预期。

PMO应记录并行项目数、关键依赖等待和任务中断情况。若同一专业人员同时服务过多项目，优先级不清晰会产生大量协调成本。此时减少并行数，往往比微调每个项目的百分比更有效。

5. 把缺勤和非项目职责视为“异常”

培训、管理、知识传承、招聘面试、代码评审、事故复盘和客户支持，很多时候是岗位的正常组成部分。若容量模型只承认项目工作，员工为了满足指标就会把必要工作隐形化，最终导致计划数据失真。

应将工作类型分层记录，例如项目交付、产品维护、运营支持、内部建设、管理协作和休假。分类不必过细，但要足以解释时间流向，也要能让负责人据此调整工作方式。

6. 只做一次年度计划，不做滚动校准

年度计划适合表达战略方向和预算边界，不适合代替项目执行期的资源调度。需求变化、人员离职、优先级调整、供应商交付和突发质量问题都会改变可用容量。若计划一年不更新，表格即使字段齐全，也只能成为历史记录。

PMO需要建立固定的更新节奏：项目组合层面按月检查供需，项目层面按周确认近期开工资源，重大变化随时触发调整。重点不是每天修改比例，而是让变化有门槛、有责任人、有决策记录。

四、专业判断逻辑：怎样确定比例、粒度和缓冲

1. 先确定计划层级：组合、角色、个人不能混成一张表

项目组合层关注总需求与组织供给是否匹配，通常按月或季度看角色容量；项目层关注交付阶段和工作包，按周或双周安排；个人层才涉及具体日历与任务协作。把三个层级塞进一个表格，会导致计划既过粗又过细。

我建议先做两层基线：第一层是角色容量池，回答“未来两个月产品、研发、测试、运维各有多少有效容量”；第二层是重点项目需求，回答“每个阶段需要哪些角色、峰值何时出现”。只有关键角色冲突无法通过组合视图判断时，才下钻到具体人员。

2. 用工作包推导比例，而不是先拍百分比

投入比例应由工作量和周期推导。先列出阶段交付物，再估算所需角色的工作量，最后除以该角色在相同周期内的有效容量。这样得到的比例才有可追溯的业务依据。

例如，一个阶段预计需要分析师 48 小时，计划周期为 4 周；该分析师每周有效可计划容量为 30 小时，则该阶段平均投入比例约为 40%。如果工作集中在前两周，计划就不能写成“四周均匀 40%”，而应明确前两周峰值安排和后两周释放时间。

估算不确定时可以保留低、中、高三档，或者给出范围并注明假设。分母和分子必须使用同一口径：不能用含会议的 40 小时工作周去除一个只算专注工时的任务估算。

3. 按任务性质设定不同容量边界

不是每个岗位都适合用同一套比例。支持型岗位需要处理随机到来的工单，通常要预留响应容量；研发交付岗位可以根据迭代节奏集中安排；管理岗位则有大量跨团队沟通，计划时应把管理职责显式列出。

4. 用服务水平和波动程度决定缓冲

缓冲不宜采用全公司统一的固定比例。支持事件多、外部依赖复杂、需求变更频繁的团队，缓冲应较高；工作内容稳定、依赖少、交付节奏成熟的团队，可以逐步降低缓冲。关键是记录缓冲被消耗的原因，而不是把它当作“闲人时间”。

可以从过去 8 至 12 周观察突发工时、返工工时和等待时间的分布。如果某团队每周突发工作经常超过计划容量的 15%，继续按 5% 留缓冲就不现实。反过来，若缓冲长期几乎未使用，也应检查是否预留过多，或工作分类与记录方式不完整。

5. 关键岗位采用“瓶颈优先”的判断顺序

总容量充足，不代表关键岗位充足。资源评审时，我会先检查稀缺技能、单点知识、审批角色和关键依赖，再看一般性岗位。若瓶颈角色被三个项目同时要求，就应先讨论顺序，而不是把比例从 30% 微调到 25%，假装冲突已经解决。

决策优先顺序可以是：明确项目优先级；减少同时开工的项目数；调整范围或里程碑；寻找可替代技能并安排交接；最后才讨论外部补充资源。招聘和外包不是即时按钮，涉及招聘周期、知识转移、权限和质量管理，不能用“下个月补人”掩盖当前计划缺口。

五、案例与数据观察：一个矩阵团队如何从“满负荷”改成可执行计划

1. 案例设定：项目都在推进，关键人员却总在救火

以下是一个为说明方法构造的情景案例，不代表某家企业的实际经营数据。某中大型企业的产品与技术组织约 120 人，同时推进 6 个重点项目，并承担线上维护、客户问题响应和内部平台建设。项目计划表显示关键岗位几乎全部达到 100% 投入，但多个里程碑连续延期。

复盘后发现，问题并非单纯“人不够”：项目表没有扣除固定运营职责；同一名架构师被多个项目重复承诺；测试资源集中在上线前几周；项目负责人只报平均投入比例，没有提供阶段工作包；员工的支持与评审工作没有归入任何计划类别。

2. 先用容量账本还原资源去向

PMO先按角色盘点月度有效容量，再将项目交付、维护支持、内部建设和必要管理工作分开。对数据尚不完整的岗位，先采用 4 周观察期，不把推测当作事实。观察期内记录计划投入、实际投入、临时支持、等待和返工，并让负责人确认异常原因。

这个步骤的目的不是监控每一分钟，而是判断容量模型是否遗漏了稳定存在的工作。若研发人员每周固定参加多个评审，评审就应当被视为真实工作；若某项目经常因等待审批停滞，则问题可能在决策链路，而不是资源比例。

3. 再按优先级重排项目，而不是继续压榨个人

容量冲突被显性化后，管理层将 6 个项目分成必须按期交付、需要重新评估范围、可以延后启动三类。两个依赖同一架构师的项目错开关键设计阶段；测试团队提前介入需求和验收标准评审；线上支持设置固定轮值，不再临时从多个项目中抽人。

这种调整短期内可能让某些项目的启动时间变晚，但换来的是承诺可信度提高。PMO应把“项目启动多少个”与“组织能同时交付多少个”放在一起讨论，而不是把所有立项都变成默认并行。

4. 用实际偏差校准，而不是把第一版当标准答案

观察四周后，团队发现某些岗位的实际运营支持占比高于原计划，另一些岗位的评审时间则被重复计算。PMO据此调整容量基线，并在月度组合评审中说明变化原因。计划偏差不再只显示“员工投入不足”，而会区分需求增加、任务等待、支持事件、估算偏差和人员缺席。

对于项目型组织，最有价值的指标往往不是“所有人是否达到某个利用率”，而是计划与实际的偏差是否能解释、关键里程碑是否稳定、资源冲突是否提前暴露、重复承诺是否减少。指标要用于改善系统，不应被简化成个人排名。

5. 用工具承载规则，但不要让工具替代治理

对于 100 人以上、跨项目并行较多的组织，资源计划通常需要同时看项目、角色、时间和状态。工具的价值在于统一数据入口、保留变更记录、把冲突可视化，并减少不同部门各自维护多份表格的重复劳动。

例如，在 PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台中，可以把项目阶段、任务责任人、计划时间和需求变更记录关联起来，再由 PMO建立统一的角色容量字段和资源评审流程。具体字段与能力应以组织实际配置和产品当前版本为准，不能假设平台会自动替管理层判断优先级。

如果组织还没有统一的平台，也可以先用受控模板试运行。关键不是先买工具，而是统一字段、责任人、更新频率和变更门槛。工具上线前口径不一致，只会更快地产生不一致的数据。

六、PMO制度设计与操作步骤：从规则发布到滚动执行

1. 先发布资源计划规则，而不是先要求填表

制度文件要短而明确，至少说明计划对象、时间粒度、容量口径、审批权限、更新频率和冲突升级路径。对每个岗位的可计划容量，可以由职能负责人提出基线，PMO校验后纳入角色池；任何临时变更都要说明影响到哪些项目和里程碑。

建议把“计划”“承诺”“预测”区分开。计划是基于当前假设的安排；承诺代表负责人接受交付责任；预测是根据现有信息对结果的估计。探索性工作可以有预测，不一定立即形成固定承诺；依赖未满足时，应显式标注条件。

2. 统一字段，避免每个部门发明自己的口径

一条可执行的资源记录，至少包含人员或角色、项目或工作类型、计划周期、投入比例或工时、工作包、交付物、优先级、依赖条件、确认人和更新时间。对比例有争议时，能够回到工作量和容量来源核验。

3. 建立从需求提出到资源确认的操作闭环

资源计划不应只是周期性填报，而应嵌入立项、排期和变更流程。下面的步骤适用于多数矩阵型组织，可以按项目规模简化，但不建议删掉冲突确认和变更留痕。

1. 项目提出角色需求。项目负责人按阶段列出工作包、交付物、预计周期和所需技能，不直接假设某位员工已经可用。
2. 职能负责人核对供给。确认角色容量、固定职责、休假安排、关键技能和替补人选，指出需求与实际供给不匹配之处。
3. PMO汇总项目组合冲突。按周期和角色检查重复承诺、峰值集中、依赖风险及资源缺口，并区分已确认与待确认事项。
4. 项目与职能负责人协商方案。优先讨论调整顺序、范围、并行度和工作包，再讨论人员替换或增补。
5. 授权人确认承诺。涉及跨部门优先级或重大里程碑变更时，由有权决策的负责人确认，不能让一线员工独自承担冲突。
6. 按节奏滚动更新。月度检查组合容量，周度确认近期安排；需求、人员或依赖发生重大变化时触发临时复核。
7. 复盘实际偏差。区分估算误差、需求变化、支持工作、等待、返工和资源缺席，并把原因反馈到下一轮容量基线。

4. 设置明确的冲突阈值和升级路径

有些冲突不需要每次都升级到高层，但必须设定触发条件。例如关键岗位超出已确认容量、多个项目争抢同一人员、关键里程碑依赖未解决、某角色连续多个周期超负荷，或临时支持挤占已承诺交付时，都应进入资源评审。

阈值不必照抄统一百分比。组织可以先选一个试运行阈值，例如关键角色需求超过有效容量 10% 时触发评审，再结合实际偏差调整。阈值的意义是让问题被看见，而不是保证所有计划都在阈值之内。

5. 选择能够解释偏差的指标

PMO可以关注容量预测偏差、关键岗位冲突次数、里程碑稳定性、临时插单比例、等待与返工占比，以及计划变更的响应时间。每个指标都要有定义、计算周期和负责人，不能因为容易采集就把个人填报时长作为唯一核心指标。

数据解释要有上下文。例如，某团队计划准确度下降，可能是需求频繁变更，也可能是容量核算漏了运营支持；某项目延期，可能是关键资源缺席，也可能是外部依赖未就绪。指标触发的是调查，不是直接定责。

6. 让制度有例外机制，但例外必须有期限

组织一定会遇到紧急事件，制度不可能把所有突发情况都提前排进计划。关键是定义谁可以启动例外、例外持续多久、被挤占的承诺如何处理、何时重新排期。若没有这些问题的答案，“临时优先”就会长期成为默认状态。

例外记录应至少说明事件原因、影响人员、受影响项目、预期恢复时间和决策人。临时调配结束后，PMO应检查计划是否需要重新基线，而不是让被打断的项目继续背负原里程碑。

七、不同组织情况下的行动建议与关键取舍

1. 小团队：先做轻量容量账本，不要过早建设复杂制度

人数较少、项目数量有限的团队，通常不需要复杂的资源管理系统。可以用一个共享视图记录每周有效容量、项目工作、日常支持和计划外事项。重点是每天出现的临时工作能被看见，每周的优先级由负责人明确，而不是让员工自行决定哪项任务先做。

小团队的取舍在于：减少填报成本，接受较粗的预测粒度。与其追求每个人每周精确到 5% 的比例，不如让团队知道哪些任务必须完成、哪些可以延后，以及发生冲突时谁作决定。

2. 中大型矩阵组织：按角色池治理，再下钻关键人员

当项目多、部门多、人员跨项目时，应先建立跨项目的角色容量池，再对稀缺角色和关键依赖进行个人级管理。制度要明确职能经理与项目经理的决策边界，避免多个项目负责人分别向同一员工承诺优先级。

这类组织更适合使用统一的项目管理平台，把项目阶段、任务、人员角色、计划周期和变更历史关联起来。采用 PingCode 等平台时，建议先小范围验证字段、流程和权限设计，再推广到更多部门；同时确保系统数据能服务于容量决策，而不是只用于汇报展示。

中大型组织的主要取舍是治理成本与可见性。管理粒度越细，信息维护成本越高；粒度太粗，又无法发现关键角色瓶颈。通常可以让组合层按角色看月度容量，近期项目按周看工作包，只有出现冲突时再核到个人。

3. 产品探索期：保留弹性，不要把不确定性伪装成精确比例

产品方向尚未验证、需求变化频繁时，适合按阶段设置时间盒和投入上限，明确进入下一阶段的条件。例如先安排短周期调研与原型验证，达到用户问题、技术可行性或商业假设的最低证据要求后，再增加设计与开发容量。

这种做法的代价是短期内难以给出远期人力承诺，但好处是把风险限制在可控范围。投入比例应随证据质量变化，不宜在早期就承诺长期固定团队，除非关键假设已经验证且资源机会成本可接受。

4. 稳定运营团队：优先保证服务水平，再安排改进项目

运营、客户支持和线上维护类团队，突发工作具有波动性。若把全部容量分配给改进项目，服务压力上升时就会通过加班和插单消化。可以根据历史负荷分位数设置基础预留，并将超过预留的情况分级处理：一般波动由轮值吸收，重大事件触发管理层重新排序。

要在服务响应与改进速度之间取舍，就应公开说明响应时间、风险等级和项目影响。长期把维护工作压到“剩余时间”，通常会积累技术债和响应风险；但预留过多也会使改进项目缺乏稳定投入。需要根据实际支持量滚动修正，而不是凭印象确定比例。

5. 外包与临时增员：先确认工作可拆分，再比较补人和调整范围

外部资源适合边界清楚、可验收、知识转移成本可控的工作。若工作高度依赖内部系统权限、业务背景或频繁决策，新增外部人员未必能迅速释放内部关键人员，管理与交接甚至会增加负担。

在决定补人之前，先判断瓶颈究竟是“工作量过大”还是“关键知识集中”。前者可能适合增加人手或外包；后者更需要文档化、结对、轮岗和逐步建立替补能力。两者可以同时推进，但短期缓解与长期能力建设要分开评估。

6. 资源冲突解决不了时，必须在范围、时间、成本和质量之间明确取舍

当需求超过有效容量，组织实际上只有几类选择：延后部分工作、缩小范围、增加资源、降低并行度，或接受更高风险。把投入比例调到超过 100%，不是一种真实解决方案；它只是把决策转交给员工，让其用加班和质量风险支付成本。

我建议按以下顺序讨论：第一，是否可以减少同时开工的项目；第二，是否有低价值范围可以暂缓；第三，里程碑是否可调整；第四，是否存在可复用能力或内部替代；第五，外部资源是否能在可接受的周期内形成产出。每个选项都应写明影响和决策人。

7. 试运行 8 周，比一次性推行全公司统一模型更稳妥

制度上线初期，可以选择项目数量适中、跨部门协作明显的团队试运行 8 周。前两周统一字段并采集基线；中间四周按周复核计划与实际偏差；最后两周复盘规则是否过重、哪些字段没人使用、哪些冲突仍未被发现。

试运行不要以“表格填写率”作为唯一成功标准。更值得观察的是：重复承诺是否减少，关键冲突能否提前发现，例外调整是否有记录，计划外工作是否显性化，以及一线是否认为计划机制帮助他们解决了优先级问题。

八、落地检查清单：让投入比例从一张表变成管理闭环

1. 发布前检查口径是否一致

• 是否明确了有效可计划容量的计算方式，且没有把合同工时直接当成项目工时。
• 是否区分项目交付、运营支持、内部建设、管理协作和休假等工作类型。
• 是否要求投入比例关联到人员或角色、周期、工作包和交付物。
• 是否明确计划、预测和承诺的区别，避免未经确认的需求进入正式承诺。
• 是否设定了角色级与个人级计划的适用条件，避免全员过度细化。

2. 执行中检查冲突是否有人处理

• 重复承诺是否有可视化视图，关键人员是否被多个项目同时按满容量使用。
• 需求超过角色容量时，是否有明确的协商人和最终决策人。
• 临时插单挤占项目容量后，原项目里程碑是否同步调整。
• 运营支持与突发事件是否有预留机制，且能依据历史数据校准。
• 人员离职、休假、依赖延迟或需求变化时，是否能记录变更原因和影响范围。

3. 复盘时检查制度有没有制造新问题

如果员工花大量时间维护数据，负责人却没有依据数据做取舍，制度就变成了额外行政负担。如果利用率指标导致员工隐瞒支持工作，数据就不再可信。如果所有冲突都升级到高层，说明授权边界或阈值设计不合理。

每次复盘都应回答三个问题：哪些计划假设被事实推翻？偏差来自需求、供给、依赖还是执行方式？下个周期要改变哪条规则？制度优化应有明确对象，避免每次复盘都只得出“加强沟通”这样的空结论。

九、结尾：比例的价值，在于让组织敢于做真实取舍

1. 不要追求看起来满载，要追求承诺可以兑现

人力资源计划的质量，不在于每个人的日历被填得多满，而在于组织是否知道哪些容量已经被承诺、哪些工作被遗漏、哪些冲突必须由管理者裁决。投入比例只是把这些问题显性化的入口，不是解决问题的答案本身。

2. 下一步先做一个小范围的容量校准

如果现在就要开始，我建议选一个跨项目团队，先统一有效容量口径，收集 4 周计划与实际数据，识别关键角色、运营支持和高频切换，再用接下来的 4 周试行资源评审。第一轮不急着设统一利用率目标，先验证数据能否解释冲突、负责人能否据此作出取舍。

我最看重的判断是：当资源计划发现缺口时，组织是否愿意调整项目范围、启动顺序和承诺时间。如果所有项目都不能延、范围都不能减、人员也不能增加，那么再精细的投入比例也只是把组织的超载写得更漂亮。真正有效的 PMO制度，不是把每个人填到 100%，而是让有限的人力流向优先级最高、条件最成熟、责任最清楚的工作。