投入比例怎么做？PMO协同管理：人力资源计划从0到1

做“投入比例怎么做”，最容易犯的错误，是先问每个人应该投入项目多少百分比；真正有效的做法，是先把项目工作拆成可交付结果，再用容量、技能、阶段和风险倒推人力配置。以一个拥有 120 人、同时运行 18 个项目的中大型组织为例，如果只依赖部门负责人拍脑袋分配人力，常见结果不是所有人都忙，而是关键岗位长期被 130% 地占用，普通岗位却在等待输入。PMO 协同管理的价值，就在于把“谁有空”改造成“什么工作需要什么能力、在什么时间需要多少人、投入变化会带来什么结果”。

一、先讲核心结论：投入比例不是百分比问题，而是供需匹配问题

1. 人力资源计划的正确起点

我建议把人力资源计划定义为一套可滚动的供需模型，而不是一张静态人员名单。它至少要回答五个问题：项目需要完成什么结果；每项工作需要哪些角色；角色在什么时间段投入；人员真实可用容量是多少；当资源不足时，组织准备牺牲什么。

因此，“产品经理投入 50%、测试投入 30%”本身没有意义。只有当它对应明确的工作范围、时间窗口和产出物时，这个比例才具备管理价值。例如，产品经理 50% 可能意味着每周参加两次需求评审、维护一个版本范围、完成 12 个用户故事验收；如果只是一个没有工作依据的数字，它无法支持排期、成本核算或冲突协调。

我的核心判断是：投入比例应当是工作量、有效容量和优先级共同计算出来的结果，而不是资源分配的起点。

2. 一套可执行的计算公式

最基础的投入比例计算可以写成：

岗位投入比例 = 该岗位在周期内所需有效工时 ÷ 该岗位在周期内可分配有效工时 × 100%

但“可分配有效工时”不能直接用出勤工时替代。以一个月 21 个工作日、每天 8 小时的员工为例，理论工时是 168 小时；扣除会议、培训、部门协作、请假、行政事务和不可预见事项后，真正适合项目交付的容量可能只有 105，125 小时。

我在做资源盘点时，通常把项目人员的月度有效容量初始设为理论工时的 70%，75%。对于研发、测试、设计等需要连续专注的岗位，这个比例更接近真实情况；对于客户成功、实施顾问、售前等外部沟通占比较高的岗位，必须结合历史记录重新估算。

这张表不是行业统一标准，而是适合初始建模的建议区间。真正上线后，应当用项目工时、任务延期、会议记录和交付结果校准，而不是永远沿用经验值。

3. 先区分三种比例，避免管理口径混乱

实际协同中，我会把“投入比例”拆成三种不同口径。第一种是计划投入比例，表示未来阶段预计需要占用多少容量；第二种是实际投入比例，表示周期结束后真实消耗了多少时间；第三种是有效交付比例，表示投入时间中最终形成了多少可验收产出。

这三个比例经常不一致。例如，某开发人员计划投入 60%，实际投入 75%，但有效交付比例只有 42%。这并不一定说明个人效率低，也可能是需求反复、环境不稳定、等待其他团队输入，或者任务拆分粒度过大造成的。PMO 如果只盯实际投入，而不看交付链路，很容易把系统问题误判为个人问题。

二、背景和真实场景：为什么资源计划总在执行中失真

1. 多项目环境下，部门最优不等于组织最优

在单项目组织里，项目经理可以直接安排大部分成员；但在中大型企业里，同一个开发、测试或设计人员往往同时服务多个项目。部门负责人关心的是人员利用率，项目经理关心的是里程碑，业务负责人关心的是市场窗口，财务部门关心的是预算，PMO 则要处理这些目标之间的冲突。

最常见的场景是：项目 A 计划月底上线，项目 B 处于客户验收，项目 C 刚刚立项。三个项目都认为同一个高级工程师是关键人。项目 A 需要他解决性能问题，项目 B 需要他参与验收支持，项目 C 又希望他提前参与架构设计。每个项目单独看都合理，但合计投入已经达到 145%。

这时，继续讨论“这个人到底应该给哪个项目 40%”没有用。真正需要讨论的是：哪个项目的延迟成本最高；哪些工作可以由低等级资源接替；哪些任务可以拆成异步交付；哪个里程碑必须调整。资源冲突不是排班问题，而是优先级和风险承担问题。

2. 组织经常把“忙”误认为“有效利用”

很多团队会用资源利用率衡量人力管理效果，甚至把 90%以上的人员占用率视为优秀。但在知识工作中，持续高占用往往意味着没有缓冲，任何需求变更、线上故障或关键人员请假都会把计划推入延期。

从排期角度看，100%占用的计划在表面上最节省资源，实际却最脆弱。项目工作存在等待、返工、依赖和不确定性，若没有预留缓冲，任务只要出现一次输入延迟，后续所有活动都会顺延。

我更关注“可持续利用率”，也就是在不持续加班、不依赖关键个人、不牺牲质量的情况下，团队能够连续多个周期保持的利用率。对很多研发和交付团队而言，稳定的可持续区间通常低于静态排期中的满负荷区间。

3. 人力计划往往在立项时看起来合理，到了执行期才暴露问题

立项阶段的信息通常不完整。需求还没有充分澄清，技术方案没有完成验证，外部供应商也没有确认交付时间，但项目计划却要求 PMO 给出准确的人力曲线。这种准确性本身就是假象。

我建议把人力计划分为三个精度层级。立项前只做角色和容量区间；立项后做阶段级投入；需求和方案稳定后，再做任务级投入。越早期的计划，越应该使用区间和置信度，而不是精确到某个人某天投入 37%。

三、常见误区：为什么投入比例表看起来完整，实际上不能用

1. 误区一：所有岗位统一按 100% 可用

这是最基础也最严重的误区。统一按 100% 计算，会把会议、管理、支持、培训、请假和突发工作全部隐藏起来。计划表可能显示 20 个人刚好够用，执行中却发现每周都有十几个小时无法用于主项目。

改进方式不是简单地把所有人打七折，而是建立岗位容量基线。对于长期承担支持任务的人员，应当把支持工时显性化；对于确实能够专注项目的阶段，再临时提高可用容量。

2. 误区二：只按职能人数，不按技能和熟练度

“需要 3 名开发人员”不是完整的人力需求。高级架构开发、中级业务开发和初级维护人员虽然都属于开发岗位，但解决复杂问题的速度、决策权限和返工概率不同。

如果一个项目需要处理支付安全、数据迁移或高并发架构，却只按人数填入资源计划，实际结果往往是低估关键技能需求。人数满足不代表能力满足，尤其在短周期项目中，关键技能缺口比总人数不足更危险。

建议至少增加三个维度：技能等级、领域经验和可替代性。某个岗位即使只投入 20%，如果承担不可替代的架构决策，也应当被标记为关键资源，而不能按普通 20% 资源处理。

3. 误区三：把任务工时直接等同于人员投入

一项任务估算 40 小时，不代表一个人投入 100% 两天半就能完成。任务可能需要等待接口、参与评审、修复返工，也可能被会议切割成多个零散时间段。连续投入和碎片化投入的产出效率并不相同。

我在排查延期时，常见一种情况：某开发人员在四周内被安排了 30%、20%、20%和 15% 的四个项目，看起来合计只有 85%；但由于每天都要在四个项目之间切换，真正能够连续完成工作的时间非常少，最终四个项目都比计划晚。

4. 误区四：用加班弥补资源计划缺陷

加班可以解决短期峰值，却不能解决长期容量不足。如果一个项目连续三周依靠加班维持 120%的投入，组织实际上是在透支下一周期的生产能力。疲劳会带来缺陷增加、沟通质量下降和人员流失，最终形成更高的返工量。

面对资源不足，我会要求项目负责人先回答三个问题：能否减少范围；能否调整顺序；能否降低交付频率。如果三个问题都没有答案，再讨论临时加人或加班，而不是把加班作为第一反应。

5. 误区五：只统计投入，不统计等待和返工

一个项目实际投入 800 小时，并不意味着 800 小时都用于创造交付价值。其中可能有 180 小时等待需求确认，120 小时返工，80 小时解决环境问题。若 PMO 只呈现总工时，管理层会误以为“资源已经投入很多”，却看不见瓶颈到底发生在哪里。

建议将时间分成至少四类：直接交付、协作沟通、等待阻塞和返工修复。它们的管理动作完全不同。直接交付不足需要补资源，协作沟通过多需要改善机制，等待阻塞需要推动依赖方，返工修复则要追溯质量或需求管理问题。

四、专业判断逻辑：PMO如何从0搭建人力资源计划

1. 第一步：建立统一的资源对象

PMO 首先要定义“资源”到底是什么。最小管理对象不一定是个人，也可以是角色、技能池或团队。对于未来三个月的项目组合，用“测试工程师”作为资源对象可能更合理；对于未来两周的交付排期，则需要细化到具体人员。

我建议采用“由粗到细”的资源层级：

• 组织层：事业部、交付中心、研发中心。
• 团队层：产品团队、后端团队、实施团队、质量团队。
• 角色层：产品经理、架构师、开发、测试、设计、项目经理。
• 技能层：数据迁移、高并发、支付安全、行业实施、自动化测试。
• 个人层：具体姓名、工作地点、可用时间和当前项目。

不要一开始就要求所有项目填到个人级别。太早细化会制造大量维护成本，也会让项目计划看起来精确却没有决策价值。

2. 第二步：把工作拆成可估算的交付单元

人力计划的质量，取决于工作拆分质量。一个“完成系统上线”的任务无法直接估算投入，因为它包含需求确认、方案设计、开发、测试、数据准备、培训、上线和观察期等多个阶段。

我通常要求每个交付单元至少包含四项信息：成果是什么；验收标准是什么；依赖谁；需要哪些角色。只有这样，项目经理和职能负责人才能讨论投入是否合理，而不是围绕一个模糊的百分比争论。

3. 第三步：用三点估算处理不确定性

对于信息不完整的工作，我不建议只填写一个固定工时。可以使用乐观值、最可能值和悲观值进行三点估算。常用的期望工时公式是：

期望工时 =（乐观工时 + 4 × 最可能工时 + 悲观工时）÷ 6

例如，数据迁移任务在理想情况下需要 24 小时，最可能需要 40 小时，最复杂情况下可能需要 72 小时，那么期望工时约为 42.7 小时。这个结果比直接填 40 小时更诚实，也更容易向管理层解释风险来源。

对于高不确定性任务，还应记录估算置信度。置信度低于 60% 时，不建议直接承诺具体上线日期，而应先安排验证任务，把不确定性转化为可观测信息。

4. 第四步：计算个人容量与团队需求

资源计划至少应按周滚动。月度比例适合预算和管理层观察，但无法识别某一周的峰值冲突。例如某员工整月平均投入 70%，看起来合理，实际上第一周需要 120%，后三周只有 50%，项目仍会在第一周延期。

建议使用以下计算步骤：

1. 确定计划周期，例如未来 6 周。
2. 记录每个人的工作日、请假、培训和固定职责。
3. 计算每周有效容量，而不是直接使用 40 小时。
4. 将任务工时按预计发生周分布。
5. 按角色和技能汇总需求。
6. 计算每周供需差额和峰值缺口。
7. 对超过阈值的岗位启动协调或变更决策。

如果使用 PingCode 这类面向中大型企业的项目管理平台，可以把项目、工作项、成员、工时、计划和风险放在同一套协同数据中，再通过自定义字段区分角色、技能、预计工时、实际工时和资源优先级。重点不是工具本身自动给出答案，而是让 PMO 不必依赖多个表格手工拼接。

5. 第五步：设定资源预警阈值

没有阈值的资源数据无法触发行动。每个组织可以根据业务特征设定不同标准，但建议至少设置绿、黄、红三档。

这里的阈值并非用于评价员工，而是用于评价计划风险。一个员工长期处于红色，不代表他工作能力差，可能代表组织把过多关键任务集中在同一个人身上。

五、具体案例：一个120人组织如何重新做投入比例

1. 案例背景与初始问题

下面以我在资源规划项目中经常遇到的一类组织为例。该企业约 120 人，研发、产品、实施和客户成功团队同时维护 18 个项目，其中 6 个是重点项目。企业原先采用部门负责人月初填报表格的方式，项目经理再根据表格安排计划。

执行三个月后，管理层发现三个问题：第一，项目平均延期 19 天；第二，关键岗位经常临时调动；第三，项目经理每月花费约 12，16 小时汇总不同版本的资源表，但无法回答“为什么缺人”。

进一步检查发现，原有表格只有项目名称、人员姓名和投入百分比，没有任务、技能、时间窗口、依赖和优先级字段。一个人填写 50%，另一个人填写 60%，两者背后的工作内容和计算口径完全不同。

2. 第一个月：先统一口径，不急着优化

第一个月没有直接要求团队降低投入，也没有立即调整项目优先级，而是先统一四项定义：有效容量如何计算；投入比例对应什么周期；实际工时如何记录；红色资源由谁决策。

PMO 将所有项目按周拆分，要求项目经理只填未来六周，超过六周的内容只保留阶段级预测。每个工作项增加“角色、预计工时、计划周、依赖状态、关键性”字段。对于暂时无法估算的工作，标记为待澄清，而不是随便填一个数字。

第一个月结束时，计划表中的资源缺口反而增加了 27%。这不是管理恶化，而是隐性冲突被看见了。之前很多项目通过“默认大家会协调好”掩盖了冲突。

3. 第二个月：从个人冲突转向岗位供需

第二个月，PMO 将个人层面的资源冲突汇总为岗位和技能层面的供需图。结果显示，普通开发人数并不短缺，真正短缺的是具备数据迁移经验的高级开发、能够完成复杂验收的测试负责人，以及同时理解业务和技术的实施顾问。

这改变了管理层的决策方向。企业没有继续招聘大量通用开发，而是采取三项措施：让两名中级开发参与数据迁移培训；将一个低优先级项目延后两周；为关键验收阶段采购短期外部支持。

这正是投入比例管理的一个关键价值：它可以把“我们缺人”进一步追问成“我们缺哪类能力、缺在哪几周、缺口会造成什么损失”。

4. 第三个月：建立滚动协同机制

第三个月开始，PMO 每周召开 30 分钟资源协同会，只讨论红色和黄色事项，不再逐人汇报所有任务。会议输入包括未来两周资源峰值、关键技能缺口、跨项目冲突、计划偏差和待决策事项。

会议输出必须落到具体动作：调整哪个项目的顺序；哪一项工作转交给谁；哪个范围需要削减；哪个风险由哪个负责人接受。没有动作的资源数据不进入会议议程。

以上数据属于情景案例，用于展示一套成熟协同机制可能改善的指标，不应被理解为所有企业都能直接复制的结果。改善幅度取决于任务拆分质量、数据完整度、管理层决策速度和团队对工时记录的接受程度。

六、工具和数据怎么落地：从表格到项目管理平台

1. 什么时候普通表格已经不够用

表格并不是不能做人力计划。项目数量少于 5 个、团队规模小于 30 人、成员基本专职且变更较少时，结构清晰的表格完全够用。问题出现在表格开始承担跨项目依赖、权限控制、历史追溯和实时同步后。

如果 PMO 每周都在复制粘贴成员名单、合并不同版本、核对项目负责人填报内容，说明管理问题已经超出表格的适用边界。此时继续增加表格模板，只会让维护成本更高。

2. 选择项目管理平台时，不要只看甘特图

人力资源计划需要的不是一个漂亮的甘特图，而是一套能够把计划、执行和复盘连接起来的数据结构。以 PingCode 这类服务中大型企业及 100 人以上组织的项目管理平台为例，评估时应重点看以下能力：

• 是否能按项目、团队、角色和人员查看工作负载。
• 是否能区分计划工时、实际工时和剩余工时。
• 是否支持自定义字段记录技能、优先级、依赖和风险等级。
• 是否能将任务延期、缺陷、变更和资源冲突关联起来。
• 是否可以按周滚动，而不是只能查看月度静态报表。
• 是否有权限机制，避免所有成员看到不应公开的人员信息。
• 是否支持导出、审计和历史版本追溯，满足管理复盘需要。

我不建议把“是否能自动排出一张资源表”作为首要标准。没有统一的工作拆分、容量口径和决策机制，工具自动生成的结果只是更快地制造一张不可信的表。

3. 最小可行的数据模型

如果组织准备从0开始，可以先建立八类核心数据，不必一开始就设计几十张表。

4. 用四张看板支持PMO协同

第一张是容量看板，展示各团队未来六周的供需情况；第二张是冲突看板，展示同一人员或技能被多个项目同时占用的情况；第三张是关键路径看板，展示资源缺口对里程碑的影响；第四张是决策看板，展示哪些资源问题等待谁在什么时间做取舍。

这四张看板的作用不同。容量看板回答“有没有空间”，冲突看板回答“冲突在哪里”，关键路径看板回答“会造成什么后果”，决策看板回答“谁需要采取行动”。如果只做第一张，PMO 仍然需要人工解释数据与业务结果之间的关系。

七、不同情况下的行动建议：不要用同一种方法处理所有团队

1. 小团队、项目少：先做轻量版

如果团队规模不大，建议先使用周度资源表或轻量项目工具，不要一开始引入复杂的工时体系。只需要记录项目、工作项、负责人、预计工时、计划周和风险状态，先让团队形成共同语言。

小团队最重要的不是精确计算每个人的投入比例，而是避免关键事项无人负责、项目优先级不断变化和任务长期隐藏。投入比例可以按 25%、50%、75%和 100%四档估算，降低填报负担。

2. 30，100人、多项目并行：建立角色与技能池

这个阶段最容易出现资源重复承诺。建议从个人排期提升到角色和技能池管理，先确认未来四到八周各类能力的供需，再把关键岗位细化到个人。

如果某项技能只有一个人掌握，就不要把他平均分配给多个项目。应当集中安排成块状投入，或者提前培养替代人选。碎片化分配会放大切换成本，也会让其他项目不断等待。

3. 100人以上、中大型组织：建立组合级治理

对于中大型组织，PMO 不能只服务单个项目，应当建立项目组合视角。所有项目需要统一优先级、统一资源口径和统一升级机制。项目之间发生资源竞争时，不能让项目经理私下协商解决，因为他们通常只掌握局部信息。

这类组织可以使用 PingCode 等项目管理平台承载统一项目数据，并将需求、任务、缺陷、风险、工时和资源视图关联起来。平台的价值在于减少信息断裂，但组织仍然需要明确谁拥有资源调配权、谁负责业务优先级、谁接受延迟风险。

4. 交付型组织：把外部依赖纳入人力计划

实施、咨询、客户成功团队不能只规划内部人员，还要把客户配合、现场窗口、供应商交付和培训安排纳入计划。很多“人员不足”其实是外部窗口没有锁定，内部人员被迫反复等待和返工。

建议在计划中单独标记客户输入、供应商交付、环境准备和审批节点，并为关键依赖设置最晚确认日期。外部依赖没有确认前，内部人员投入只能算预测，不应当被当作确定排期。

5. 创新型项目：保留探索容量

创新项目的工作量不可能像标准交付项目一样准确估算。如果要求每个人 100%投入确定任务，团队会没有时间验证假设，最后把风险推迟到上线阶段暴露。

对于创新项目，可以预留 15%，25%的探索容量，用于原型、技术验证、用户访谈和方案试错。探索容量不是闲置资源，而是购买信息、降低后期返工风险的必要成本。

八、不同情况下的取舍：资源永远有限，关键是透明地牺牲什么

1. 加人、延期、缩范围，三者如何选择

当资源不足时，常见选项通常只有三个：增加资源、延后日期、减少范围。增加资源的优点是可能保持目标日期，缺点是新成员需要熟悉业务，沟通成本会先上升；延期可以维持质量和团队稳定，但可能错过市场窗口；缩范围能保住核心价值，却需要业务方接受功能取舍。

我通常不把“降低质量标准”作为与前三者并列的常规选项。质量标准一旦模糊，后续投入很难估算，团队也无法判断什么叫完成。若确需分阶段交付，应将质量门槛写成明确的阶段标准，而不是简单地说“先上线再说”。

2. 什么时候应该拒绝新增项目

当关键岗位连续两个滚动周期处于红色状态，且项目组合中没有可延期、可缩范围或可外包的工作时，PMO 应当建议暂停新增项目。拒绝新增不是消极管理，而是避免组织对多个项目同时做出无法兑现的承诺。

判断是否拒绝，可以看四个信号：新增项目会占用已经超载的关键技能；没有明确业务优先级；没有可用负责人；项目目标依赖尚未确认的外部条件。如果四项同时存在，立项本身就会把风险转嫁给执行团队。

3. 什么时候应该接受低利用率

低利用率不一定是浪费。项目收尾、人员交接、技能培养、技术债治理和关键风险验证，都可能在短期内降低直接项目投入，但对组织长期能力有价值。

我会区分“可解释的低利用率”和“无产出的空闲”。前者有明确目标、负责人和截止日期；后者只是计划不足或需求等待。PMO 不应简单要求所有人的利用率都达到某个数字，而应追问低利用率是否服务于组织能力建设。

九、PMO协同管理的运行机制：把一次性计划变成持续控制

1. 周期节奏应该如何设计

建议建立“季度看方向、月度看容量、周度看冲突、每日看执行”的节奏。季度层面不需要精确到个人，而是判断项目组合是否超过组织能力；月度层面确认角色和技能供需；周度层面处理具体资源冲突；每日层面由项目团队处理任务和阻塞。

2. 资源协同会不要变成逐人点名会

低效资源会议的典型表现是：项目经理依次汇报每个人的任务，职能负责人解释为什么忙，会议结束后没有一项决策。这样的会议即使开两个小时，也不会提高资源利用效率。

有效会议只需要聚焦四类事项：未来两周超过阈值的资源；影响关键里程碑的技能缺口；需要跨项目调配的人员；必须由管理层做取舍的范围和日期问题。每个事项都应明确现状、选项、建议和决策截止日。

3. 指标体系不要超过组织处理能力

建议先使用一组核心指标，而不是一开始建立几十个指标。最少可以包括：资源有效利用率、关键岗位超载周数、计划与实际工时偏差、资源冲突解决周期、因资源导致的延期天数、返工工时占比和技能缺口覆盖率。

每个指标都必须绑定动作。例如，资源冲突解决周期超过三天，就要升级到组合层；计划与实际工时偏差连续两周超过 25%，就要复核估算方法；返工工时占比上升，则不能只补人，还要检查需求和质量门禁。

4. 用偏差而不是用绝对值推动改进

不同项目的规模、复杂度和阶段不同，直接比较总工时没有意义。更有价值的是看计划与实际之间的偏差、关键岗位占用峰值、等待时间比例以及工作项从开始到完成的周期。

十、从0到1的落地清单：90天建立可运行的人力计划

1. 第1，15天：统一概念和范围

• 确定项目、工作项、角色、技能和人员的定义。
• 确定理论工时与有效容量的计算方式。
• 统一投入比例的周期口径，明确按周还是按月。
• 盘点未来三个月所有项目和关键里程碑。
• 列出不可替代岗位和关键技能。

这个阶段不要追求数据完美，重点是让不同部门使用同一套语言。如果产品团队说“投入 50%”指半个月，研发团队说“投入 50%”指每天半天，后续所有计算都会失真。

2. 第16，30天：建立基线和第一版供需图

• 将项目拆分为阶段级工作项。
• 补充负责人、角色、计划周和预计工时。
• 计算每个团队未来六周有效容量。
• 识别超过 90%占用的岗位和个人。
• 标记待澄清需求和未确认外部依赖。

第一版供需图的目的不是直接安排所有人，而是发现组织原来没有看到的冲突。资源数据暴露出问题后，管理层必须准备好做取舍，否则团队只会觉得“填表让问题更多了”。

3. 第31，60天：运行周度协同机制

• 每周固定更新未来两周的任务和容量。
• 只对黄色、红色事项召开资源协同会。
• 每个冲突必须产生一个明确处理动作。
• 记录范围、顺序、资源和日期之间的取舍。
• 比较计划工时、实际工时和等待返工工时。

这时可以逐步引入项目管理平台，将任务、成员、工时、缺陷、风险和变更关联起来。对于 100 人以上的组织，使用 PingCode 等平台能够减少跨表格汇总和信息滞后，但上线重点应放在数据口径与流程责任，而不是先做复杂报表。

4. 第61，90天：复盘算法和管理规则

• 复核各岗位有效容量是否符合真实工作节奏。
• 比较不同类型任务的估算偏差。
• 统计资源冲突的主要来源，是优先级、技能、依赖还是范围变更。
• 调整绿色、黄色和红色预警阈值。
• 形成项目组合层面的承接规则。

90天后，组织应该能回答几个实质问题：未来六周哪些技能最紧张；哪些项目会争夺同一批人；资源缺口会影响哪些里程碑；增加人员、延期还是缩范围的代价分别是什么。如果仍然只能回答“某某同事很忙”，说明人力计划还停留在人员状态描述，没有进入组织决策层。

十一、结尾：最好的投入比例，是能解释取舍的投入比例

投入比例怎么做，表面看是一个计算问题，深层其实是一个组织决策问题。它要求企业承认三个事实：人的有效容量低于理论工时；不同技能不能用人数互相替代；所有项目不可能同时拥有最高优先级。

我最看重的并不是某个项目最终填了 60%还是 70%，而是这个数字能否被追溯到具体工作，能否说明未来哪一周会出现峰值，能否让管理层看见资源不足后的代价，并在延期、缩范围、加人之间做出明确选择。

如果你准备从0开始，下一步不要先购买工具，也不要先要求所有人填写精确百分比。先选取未来六周、五个以内的重点项目，统一有效容量口径，按周拆出关键工作项，识别三个最紧张的技能，并召开一次只处理资源冲突的短会。等这套机制能够稳定运行，再把数据扩展到更多项目和团队。

PMO协同管理的成熟标志，不是资源表越来越复杂，而是组织越来越早看见冲突，越来越快做出取舍，越来越少依赖加班和临时救火。