投入比例怎么做？PMO入门指南：人力资源计划从0到1

投入比例看起来只是“某个人每周拿出多少时间”，实际却同时影响项目承诺、团队负荷、成本核算和交付风险。PMO从0到1建立人力资源计划时，我最先纠正的不是表格格式，而是一个常见误解：投入比例不是把员工的工作时间平均分给项目，而是把有限产能、明确工作范围和可验证的交付承诺连接起来。下面我会用一组明确标注为情景模拟的数据，拆解如何计算、核验和滚动调整投入比例，并说明在百人以上组织中，如何借助项目管理平台把计划变成可维护的管理机制。

一、先讲核心结论：投入比例不是分人，而是管理承诺

1. 投入比例必须同时回答三个问题

我做人力计划评审时，不会只问“这个人投入多少”。一个有效的比例至少要能回答：投入的是谁、投入到什么工作、投入发生在哪个时间段。缺少其中任何一项，数字都可能看似精确，实际却无法排期、核算或复盘。

例如，“后端工程师投入项目A 50%”仍然不够。还要知道这50%是未来四周每周稳定投入，还是本月合计投入；是用于接口开发，还是还包括线上支持；遇到紧急故障时，谁有权调整这部分时间。比例只有和角色、工作包、时间窗口、优先级绑定，才是资源承诺。

2. 计划管理的对象是可用产能，不是名义工时

我通常先把某人的名义工作时间折算为计划可用产能，再分配给项目。假设一位员工每周名义工作40小时，扣除例会、培训、请假、跨团队支持和常规运维后，能稳定用于项目计划的时间可能只有28小时。若一个项目分配给他50%，更实用的解释是每周约14小时，而不是20小时。

这里的28小时不是通用标准。它应根据岗位、组织会议密度、支持职责和工作制度核算。计划的目的不是把每一分钟塞满，而是建立一个能执行、能解释偏差的基线。

3. 三条底线比一个“准确比例”更重要

• 单人总承诺要有上限：同一时间窗口内，各项目投入比例与日常职责合计不得默认超过可用产能。
• 关键角色要有缓冲：架构、测试、运维等共享角色，不能只按项目理想排期计算，应给突发工作留出容量。
• 比例要有复核机制：计划不是一次性填表，而是按固定节奏核验实际投入、工作范围变化和优先级变化。

因此，我建议PMO把投入比例管理定义为一个循环：确认工作范围、估算角色需求、核实人员容量、形成承诺、按周期核验、根据偏差调整。先把管理闭环做对，再追求系统自动化和细颗粒度。

二、背景和真实场景：为什么一张比例表经常管不住资源

1. 组织变大后，资源信息会分散在不同地方

在小团队里，负责人通常能直接知道谁正在做什么。组织扩大后，项目计划可能在项目文档里，人员借调在即时消息里，休假在考勤系统里，线上支持又在值班表里。单个项目看起来只占用一个人20%，但多个项目汇总后，可能已经超过这个人的实际产能。

PMO遇到的难题往往不是没有数据，而是数据口径不一致。有的团队报“计划投入”，有的报“实际工时”，还有团队把“全职参与”写成100%，却没说明是否包括会议、缺陷修复和上线值守。这样的数字不能直接横向比较。

2. 项目计划与职能工作之间存在看不见的争用

一位测试负责人可能同时参与三个项目，还要负责测试规范、版本质量门禁和线上问题复盘。若项目计划只登记前三项，管理层会以为他有余量；若他把所有职责都填进每个项目，项目合计又会被重复计算。PMO需要把“岗位职责”与“项目工作”分开建模，再明确哪些容量可被项目承诺。

我会把工作先分成三类：项目交付工作、持续性职能工作、不可预期但必须承接的工作。三类工作都消耗产能，但管理方式不同。项目交付靠里程碑和工作包安排，职能工作靠岗位基线和周期任务管理，突发工作则需要容量缓冲和升级规则。

3. 百人以上组织需要从“找人”转向“管理能力池”

在百人以上的组织中，PMO不宜只建立一张员工名单。更有效的做法是按能力和约束识别资源池，例如后端开发、数据工程、自动化测试、信息安全评审等，再记录人员的可用窗口、技能等级、地点或合规限制。这样做不是要把人当成可以随意调度的单位，而是让资源冲突能在承诺之前暴露。

以PingCode为例，若组织已经用项目管理平台维护项目、工作项和团队协作，可以把项目计划、责任角色、迭代安排和风险信息尽量放在关联的管理流程中。平台能帮助团队减少信息散落，但不能替代经理确认容量、业务负责人确定优先级，也不能自动判断某个人是否适合某项工作。工具负责让事实可见，资源决策仍要由有权限的人承担。

4. 情景模拟：看似只差10%，实际可能拖延一个迭代

下面用一个情景模拟说明超配如何发生。某数字化项目需要后端工程师每周投入约20小时，人员的可规划产能是28小时；同一工程师还被另一个项目安排每周12小时，并承担每周4小时的线上支持。总承诺达到36小时，超过可规划产能8小时。项目计划表若分别只看单个项目，两个负责人都可能觉得安排合理。

如果每周超出的8小时持续四周，累计缺口就是32小时，约等于该岗位一周以上的可规划产能。结果未必表现为“加班32小时”，也可能表现为评审等待、缺陷修复延后、工作切换增加或交付范围被压缩。PMO要关注的是容量缺口及其后果，而不是单纯要求员工填更多工时。

三、常见误区：比例写得很细，不等于计划更可靠

1. 把投入比例当成精确工时承诺

“投入50%”通常是一个规划粒度，不是对未来每个小时的保证。知识工作中的问题复杂度、评审往返和外部依赖都会变化。若组织要求每个人提前数月承诺精确到个位数的比例，表格看起来更精细，实际却可能只是把不确定性包装成确定数字。

我建议区分三种概念：容量比例用于中期资源规划；工作量估算用于判断任务规模；实际工时或工作记录用于复盘投入。三者可以关联，但不能互相冒充。比例解决“可用多少”，估算解决“需要多少”，实际记录解决“发生了什么”。

2. 把100%误解为全天无缓冲

如果员工的所有可用时间都被排满，任何临时评审、客户问题或返工都会造成连锁延误。满载不是高效率的同义词，而是降低响应能力的信号。具体缓冲比例不能照搬固定数字，应结合工作波动、服务等级、关键岗位替代性和历史突发量测算。

对稳定、重复、依赖关系少的工作，可以安排较高的计划利用率；对需求变化频繁、线上故障影响大的岗位，应保留更充分的机动容量。PMO应看岗位和团队层面的风险分布，而不是机械规定所有人都必须留出同一比例。

3. 把一个人的比例复制到所有月份

投入并不总是均匀发生。开发阶段可能需要较高研发投入，联调阶段需要测试和架构支持，验收阶段则会集中占用业务专家。将“某人投入30%”复制到整个季度，会掩盖工作峰值和角色交接，导致关键节点缺人、其他阶段却出现闲置。

更稳妥的计划方式是按周或按迭代维护近期资源承诺，对较远期只保留阶段性需求区间。时间窗口越近，计划颗粒度可以越细；时间窗口越远，不确定性越大，应该使用范围而不是假装精确的单点值。

4. 把所有项目都当成同等优先级

资源冲突并不能靠“每个项目都重要”解决。冲突发生时，PMO需要组织业务负责人对价值、合规、客户承诺、依赖关系和延迟成本进行比较。没有明确优先级，就会出现多个项目各自私下加码，最终由执行人员通过加班和频繁切换承担成本。

遇到冲突时，我会要求提出资源需求的项目同时说明：若不获得资源，影响的具体里程碑是什么；能否缩减范围；能否调整顺序；是否有替代人员；延后一个周期的业务代价是什么。资源审批不应只批“要人”，还要批相应的范围、优先级或延期选择。

5. 用实际工时倒推计划是否合理

实际工作记录有价值，但不应被当作计划质量的唯一评价指标。工时记录偏高可能是估算不足、范围变更、人员能力不匹配，也可能是登记口径变化；偏低则可能代表工作被延期、记录不完整或任务实际比预期简单。脱离原因分析，只看高低很容易惩罚报数的人，反而让数据质量下降。

PMO应把计划偏差拆成可解释类别：需求变化、外部依赖、估算误差、人员不可用、质量返工、临时支持和记录偏差。只有知道偏差原因，才知道应该改计划、改流程、补能力还是重排优先级。

四、专业判断逻辑：从工作包推导投入比例

1. 先明确范围和时间窗口

资源估算之前，我会先确认交付物、验收条件、主要依赖和目标日期。若范围仍在讨论，资源比例只能作为初步区间，不应被当作正式承诺。对需求不确定的项目，先安排短周期探索或技术验证，再根据结果更新估算，通常比直接报一个看似精确的比例更可靠。

时间窗口也要明确。项目总体规划可以按月或阶段表达资源需求，近期执行计划则需要落到周或迭代。计划越接近执行，越应核实人员实际日历、休假、值班和其他项目承诺。

2. 以工作包识别角色，不以岗位名称直接分配人

我会把项目拆成可估算的工作包，例如方案评审、接口开发、数据迁移、自动化测试、上线验证。每个工作包标出需要的角色、预计持续时间、依赖关系和完成标准。随后再确认具体人员。这样既能看出能力缺口，也能避免“项目需要两个人”却没有说明所需技能的粗糙申请。

工作包不用拆到每个小时。拆分的标准是：负责人能解释估算依据，依赖关系能被管理，完成结果能被验收。拆得太粗会看不到阶段性峰值；拆得太细则维护成本高，计划很快失效。

3. 区分名义工时、可规划产能和项目需求

可用一个简单公式作为起点：可规划产能＝名义工作时间－休假及节假日－固定职能工作－已确认的非项目职责－合理的机动容量。项目投入比例则可按“分配到该项目的计划工时÷可规划产能”计算，并明确时间范围。

例如一周名义工作40小时，扣除平均4小时固定会议、4小时支持职责和4小时机动容量，可规划产能为28小时。项目计划每周分配14小时，则相对于可规划产能是50%；若相对于名义工时表达，则是35%。两个比例都可能正确，但必须标注分母。不写分母的投入比例，不能用于跨团队比较。

4. 同时看个人、岗位和项目三个层级

个人层面检查是否超配，岗位层面检查稀缺能力是否成为瓶颈，项目层面检查关键路径是否获得足够资源。只看个人会忽略某项关键能力整体短缺；只看项目会忽略一个人被多个项目重复预约；只看岗位总量又可能掩盖某位资深人员的不可替代性。

我通常至少检查三个问题：关键任务是否有明确负责人；高峰期是否集中依赖同一人员；人员调整是否会影响连续性和交接成本。必要时还要加入地点、权限、语言、合规要求和系统访问等限制，因为“名义上有空的人”未必能立即承担工作。

5. 设置分级计划精度和触发阈值

计划不需要所有角色都精确到同一程度。核心路径上的稀缺角色应更早确认；一般支持角色可以用区间估算；需求仍不确定的工作则列为待验证容量。PMO可以设定组织自己的预警规则，例如当某人在连续两个周期的计划承诺高于核定容量，或关键角色需求超过供给时，必须触发资源评审。

阈值应根据组织历史和风险偏好校准，不要把示例数字直接变成硬性制度。成熟度较低的团队先用“绿、黄、红”识别超载风险就够了；当口径稳定后，再逐步引入更细的容量利用率、计划偏差和岗位缺口分析。

五、从0到1落地：建立可维护的人力资源计划

1. 第一步：统一口径，先约定“比例代表什么”

PMO应先发布简短的口径说明，至少定义分母、时间单位、工作类型和更新频率。比如投入比例是相对于每周可规划产能，还是名义工作时间；“已分配”代表经经理确认，还是项目经理提出的需求；实际投入是工作记录，还是团队复盘的粗略估算。

如果口径尚未统一，建议先选一个业务单元试运行。试点中把有争议的项目记录下来，再修订定义。不要一开始就建设覆盖全公司的复杂模型，否则组织会花很多时间争论字段，却没有形成可用的资源决策。

2. 第二步：盘点角色、技能和容量约束

资源盘点不应只包含姓名和部门。至少需要知道角色、关键技能、负责人、可投入时间窗口、持续性职责、不可替代性和必要限制。涉及个人敏感信息时，应遵循组织的数据访问和隐私政策，只收集资源决策真正需要的信息。

容量数据的来源可以包括团队日历、项目计划、值班表、岗位职责和请假安排。不同数据源更新频率不同，PMO应标明更新时间和责任人。超过一定周期未确认的容量信息，应标记为待核实，不能默认仍然准确。

3. 第三步：建立项目需求清单并区分需求状态

项目经理提出需求时，要说明所需角色、预计投入、起止时间、工作包、优先级和需求置信度。PMO可以把需求分为“已确认、待审批、待验证、备选”四种状态，避免把所有申请都当作已经承诺的资源占用。

当需求跨团队时，还要明确资源提供方和决策人。项目经理提出需求，不等于职能经理已经批准；职能经理同意借人，也不等于项目范围与时间目标已经同步调整。批准链条要清晰，避免资源在表格中被标为已分配，实际却无人负责。

4. 第四步：先解决冲突，再公布基线

把人员需求与容量放在同一时间轴上，识别超配、峰值和关键岗位缺口。冲突处理顺序可以是：核实需求是否真实；检查能否调整任务顺序；评估能否缩减范围；确认替代能力；最后再决定借调、招聘、外包或延期。

资源基线应包含批准日期、责任人和变更记录。若中途发生需求变更，不能只覆盖旧数字。保留变更原因，才能在复盘时判断预测问题来自估算、范围管理还是组织优先级变化。

5. 第五步：建立固定节奏，避免计划一次性过期

可以把资源复核嵌入既有的项目评审节奏，而不是另造一套繁重会议。周度检查近期冲突和人员不可用情况；月度检查关键岗位供需和项目优先级；季度复盘则查看需求预测偏差、技能短缺和组织结构性瓶颈。具体频率应适配业务变化速度。

每次复核聚焦例外项，而不是逐人朗读表格。建议优先讨论容量超限、关键路径缺人、连续偏差、需求变更和未决资源申请。这样既能保持治理强度，也避免团队把大量时间耗在低风险数据确认上。

6. 第六步：选工具时先验证流程，不先追求功能清单

对百人以上组织，工具的价值在于让项目计划、工作项、责任角色和风险信息能够相互关联，并支持按团队或项目观察资源需求。以PingCode这类项目管理平台为例，组织可以先验证项目与任务信息是否能被团队持续维护，再评估是否能满足内部的权限、报表和协作要求。具体能力、版本和配置方式应以实际产品说明及试用验证为准。

我会优先检查四件事：输入是否足够简单；不同角色能否看到适合自己的视图；计划变更是否留下记录；报表中的分母和时间口径是否可解释。若系统只能汇总数字，却不能追溯到工作包、责任人和变更原因，数据看板再漂亮也难以支持决策。

六、案例与数据观察：一组模拟数据怎样指导取舍

1. 说明数据边界，避免把示例误当行业基准

下面是一组情景模拟，不是公开行业调查，也不代表任何企业的真实实施结果。它用于展示PMO如何从容量供需推导动作。设某产品团队未来四周的可规划产能为：后端工程师112小时、测试工程师84小时、产品分析师56小时。

三个项目分别提出角色需求。项目甲需要后端80小时、测试36小时、产品分析师16小时；项目乙需要后端40小时、测试40小时、产品分析师28小时；项目丙需要后端16小时、测试20小时、产品分析师20小时。需求合计后，后端超出24小时，测试超出12小时，产品分析师有8小时余量。

2. 总量看起来接近，不代表关键角色没有缺口

团队三类角色的总容量为252小时，需求合计为256小时，整体只超4小时。若只看总量，管理者可能认为几乎平衡；但后端与测试已经分别超配，产品分析师却有余量。人员资源不能像同一种库存一样互相抵消，产品分析师的闲置时间不能直接填补后端开发缺口。

这也是资源计划必须按角色和能力拆分的原因。总量指标适合做宏观观察，不足以做调度决策。真正要解决的问题是：哪些能力构成瓶颈，瓶颈是否位于关键路径，能否通过范围、顺序、替代技能或时间调整化解。

3. 用优先级和可替代性处理冲突

假设项目甲涉及已承诺的客户交付，项目乙是提升内部效率的功能，项目丙是尚未验证需求的探索工作。此时不应简单地让三项目按比例削减。可以先核实项目丙是否必须在当前周期完成，再看项目乙能否分批交付，最后保护项目甲关键路径上的后端与测试容量。

如果项目丙的探索价值仍然重要，可以保留一个小规模验证工作包，而不是完整投入20小时产品分析师和16小时后端工程师。缩小范围并非降低项目重要性，而是先用有限资源降低不确定性。待验证结果明确后，再决定是否扩容。

4. 设定调整方案并衡量副作用

一个可讨论的模拟方案是：项目甲优先获得关键路径资源；项目乙将部分非关键功能移至下一周期；项目丙只保留验证工作。这样可能减少后端和测试的峰值需求，但代价是项目乙范围缩减、项目丙交付时间后移。PMO要把取舍写进决策记录，而不是把工作悄悄转成团队加班。

调整后的计划仍需复核角色匹配和时间分布。例如总需求下降了，但如果测试工作集中在最后一周，仍可能形成阶段性瓶颈。容量判断要看整个时间窗口的分布，不能只看四周总数。

七、不同情况下的行动建议：按组织成熟度和工作性质调整

1. 组织刚开始做资源计划

先从一个项目群或一个职能团队试点，不要一口气要求全公司填报复杂工时。试点重点是统一比例口径、发现重复预约、建立冲突升级路径。可先按角色和周容量估算，再逐步增加人员级信息。

若团队对计划数据缺乏信任，应公开说明数据用途：用于预测和协调，不直接等同于个人绩效评分。否则员工会倾向于报“看起来安全”的数字，计划系统很快失去可信度。

2. 项目需求稳定、工作重复度较高

对于版本节奏稳定、工作类型重复的团队，可以使用历史实际投入校准未来计划。比如按过往多个周期的角色工作量区间估算，而不是只采用一次项目的偶然结果。使用历史数据时要排除范围明显不同、突发事故或资源严重短缺的异常周期，并记录调整理由。

此类团队可以逐步提高计划细度，重点观察计划偏差、返工率和周期稳定性。若比例表明资源长期满载，但交付速度并未提高，应检查等待、审批、切换和返工，不要先假设是人员不足。

3. 项目需求变化快、探索性强

对探索型项目，远期人员级计划容易失真。建议先确认关键能力和最小验证周期，把资源承诺分成短期已确认量与远期需求区间。每个阶段结束后根据证据重新评估，而不是把最初的估算一直沿用到项目结束。

同时要预先定义停止、继续或扩大的判断条件。没有退出标准的探索工作容易长期占用共享专家；有了条件，资源评审就能围绕证据展开，而不是围绕项目名称争取预算。

4. 关键岗位稀缺或共享程度高

架构、安全、数据平台和发布运维等岗位，通常不适合按项目经理报来的比例简单切分。应建立集中需求窗口，统一排序，明确服务范围、响应等级和容量边界。对瓶颈岗位，还要识别替代人选和知识转移计划，降低单点依赖。

如果可替代能力短期内无法培养，管理层必须在进度、范围、外部采购和风险之间做明确选择。把稀缺岗位的超配隐藏在“支援一下”之中，只会让故障和延期集中暴露。

5. 多项目组合之间优先级经常变化

若项目优先级每月都发生变化，资源计划需要把决策机制放在核心位置。建议设定固定的组合评审时间，并规定紧急插单需要说明谁批准、挤占了哪项原计划工作、造成什么影响。没有挤占记录的插单，等于把成本转嫁给所有项目。

项目组合负责人还应保留变更历史。持续追踪哪些项目频繁要求临时资源，可能揭示需求治理、商业承诺或项目立项质量的问题。资源计划不仅预测人力，也能反向暴露组织决策的不稳定性。

6. 需要用项目管理平台支撑协作

当项目、团队和工作项数量增加时，可考虑用项目管理平台统一项目计划与执行信息，并建立必要的报表视图。以PingCode为例，中大型组织可以先用一个项目群验证：负责人是否愿意维护计划，角色需求是否能按时间窗口汇总，资源冲突能否从报表追溯到具体工作项，权限是否符合组织要求。

建议采用小范围验证而非一次性全量上线。试点前定义成功标准，例如资源信息更新时间、冲突发现提前量、计划变更可追溯率和月度统计耗时。具体目标应基于当前基线设定，不能把示意数据当成产品承诺或行业效果。

八、不同情况下的取舍：效率、准确性和治理成本不可能同时最大化

1. 个人级精确计划与团队级粗粒度计划

个人级计划更适合关键路径明确、团队规模可控、资源冲突成本高的场景，能更早发现某位专家被重复预约。代价是维护频率和沟通成本更高，也更容易被误用为对个人的微观监控。

团队级粗粒度计划更适合需求变化大、人员会灵活协作的环境，更新负担较低，但可能掩盖关键技能集中和具体人员不可用。我的建议是按风险分层：关键角色按人核验，一般角色先按团队容量管理，不必所有岗位都使用同样颗粒度。

2. 高利用率与交付韧性

高利用率看起来能减少闲置，但会缩小处理突发事件和需求变化的空间。对工作稳定、可替代、依赖少的岗位，高利用率可能有经济合理性；对线上支持、复杂研发和关键审批岗位，过度压满可能导致等待时间上升，整体交付反而变慢。

判断是否留缓冲，不应只看“有没有空闲”，还要看突发工作的频率、影响和恢复成本。如果短暂空闲能避免严重延期或服务中断，它不是浪费，而是为不确定性购买响应能力。

3. 统一制度与团队自主性

PMO统一数据定义、冲突升级规则和决策记录，能提高跨团队可比性；但若把每个团队的工作方式、周期和岗位责任强行标准化，制度会变得僵硬。适合统一的是数据口径和治理底线，不适合统一的是所有团队的容量假设和计划颗粒度。

可以建立“组织标准加团队参数”的做法：统一投入比例分母、状态定义和更新责任；由团队根据会议、支持工作、节奏和岗位特点提出容量参数，经职能负责人确认。PMO定期用数据复核参数，而不是把一个全公司通用比例套到所有人。

4. 工时记录与轻量状态更新

详细工时记录有助于成本核算、合同管理和历史估算，但会增加记录负担，也可能诱导团队关注填报而非结果。轻量状态更新更省事，适合以协调为主的资源计划，却无法支持精确成本分摊。

选择时要先问业务问题是什么。如果需要财务核算，就必须设计可审计的工时口径；如果主要目标是提前发现容量冲突，可以采用周期容量与异常说明。不要为了“看起来数据更多”而收集组织不会使用、员工也不信任的信息。

九、衡量计划是否有效：从填表率转向决策质量

1. 监控指标要能推动动作

投入比例管理的指标不能只停留在“多少人完成填报”。更有用的指标应能说明资源风险是否更早暴露、决策是否更及时、项目预测是否更可信。指标体系不必一次做全，可以先从少数核心指标开始，再根据管理问题扩展。

• 容量冲突发现提前量：冲突在关键里程碑之前多久被识别。
• 计划变更可追溯率：发生的资源调整中，有多少记录了原因、批准人和受影响项目。
• 关键岗位需求满足率：关键时间窗口内，已确认需求获得匹配能力支持的比例。
• 计划偏差分类完整度：发生明显偏差时，是否有一致的原因分类和复盘结论。
• 资源决策周期：从提出冲突到形成范围、人员或时间决策所需的时间。

2. 不要把指标变成绩效排名

这些指标适合观察系统是否有效，不适合直接对个人做简单排名。某团队的计划偏差高，可能源于需求频繁变化；另一个团队偏差低，也可能是把不确定工作隐藏在计划外。必须结合范围变更、依赖阻塞、工作类型和数据完整度解释结果。

如果团队发现报出风险会被追责，风险就会延迟暴露；如果计划超载总是靠个人加班补齐，表面上的里程碑达成反而会掩盖治理问题。PMO要奖励及时披露真实约束和提出可行替代方案，而不是奖励“从未偏差”的表面稳定。

十、结尾：先建立可信的承诺，再追求更细的比例

1. PMO入门阶段最值得做的三件事

第一，统一投入比例的分母和时间窗口，避免把名义工时、可规划产能和实际投入混在一起。第二，按角色和工作包核对需求，把共享职责、关键岗位和容量缓冲纳入视野。第三，建立资源冲突的决策机制，让范围、优先级、人员和延期能够被共同取舍。

这三件事看起来不如做一张漂亮的资源热力图直观，却决定了图表里的数字是否可信。工具和报表能提升可见性，但只有明确的数据口径、责任边界和决策权限，才能把可见性转化成实际行动。

2. 下一步从一个四周滚动窗口开始

如果你正在从0开始，可以先选一个项目群，明确角色容量，梳理未来四周的工作包和已有承诺，标记超配与关键岗位缺口。召开一次只讨论例外项的资源评审，把每个冲突落实为具体选择：调整范围、改变顺序、引入替代能力、补充资源或接受延期。

一个好的投入比例，不是每个人都刚好填到100%，而是组织能解释每份承诺来自哪里、冲突由谁决策、变化如何被记录。PMO真正要管理的不是比例本身，而是比例背后的工作、容量和取舍。