人力规划管理方法大全：PMO人力资源计划落地方案落地清单

人力规划管理方法大全：PMO人力资源计划落地方案落地清单

很多企业的人力资源计划不是败在“没有人”，而是败在关键节点没有合适的人、人员投入无法被准确核算、项目延期后才发现瓶颈已经形成。PMO人力规划真正要解决的，不是做一张人员名单，而是把业务目标翻译成可计算的工作量、能力需求、时间窗口和决策动作。我在参与中大型企业项目治理时发现，凡是能把人力规划做出结果的团队，通常都建立了“需求，能力，容量，分配，预警，复盘”六个闭环，而不是每月临时问一次各部门有没有人。

一、先讲核心结论：人力规划不是排班，而是项目组合的供需控制

1. 先把人力规划的对象定义清楚

PMO经常把人力规划等同于“项目需要几个人”。这个问题过于粗糙，因为同样是一个人，投入20%和投入80%的管理含义完全不同；同样是两名开发人员，如果一个熟悉业务架构、一个刚入职，实际产出也可能相差一倍。

我通常把人力规划拆成四个对象：项目工作量、人员可用容量、岗位能力结构、时间窗口。只有四个对象同时存在，规划结果才具备执行价值。

• 工作量：项目在某个周期内需要完成多少人天、工时或故事点。
• 可用容量：人员扣除休假、会议、支持工作、培训和日常事务后的真实可投入时间。
• 能力结构：需要什么岗位、等级、领域经验和关键技能。
• 时间窗口：这些能力必须在什么时候到位，晚到几周会产生什么影响。

因此，PMO不应该只向部门负责人提问“能不能支援两个人”，而应该明确询问：“在4月第二周至5月第三周，能否提供一名具备支付业务经验的高级后端工程师，实际投入比例不低于60%，如果只能提供40%，需要将哪个范围顺延？”这才是可决策的人力问题。

2. 用一个公式判断规划是否可信

在人力规划初期，我会先用一个简化公式做容量校验：

有效人力容量 = 标准工作时长 × 可投入比例 × 出勤系数 × 能力系数

例如，一名员工月标准工作时长按160小时计算，可投入项目比例为75%，出勤系数为0.95，能力系数按1.05估算，则其月有效容量约为：

160 × 75% × 0.95 × 1.05 = 119.7小时。

如果项目计划直接按“160小时”分配给这名员工，表面上没有超负荷，实际上已经把会议、请假、支持工作和能力差异全部忽略了。很多项目延期，并不是任务估算一定错误，而是容量基线虚高。

3. 判断一份人力计划是否能落地的五个标准

我在评审PMO人力计划时，不会先看页面是否漂亮，而会看以下五个问题是否有明确答案：

1. 这份计划是否能说明每个岗位在什么时间段投入？
2. 计划中的人员是否已经与部门负责人确认，而不是仅仅写了姓名？
3. 工作量是否按岗位和阶段拆分，而不是只有一个总人数？
4. 是否考虑了共享资源、休假、日常运维和突发支持？
5. 当供给不足时，是否预先定义了范围、时间、预算和外部招聘的取舍顺序？

如果一份计划只能回答“需要多少人”，不能回答“为什么需要、何时需要、少了会怎样”，它仍然只是资源申请单，不是人力规划。

二、背景和真实场景：为什么很多团队越加人，项目反而越慢

1. 多项目并行让“部门有余量”变成假象

在一个约300人的产品与研发组织中，我曾见过这样的情况：项目A的项目经理认为研发部门有3名空闲工程师，因为资源表上显示他们当月只分配了60%；部门负责人却认为这3个人已经满负荷，因为他们还承担了线上故障、客户需求评估和旧系统维护。

双方都没有说错。项目经理看到的是计划分配率，部门负责人看到的是实际工作负荷。问题在于，企业没有统一定义“可用容量”。最终，项目A获得了两名兼职人员，但由于上下文切换频繁，首个迭代的实际交付量只增加了约12%，沟通成本却明显上升。

这类问题在中大型企业尤其明显。项目数量增加后，同一个专家可能同时出现在产品路线图、专项项目、客户支持、合规整改和部门内部改善计划中。如果PMO只做项目台账，不做跨项目容量视图，就无法识别隐性冲突。

2. 关键岗位不是按人数计算，而是按瓶颈计算

一个项目可能有10名成员，但真正决定进度的往往只有两三个关键岗位，例如支付架构师、数据治理负责人、合规评审人员或熟悉历史系统的高级测试工程师。

我在评估项目资源风险时，会单独计算关键岗位的峰值负载，而不是用项目总人数平均分摊。因为普通岗位短缺可能通过调整任务顺序解决，关键岗位短缺则可能直接阻塞多个工作包。

例如，一个数据迁移项目需要15人参与，其中数据架构师只需要投入20%，但所有迁移方案、字段映射和异常处理都必须经过他确认。如果这名架构师同时服务4个项目，实际需求可能达到80%至100%。项目总人数看起来不高，关键岗位却已经成为系统瓶颈。

3. 组织变化会让静态计划迅速失效

人力计划通常在立项时制定，但人员会转岗、请假、离职、承担临时任务，项目范围也会变化。静态表格无法持续反映这些变化，导致PMO每次更新都要依赖人工催收。

我更推荐把人力规划设计成滚动机制：未来两周按周确认，未来一到三个月按月确认，三个月以后按季度预测。越靠近执行期，数据越具体；越远的时间段，允许使用区间和置信度。

这里的误差范围不是行业统一标准，而是我在项目组合规划中使用的管理基准。企业可以根据业务波动、人员稳定性和项目类型进行调整。

三、常见误区：看起来很专业的计划为什么落不了地

1. 误区一：用总人数替代能力结构

“需要8名研发、3名测试、2名产品”是最常见的人力计划表达，但它无法说明人员等级、领域经验、技术栈和阶段变化。

需求分析阶段可能更需要业务分析师和产品经理，开发阶段需要后端、前端和架构人员，联调阶段则更依赖测试、运维和数据人员。如果从头到尾保持同一组人数，通常意味着计划没有按阶段拆解。

正确做法是建立岗位能力矩阵。矩阵至少应包含岗位、能力等级、关键技能、可替代性、最早到岗时间和预计退出时间。

2. 误区二：把工作量估算直接等同于人员容量

工作量是任务需要多少劳动投入，容量是人员实际能够贡献多少有效时间，两者不是同一个概念。

例如，某项目未来4周需要完成480小时后端开发工作。团队有4名后端工程师，每人理论容量为160小时，表面上总容量为640小时。但扣除日常支持、会议、休假和其他项目后，每人只能提供100小时有效投入，团队真实容量只有400小时，缺口达到80小时。

如果PMO不做这一步换算，就会把延期归因于执行效率低；实际上，项目从计划开始就存在容量缺口。

3. 误区三：默认每个人可以稳定投入一个固定比例

在实践中，“某人投入50%”往往不等于每天投入4小时。很多兼职成员会在周一参加原项目会议，周二处理部门事务，周三才开始新项目任务，到了周四又被临时事项打断。

对于高度依赖上下文的工作，碎片化投入会产生明显损耗。我通常把20%以下的投入视为高风险配置，除非工作内容是评审、顾问、专项决策或固定接口；对于需要连续产出的开发、测试和方案设计，建议优先安排连续时间块。

4. 误区四：只做资源申请，不做冲突仲裁

PMO不是资源登记员。多个项目争夺同一名专家时，如果PMO只是把冲突记录下来，组织仍然没有做出选择。

更有效的做法是把冲突转化为可比较的业务影响：项目延期会影响收入、合规、客户承诺、成本还是战略窗口？关键岗位投入到项目A后，项目B会推迟几周？哪个项目的延迟不可逆？

只有当资源冲突被翻译成业务损失，管理层才有条件做取舍。

5. 误区五：工具上线后，数据自然会变准

某项目管理平台可以帮助企业集中管理项目、任务、工时和人员视图，但工具本身不会自动消除估算偏差。如果任务拆分不合理、工时填报没有口径、人员状态不更新，系统只会更快地展示错误数据。

在引入某项目管理工具时，我通常建议先选一个项目群做四周试运行，先统一字段和规则，再扩展到整个组织。最先要解决的不是页面数量，而是“谁在什么时间填什么数据、谁负责审核、异常多久处理”。

四、专业判断逻辑：PMO如何从需求推导出人力方案

1. 第一步：把项目目标翻译成工作包

人力规划不能从岗位名称开始，而要从交付物开始。先列出项目必须完成的成果，再把成果拆成工作包，最后映射到岗位和能力。

1. 明确项目最终交付物，例如上线版本、合规报告、客户迁移、数据治理结果。
2. 将交付物拆成需求、设计、开发、测试、发布、运营等工作包。
3. 为每个工作包估算工作量区间，而不是只给单点数字。
4. 标记前置依赖、不可并行任务和关键审批节点。
5. 将工作包映射到岗位、技能和能力等级。

我更偏好使用“最可能值、乐观值、悲观值”三点估算。比如一项接口改造，乐观需要8小时，最可能需要16小时，悲观可能需要32小时。可以用加权方式形成计划值：

计划工作量 =（乐观值 + 4 × 最可能值 + 悲观值）÷ 6

按上述例子计算，计划工作量约为17.3小时。这个方法不能消除不确定性，但能避免团队被迫提交一个看似精确、实际没有依据的数字。

2. 第二步：建立有效容量，而不是名义容量

容量计算至少要考虑四类扣减：固定事务、休假与缺勤、非项目支持、并行项目占用。对于研发和产品团队，还要单独记录技术债、线上响应和临时评审。

我通常会给团队设置一个计划利用率上限，而不是把100%都排满。对于变动较大的产品团队，项目计划利用率可控制在70%至80%；对于流程稳定、工作内容高度标准化的交付团队，可以适度提高。

这个比例不是越低越好。过低会造成资源闲置，过高则会让任何突发问题都变成延期。判断标准应该是：当正常波动出现时，团队是否仍有缓冲处理，而不需要立即加班。

3. 第三步：识别岗位瓶颈和不可替代资源

我会给每个岗位增加三个判断字段：需求峰值、可替代人数、延迟影响。这样可以将“缺人”分为不同类型。

• 数量型缺口：同类人员整体不足，可以通过招聘、外包或调整范围解决。
• 能力型缺口：人数足够，但缺少特定技能，需要培训、借调或专家支持。
• 时间型缺口：人员存在，但无法在项目关键窗口投入。
• 单点型缺口：只有一名人员掌握关键知识，存在集中风险。

这四类缺口的解决方案不同。数量型缺口可以增加人员，能力型缺口未必能靠增加新人解决，时间型缺口需要调整优先级，单点型缺口则必须安排知识转移和备份人员。

4. 第四步：用情景模拟替代单一计划

成熟的人力计划至少要准备三个情景：基准情景、保守情景和压力情景。

情景模拟的价值不是预测未来，而是让团队提前讨论“如果发生了怎么办”。很多资源冲突之所以恶化，是因为组织直到关键节点才第一次讨论替代方案。

五、具体案例：以中大型组织的人力规划为例拆出落地方法

1. 项目背景与原始问题

下面使用一个面向100人以上组织的研发管理场景说明。某企业拥有约420名员工，其中产品、研发、测试、设计和交付人员约260人。企业同时推进客户定制、平台升级、数据治理和内部合规四类项目。

企业原先使用多个表格管理资源。每周由项目经理提交人员需求，部门负责人再根据经验回复。三个月后出现三个明显问题：一是同一名高级工程师被同时安排到5个项目；二是部分人员计划投入率超过120%；三是项目延期原因无法区分为估算不足、人员冲突还是需求变更。

企业随后在某项目管理工具中建立项目、任务、人员、工时和风险的关联视图，但没有一开始就要求所有成员填报非常细的工时，而是先统一了资源规划字段和周度更新节奏。

2. 先做岗位池，再做个人分配

第一轮规划没有直接给所有任务分配具体姓名，而是先建立岗位池。例如后端工程师分为初级、中级、高级和架构能力四个层级，测试人员区分功能测试、自动化测试和性能测试，产品人员区分行业产品和平台产品。

这样做有两个好处。第一，项目组合评审时可以先判断组织是否缺某类能力，而不是过早陷入具体人员争议。第二，人员转岗或休假时，可以快速判断哪些岗位具备替代可能。

3. 再按阶段安排人员，而不是平均铺开

在平台升级项目中，项目团队最初希望从立项到上线始终保持“8名开发、3名测试、2名产品”的配置。PMO重新拆解后发现，需求与架构阶段开发人员只需要4名，但必须提前投入1名架构能力人员；联调和回归阶段测试需求会快速上升，开发人数则可以减少。

调整后的配置如下：

从表面看，项目总人数没有明显增加，但关键阶段的岗位结构发生了变化。项目最终减少了重复等待和后置测试，里程碑延误天数从模拟基线的18天降低到7天。这里的数据属于项目复盘中的情景化示例，用于说明拆分方法，不代表所有企业都能获得相同结果。

4. 用某项目管理工具建立三层视图

在工具落地时，我建议至少建立三层视图，而不是把所有数据堆在一个资源表里。

• 项目组合视图：看各项目优先级、关键里程碑、预算、风险等级和资源总需求。
• 能力供需视图：看某岗位或技能在未来数周的需求峰值、可用容量和缺口。
• 个人负载视图：看单人参与项目数量、投入比例、时间冲突和关键任务分布。

项目组合视图用于管理层决策，能力供需视图用于PMO和部门负责人协调，个人负载视图用于项目经理与成员确认执行。三类视图的使用对象不同，不能只做其中一类。

六、PMO人力资源计划落地清单：从建表到运行的完整步骤

1. 建立统一的人力规划数据模型

在开始填数据之前，先统一字段，否则后续任何图表都可能失真。建议至少建立以下字段：

• 项目名称、项目优先级、项目负责人。
• 工作包、任务名称、交付物、所属阶段。
• 岗位类型、能力等级、关键技能。
• 计划开始日期、计划结束日期、预计工作量。
• 人员姓名、所属部门、投入比例、可用日期。
• 工作量来源、估算方法、估算置信度。
• 前置依赖、关键路径、替代人员。
• 风险状态、冲突状态、决策人、处理期限。

字段不宜无限增加。我的经验是，第一阶段先保证数据可填、可审、可更新，等运行两轮后再增加复杂字段。过度设计会导致成员只填表不做项目。

2. 明确角色与责任边界

3. 建立周度滚动机制

建议每周固定一个时间点更新未来6至8周的人力计划。更新不是让所有人重填整张表，而是只要求变更者更新变化项。

1. 项目负责人更新范围、里程碑和工作量变化。
2. 部门负责人确认人员可用日期、休假和临时任务。
3. PMO自动或人工识别超负荷、关键岗位缺口和多项目冲突。
4. 相关负责人在规定时限内提交替代方案。
5. 管理层只处理无法在项目层解决的优先级冲突。
6. PMO记录最终决定，并在下一次滚动会议检查执行结果。

关键是设置“冻结窗口”。例如未来两周的人员分配原则上不随意变更，确需变更时必须说明影响；三周以后允许根据项目变化调整。没有冻结窗口，项目团队永远处于等待资源确认的状态。

4. 设置可执行的预警阈值

预警不宜只设一个“超过100%就报警”的规则。不同岗位和工作类型的合理上限不同，建议结合项目特点设置分级阈值。

阈值本身不是管理结果。真正重要的是触发预警后，谁必须在多长时间内采取什么动作。建议黄色预警在两个工作日内处理，橙色预警在一个工作日内形成方案，红色预警直接进入项目组合会议。

七、不同情况下的行动建议：不要用同一套方案处理所有缺口

1. 需求增长但时间不变时

这是最常见也最危险的情况。项目范围增加后，企业通常只要求团队“想办法赶上”，但没有明确新增人员、减少范围还是延长时间。

我的建议是先计算新增工作量落在哪些岗位和关键路径上，然后按以下顺序处理：

1. 确认新增需求是否真的属于本次交付范围。
2. 判断能否通过复用、简化或分阶段交付降低工作量。
3. 检查组织内部是否有可在关键窗口投入的合适能力。
4. 若内部资源不足，再评估外部支持的启动周期和知识成本。
5. 如果资源和范围都无法调整，必须正式调整里程碑。

不能同时承诺范围不变、时间不变、资源不变。这不是执行问题，而是约束条件不成立。

2. 关键专家被多个项目争抢时

不要用“谁先申请谁优先”解决冲突。应该比较项目价值、不可逆损失、依赖关系和替代成本。

如果专家只承担评审和决策，可以采用固定时段服务多个项目；如果专家需要连续投入完成架构改造，则应尽量集中到一个项目，避免每天在多个项目之间切换。

对于长期单点依赖，建议安排一名中级人员跟随参与，把专家投入的一部分转化为知识传递，而不是让专家永远成为唯一解决方案。

3. 人员无法按计划到岗时

如果人员延迟一周到岗，不能只把他的任务整体顺延。PMO需要先确认他是否位于关键路径、他的工作是否有前置依赖、是否能拆出准备工作，以及是否存在临时替代角色。

• 关键路径且不可替代：优先调整里程碑或申请外部专家。
• 关键路径但可拆分：先由现有人员完成接口、数据和环境准备。
• 非关键路径：重新排序任务，避免空等。
• 岗位能力不足但人员已到岗：安排结对工作，不要直接按满产出排期。

4. 项目进入维护期但人员仍未释放时

很多企业的资源表长期显示项目仍占用人员，实际项目早已进入低频维护。PMO应把“建设期”和“维护期”分开，明确维护工作量、响应等级和责任边界。

如果维护期每周只需要10小时支持，就不要继续按50%甚至100%占用人员。否则其他项目会因为资源账面被锁定而无法启动。

5. 组织准备引入某项目管理工具时

适合引入工具的场景通常有三个：项目数量超过十个且相互依赖明显；人员跨多个项目投入，表格难以维护；管理层需要持续查看项目组合和关键岗位风险。

不适合直接大规模上线的情况也有三个：企业尚未明确项目优先级；部门负责人不愿确认人员可用性；所有任务都没有统一定义和估算口径。此时先做治理规则，再做工具配置，效果通常更好。

对100人以上组织，我建议采用“一个项目群、一个月试运行、三类视图、五项指标”的轻量试点方式，先验证能否减少资源冲突和人工统计，再扩展到更多部门。

八、不同情况下的取舍：资源不足时到底该牺牲什么

1. 时间、范围、资源和质量不能同时固定

当资源不足时，项目负责人经常说“质量不能降、范围不能减、时间不能延”，这句话在管理上没有可执行性。至少有一个约束必须变化，或者组织需要投入更多预算购买外部能力。

我建议PMO使用四象限方式组织讨论：

最不建议的方式是牺牲不可见的东西，例如让团队长期加班、减少测试、推迟文档和知识转移。它们不会立即出现在项目状态里，却会在上线后以故障、返工和人员流失的形式出现。

2. 何时选择内部培养，何时选择外部引入

内部培养适合长期重复出现的能力缺口，尤其是企业核心业务知识、流程知识和客户理解。外部引入适合短期、高稀缺、边界清晰的专业任务。

判断时可以比较四项成本：获取速度、知识沉淀、交付风险和长期利用率。如果外部人员能快速解决一次性架构问题，但项目后续没有持续需求，外部支持可能更合理；如果某能力未来每季度都会出现，持续外部采购可能导致成本和依赖上升。

3. 何时采用兼职，何时必须集中投入

兼职适合评审、顾问、合规检查、业务答疑和阶段性决策。集中投入适合需求梳理、复杂开发、系统迁移、性能治理和上线保障。

如果一个任务需要频繁阅读上下文、反复验证和连续思考，低比例兼职往往会把实际周期拉长。表面上投入比例只有30%，但因为切换成本，日历周期可能达到全职投入的70%。

4. 何时应该暂停项目，而不是继续补人

如果项目目标不清、收益无法验证、依赖条件长期未满足，继续投入人员只会扩大沉没成本。PMO应当设置暂停条件，例如连续两个周期没有完成关键决策、核心业务方无法确认范围、外部依赖没有明确时间表。

暂停并不等于失败。把人员释放到更高优先级项目，可能是项目组合层面的正确决策。真正危险的是项目既没有明确成果，也长期占用关键资源。

九、指标与复盘：如何判断人力规划真的改善了组织效率

1. 不要只看人员利用率

人员利用率高不一定代表效率高。一个团队长期达到110%的计划利用率，可能只是因为所有人都在透支；如果项目延期、返工和离职增加，这种高利用率实际上是风险信号。

我建议至少跟踪以下指标：

• 计划容量偏差：计划有效容量与实际可用容量的差异。
• 关键岗位峰值负载：关键岗位在周期内最高负载，而非团队平均值。
• 资源冲突关闭时长：从识别冲突到形成并执行解决方案的时间。
• 人员到岗兑现率：承诺到岗人员中按期实际投入的比例。
• 计划工作量偏差：估算工作量与实际投入的差异。
• 多项目切换次数：单人在周期内参与项目或工作流切换的频次。
• 延期归因结构：延期由资源、范围、依赖、质量还是估算导致。

2. 用结果指标验证规划，而不是用填表率自我安慰

填表率只能说明成员完成了动作，不能说明计划有效。真正有价值的是看资源冲突是否减少、关键岗位是否更早被识别、项目延期是否更容易解释、管理层是否能更快做出取舍。

例如，某组织上线规划流程后，人员填报完整率从65%提升到94%，但冲突关闭时长没有变化，说明数据收集改善了，决策机制没有改善。相反，如果填报率只有85%，但关键岗位冲突提前两周暴露，项目延期归因更加清晰，管理价值可能更高。

3. 每月做一次人力规划复盘

月度复盘不需要写长报告，但必须回答四个问题：

1. 哪些岗位的实际投入明显高于计划，原因是什么？
2. 哪些岗位被计划占用但实际没有使用，是否可以释放？
3. 哪些项目的工作量偏差最大，估算方法是否需要调整？
4. 哪些资源冲突重复出现，是否暴露出组织能力结构问题？

如果同一种冲突连续三个月出现，就不能再把它当作项目问题。例如高级数据工程师持续被多个项目争抢，说明组织需要建立能力梯队；如果每个项目都在上线前临时申请测试资源，说明测试没有进入前置规划。

十、可直接使用的PMO人力规划落地清单

1. 规划启动前清单

• 是否已确认项目优先级和业务目标？
• 是否已定义交付物、里程碑和关键路径？
• 是否已将项目拆分为工作包和岗位需求？
• 是否已统一工作量、工时和投入比例的口径？
• 是否已建立岗位能力池和人员可用性数据？
• 是否已定义未来两周、两个月和一个季度的规划粒度？

2. 资源配置清单

• 每个工作包是否都有负责人和备份人员？
• 每个关键岗位是否明确能力等级和到岗日期？
• 人员投入比例是否扣除了休假、会议和日常支持？
• 是否识别了同一人员的多项目冲突？
• 是否识别了单点依赖和不可替代资源？
• 是否明确了资源不足时的替代方案？

3. 执行监控清单

• 是否每周更新未来6至8周的计划？
• 是否设置了计划冻结窗口？
• 是否对超负荷、关键岗位缺口和人员未到岗设置预警？
• 预警是否关联责任人、处理期限和升级路径？
• 项目变更是否同步影响人力计划？
• 实际投入与计划偏差是否被记录并解释？

4. 复盘改进清单

• 是否区分了资源不足与估算错误？
• 是否分析了延期、返工和加班的资源原因？
• 是否识别出重复出现的能力缺口？
• 是否根据实际数据调整岗位池和容量系数？
• 是否释放了维护期项目占用的闲置资源？
• 是否将关键经验沉淀为标准工作量或能力等级？

十一、最终判断：好的资源计划，不是把人排满，而是让组织知道该如何取舍

1. 人力规划的本质是提前暴露矛盾

很多人希望规划表能给出一个确定答案：需要多少人、什么时候到岗、项目什么时候完成。但真实管理中，规划最重要的作用不是制造确定性，而是尽早暴露不确定性和约束。

当PMO能明确告诉管理层“如果不增加高级后端能力，核心里程碑将延后两周；如果不延后时间，就必须减少两个非核心功能；如果不减少范围，就需要采购外部支持”，组织才真正拥有决策能力。

2. 人力规划的最小可行闭环

如果企业目前还没有成熟的人力规划体系，不必一开始就追求复杂模型。最小可行闭环可以只有六步：

1. 统一项目、岗位、人员、工作量和时间窗口五类数据。
2. 计算真实有效容量，停止直接使用名义工时。
3. 按阶段识别岗位峰值和关键路径。
4. 建立未来6至8周滚动计划。
5. 对冲突设置责任人、期限和升级路径。
6. 每月用实际投入和项目结果校准估算规则。

当这六步运行稳定后，再引入能力画像、成本预算、情景模拟、外部资源池和组织能力预测。顺序不能反过来，否则很容易先买系统、做大屏、建复杂字段，却没有形成真实决策。

3. 下一步怎么做

建议PMO在本周选取一个包含多个项目、共享关键岗位明显的项目群，完成一次小范围盘点。先不要追求全组织覆盖，只需要回答三件事：未来六周哪些岗位会成为瓶颈、哪些人员已经被重复承诺、哪些项目必须在资源不足时优先保护。

然后用统一模板或某项目管理平台建立项目组合、能力供需和个人负载三张视图，连续运行四周。四周后重点复盘冲突提前识别率、资源冲突关闭时长、计划容量偏差和关键里程碑延期率。

我对PMO人力规划的最终判断是：真正成熟的方案，不是让每个人都满负荷，也不是让资源表看起来没有空白，而是让每一次资源不足都能被量化、被讨论、被决策，并留下可复用的组织经验。