人力资源计划如何做好工作量？PMO落地方案与操作步骤

人力资源计划最容易失败的地方，不是“少算了几个人”，而是把工作量直接除以人数，得到一个看似精确、实际无法执行的结果。我在为中大型企业设计 PMO 资源计划时，见过同一个项目在预算表里只需要 18 人、到了执行阶段却持续缺口 6 人；问题并不完全在招聘速度，而在于需求被按“岗位人数”统计，没有按交付物、技能、时间窗口和并行约束拆开。真正可落地的人力资源计划，应该回答四个问题：要交付什么、什么时候交付、需要什么能力、这些能力在什么时间段被占用。

一、先讲核心结论：工作量不是人数，资源计划也不是人员名单

1. 先把工作量定义成可验证的交付任务

工作量不是“研发团队很忙”“市场活动很多”“这个项目需要 10 个人”这类描述。它必须落到可以验收的任务上，例如完成 36 个接口、上线 4 个业务流程、迁移 8 万条历史数据、完成 12 个区域的培训，或者输出 20 份合规材料。

我通常把工作量拆成四层：项目目标、交付物、活动、工时。项目目标解释为什么做，交付物解释做成什么样，活动解释怎么做，工时解释需要消耗多少人力。只有拆到“活动”这一层，PMO 才能发现重复计算、漏算和技能错配。

2. 用“需求工时，有效产能，时间窗口”计算人数

最基础的计算公式是：所需人数 = 需求总工时 ÷ 单人有效工时。这里的关键不是公式，而是“单人有效工时”不能直接用出勤小时替代。一个月工作 168 小时，不代表可以用于项目交付 168 小时。

所需人数 = Σ任务工时 ÷（计划周期 × 单人每月有效工时）
单人每月有效工时 = 月度可工作时长 × 项目投入比例 × 交付效率系数

峰值人数 = 任一时间窗口内并行需求工时 ÷ 该窗口内单人有效工时

在我参与的一项企业级系统改造中，团队最初按每人每月 160 小时计算，计划需要 22 人。复核会议、跨部门沟通、故障处理、行政事务和临时需求被纳入后，项目有效工时只有每人每月 105 至 120 小时，峰值阶段实际需要 29 人。计划人数和峰值人数不是同一个数字，平均人数也不能替代峰值人数。

如果企业长期使用项目管理平台记录任务、工时、延期原因和人员投入，就可以建立自己的有效产能基线。对于 100 人以上、同时运行多个项目的组织，使用 PingCode 这类项目管理平台统一维护任务、资源、工时与进度数据，会比依赖分散表格更容易形成可追溯的资源判断。

3. 把资源计划分成三个数字，而不是只报一个人数

我建议 PMO 在每次资源评审中至少同时报告“平均需求人数、峰值需求人数、缺口人数”。平均需求用于预算，峰值需求用于排产，缺口人数用于决策。三者混在一起，管理层往往会误以为项目从头到尾都需要高峰配置。

例如，一个项目平均需要 16 人，峰值需要 24 人，当前团队可提供 18 人。此时不能简单地说“缺 6 人”，因为缺口可能只持续三周。如果通过拆分联调批次、将低风险测试外包或错开两个项目的上线窗口解决，就不一定需要长期招聘 6 人。

二、背景和真实场景：为什么很多人力计划在审批时合理，执行时失真

1. 组织里存在四种不同的“工作量”

在资源会议中，我经常发现业务负责人、职能经理、项目经理和财务人员说的“工作量”不是同一个概念。业务负责人说的是需求规模，项目经理说的是任务工时，职能经理说的是人员占用，财务人员说的是预算金额。四种口径如果不先统一，会议越开越久，结论却越来越模糊。

• 需求工作量：需求数量、客户数量、区域数量、产品模块数量。
• 执行工作量：完成这些需求需要的任务数和工时。
• 资源占用量：某个岗位在某个时间段被占用的比例。
• 成本工作量：按人天、外包单价或内部成本折算出的金额。

例如，业务部门说“本季度有 30 个需求”，并不代表研发需要完成 30 个等量任务。可能其中 20 个是两小时配置项，5 个涉及跨系统联调，另外 5 个需要安全评审和数据迁移。数量相同，工作量可能相差十倍。

2. 资源冲突往往不是缺人，而是关键技能被少数人垄断

我见过一个 300 多人的技术组织，整体人力看起来并不紧张，但三个项目同时卡在同一位数据架构师身上。团队总人数充足，却无法并行推进。这个问题如果只看部门人数和项目总工时，很难被发现；只有把任务和技能标签关联起来，才能看到“技能瓶颈”。

资源计划至少要记录岗位、技能、熟练等级、可投入时间、所在地点、可用日期和替代人选。岗位名称只能说明一个人属于什么组织，技能标签才说明这个人能不能完成当前任务。

3. 中大型组织的真实难点是多项目争抢，不是单项目排班

单项目资源计划相对容易，因为项目经理可以控制任务、顺序和人员。但在 100 人以上的组织里，一个人往往同时出现在多个项目、部门专项、客户支持和临时任务中。项目经理看到的是“我的人”，PMO 看到的却是“同一个人被四个项目重复承诺”。

因此，PMO 的工作不是替每个项目经理做一张更漂亮的 Excel 表，而是建立跨项目的资源账本。这个账本必须能回答：谁在什么时候被什么任务占用，任务是否需要同一技能，项目优先级如何排序，发生冲突时由谁裁决。

三、常见误区：看起来精细的计划，为什么仍然不能执行

1. 误区一：用人数乘月份代替工作量估算

“这个项目安排 10 个人做 6 个月”并不等于“有 60 人月产能”。如果其中 4 人只参与前两个月，2 人每周只能投入 30%，还有 1 位关键专家在第三个月离岗，60 人月只是名义数字。

我建议把资源计划从“人员清单”改成“时间段资源矩阵”。横轴是周或月，纵轴是角色或技能，每个格子填写投入比例。这样可以直接看出某一阶段是缺人、缺技能，还是有人但不能在需要的日期到岗。

2. 误区二：把 100% 利用率当成高效率

很多部门把人员利用率设为 95% 甚至 100%，认为这样最节约。但项目型组织需要处理需求变更、评审返工、故障、审批等待和跨部门依赖。没有缓冲的计划，不会提高效率，只会把不确定性转化为延期。

在实际规划中，我通常把知识型岗位的计划利用率设在 70% 至 85% 区间，再根据工作类型调整。重复性高、输入稳定的岗位可以接近 85%；探索性研发、复杂架构和跨部门协调岗位则应保留更多缓冲。这个区间不是行业定律，而是用于启动估算的建议基准，最终要用企业历史数据校准。

3. 误区三：只看总工时，不看关键路径

两个项目都需要 2,000 小时，并不代表资源风险相同。项目甲可以在 12 周内并行完成，项目乙有一项必须由同一位专家连续投入 8 周的关键任务。后者的总工时未必更高，但对资源可用日期更加敏感。

PMO 应把关键路径上的任务单独标注，并为每项任务记录最晚开始时间、最晚完成时间、必需技能和替代方案。凡是没有替代人选、没有时间浮动、又位于关键路径上的任务，都应列入红色资源风险。

4. 误区四：把加班当作解决缺口的默认方案

加班可以解决短期峰值，却不能解决长期技能缺口。连续两个月把每周 40 小时的需求压到每周 55 小时，表面上增加了 37.5% 的工时，实际可能因返工、疲劳和离职风险而损失更多。

我在复盘一个延期项目时发现，团队连续六周加班后，缺陷返修工时占开发总工时的比例从 12% 上升到 24%。这说明加班带来的新增时间没有全部转化为有效产出。加班应该是短期缓冲措施，不应成为资源计划的主要供给渠道。

5. 误区五：只做年初计划，不做滚动校准

年度计划适合确定方向和预算，但不适合直接指导每周排产。项目优先级、人员可用性、供应商进度和客户需求都会变化。没有滚动机制的计划，通常在第一个季度后就只剩下形式价值。

我建议采用“年度容量、季度承诺、月度重排、周度预警”的四层节奏。年度层面看部门能力，季度层面看项目组合，月度层面看资源缺口，周度层面只处理已发生或高概率发生的偏差。

四、专业判断逻辑：PMO 如何判断到底是缺人、缺技能还是缺时间

1. 第一步：统一需求口径和估算粒度

在正式估算前，PMO 要先规定任务拆分标准。一个任务如果持续时间超过两周、涉及两个以上角色，或者无法在一次评审中判断完成状态，就应该继续拆分。任务太大，估算会变成拍脑袋；任务太细，维护成本又会吞噬管理价值。

我常用“半天到五天”的任务粒度作为初始标准。短于半天的工作可以合并为活动包，长于五天的工作通常需要拆成多个可验收节点。对于探索型任务，可以使用区间估算，而不是强行给出一个精确小时数。

三点估算可以使用以下公式：期望工时 =（乐观工时 + 4 × 最可能工时 + 悲观工时）÷ 6。它不是为了制造数学上的精确，而是迫使团队讨论不确定性来源。

期望工时 = (O + 4M + P) / 6
O = 乐观工时

M = 最可能工时

P = 悲观工时

2. 第二步：建立资源能力矩阵，而不是只建立部门通讯录

能力矩阵至少要包含四个维度：能否承担、独立程度、可投入时间、替代难度。一个人“会做”不代表能在本项目中独立交付，也不代表此时有空，更不代表别人可以快速替代。

能力矩阵不需要一开始就覆盖所有人和所有技能。建议先从高频项目、关键岗位和反复出现的瓶颈技能开始。PMO 如果试图一次性建立几千项技能标签，通常会因为维护困难而失效。

3. 第三步：把资源需求放到时间轴上

资源需求的核心不是“需要多少人”，而是“在第几周需要哪种能力”。例如，项目启动阶段可能需要业务分析师和架构师，开发阶段需要后端和前端，验收阶段则需要测试、培训和客服支持。把所有角色从第一个月排到最后一个月，会导致资源浪费和关键技能冲突。

我通常使用周作为中大型项目的基本时间单位。对于周期超过六个月的项目，前两个月按周规划，后续阶段按月规划；对于上线、迁移和大型活动，则把关键周进一步拆成日级计划。

4. 第四步：用优先级规则处理冲突，而不是让项目经理私下争抢

资源冲突不可避免，真正危险的是没有公开的裁决规则。没有规则时，声音最大的项目、关系最强的部门或最先提出需求的人，往往会拿到资源，而不是最重要的项目。

我建议采用四项评分：战略重要性、客户或收入影响、合规与风险、时间窗口刚性。评分结果只用于形成讨论依据，不能替代管理层判断，但可以把“谁更重要”的争论变成可解释的决策。

5. 第五步：为每个关键缺口准备至少两种替代方案

一个合格的 PMO 资源计划，不仅要写“缺 2 名数据工程师”，还要写清楚缺口可以如何处理。替代方案通常包括调入内部资源、延后非关键范围、购买外部服务、培养现有人才、调整技术方案和重新安排项目顺序。

我会要求每个红色缺口同时记录成本、到位时间、质量风险和不可逆后果。如果外包需要六周才能到位，而项目三周后就要联调，那么它在表面上是替代方案，实际上不是解决方案。

五、PMO 落地方案：从零建立一套可运行的人力计划机制

1. 第一步：建立统一的资源计划字段

资源计划模板不宜追求字段越多越专业。字段太多会造成填报疲劳，最后只剩复制粘贴。我的建议是先保留能够支持决策的最小字段，再根据复盘结果扩展。

• 项目名称、项目优先级、交付阶段。
• 任务名称、交付物、任务负责人。
• 所需角色、技能标签、能力等级。
• 计划开始日期、计划结束日期、需求工时。
• 人员可用时间、计划投入比例、当前已承诺比例。
• 任务前置条件、关键路径标识、替代资源。
• 估算依据、风险等级、最近更新时间。

在工具层面，表格适合初始试点和小规模项目，但当组织需要处理多项目并行、跨部门资源、工时回填和历史分析时，某项目管理平台更适合承担统一数据底座。尤其要注意，不要只购买一个“资源视图”，却没有任务、进度、工时和变更记录，否则资源数据仍然会脱离实际执行。

2. 第二步：建立基线，不要一开始就追求绝对准确

第一次估算一定会有误差。PMO 的目标不是第一次就算准，而是建立“估算，执行，偏差，校准”的闭环。建议选择 3 至 5 个类型不同、周期适中的项目作为样本，记录计划工时、实际工时、等待时间、返工时间和延期原因。

经过两到三个周期后，可以形成组织自己的估算系数。例如，过去十个同类接口任务的计划工时平均为 16 小时，实际完成平均为 21 小时，则初始校准系数可以设为 1.31。但不能机械地把所有接口都乘以 1.31，还要区分复杂度、人员熟练度和依赖条件。

3. 第三步：建立周度资源会，而不是月度汇报会

资源计划的周会不应该逐项念表，而应该只讨论变化。建议固定回答五个问题：本周哪些任务延期，未来四周哪里会出现缺口，哪些技能被多个项目同时占用，哪些任务可以错峰，哪些决策需要管理层介入。

为了避免会议变成状态汇报，我会提前设置触发条件。只要出现以下任一情况，就进入资源评审：关键任务延期超过两天；关键角色未来两周利用率超过 90%；任务估算偏差超过 20%；同一技能被三个以上项目争抢；项目范围变更导致需求工时增加超过 10%。

4. 第四步：设置红黄绿资源预警

预警规则必须简单到可以自动执行。绿色表示资源可用且关键路径没有风险；黄色表示未来一到四周存在冲突，需要项目经理处理；红色表示已经影响关键路径，必须由 PMO 或管理层裁决。

5. 第五步：把资源变更纳入项目变更控制

资源变化本质上也是项目变化。一个关键专家被调走、一个外包团队延迟到位、一个核心岗位从全职变成半职，都可能影响范围、工期、成本和质量。若资源变更不进入变更控制，项目计划会出现“日期没变、资源变了、结果却没人负责”的隐性失控。

资源变更单至少应说明四件事：变更原因、影响任务、替代方案、需要谁批准。对于关键路径资源变更，还应重新计算完成日期，而不是只在资源表里把人名替换掉。

六、具体案例：一个 100 人以上组织如何从“缺人”转向“重排资源”

1. 项目背景和初始判断

下面这个案例来自我参与过的一类企业级业务系统项目，数据经过脱敏和情景化处理，但计算过程保持真实工作方式。某企业有约 260 名员工，计划在 20 周内完成客户服务平台升级，涉及业务、产品、研发、测试、数据、安全和培训多个团队。

项目初始计划安排 24 人，预算约 430 人月。项目负责人在第 5 周提出“至少还缺 8 人”，理由是开发任务大量积压，测试窗口被压缩，数据迁移尚未开始。

PMO 没有立即批准加人，而是把任务拆成 186 个可追踪活动，重新检查每项任务的工时、技能和时间窗口。结果发现，问题由三部分组成：一部分是真缺人，一部分是关键技能冲突，另一部分是前置依赖没有完成。

2. 重新拆解后的资源结构

经过重新安排，团队没有新增 8 名长期成员，而是新增 2 名短期测试支持，释放 0.4 个数据架构师产能，延后 15 项非关键需求，并把数据迁移拆为三个批次。项目最终延期 1 周，但没有发生原计划中预计的 5 周整体延期。

3. 数据变化说明了什么

该项目的总需求工时从最初估算的 34,400 小时调整为 31,800 小时。数字下降并不是“少做了工作”，而是删除了重复评审、合并了重复配置任务，并将非关键范围移出当前版本。

更重要的是，峰值资源从 32 人降为 27 人，平均资源仍保持在 22 人左右。换句话说，项目真正需要的不是长期增加 8 人，而是处理三个星期的峰值和一个关键技能冲突。

4. 这个案例最值得复制的做法

第一，不把项目负责人提出的“缺 8 人”直接当成事实，而是把它转化为可验证的任务和技能缺口。第二，把非关键范围和关键路径分开，避免所有需求都争夺同一批资源。第三，把临时支持、内部借调和范围调整放在同一个决策表中比较，而不是默认招聘是唯一答案。

这个案例也说明，资源计划不是为了证明原计划正确，而是为了尽早暴露原计划不成立的地方。PMO 如果只负责收集报表，不负责推动取舍，就很难产生真正的管理价值。

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

1. 如果缺口是短期峰值，优先错峰和临时支援

短期峰值通常持续几天到四周，常见于联调、上线、迁移、审计和大型活动。此时长期招聘往往来不及，也不经济。可优先考虑调整任务顺序、拆分批次、内部借调、短期外部支持和减少非关键会议。

• 峰值不超过两周：先做任务错峰和团队内部调配。
• 峰值持续两至六周：评估短期外包、顾问或跨团队借调。
• 峰值超过六周：重新检查项目范围和长期能力配置。

2. 如果缺口是关键技能，优先建立替代和培养机制

如果所有任务都等待同一位专家，继续招聘普通岗位并不能解决问题。此时需要把专家从低价值执行任务中释放出来，将部分工作交给 L2 人员，同时安排结对工作、设计评审和知识沉淀。

我通常会把关键技能分成“必须由专家完成”“可以由中级人员完成”“可以标准化或外包”三类。专家的价值应集中在决策、复杂问题和能力传递上，而不是被大量常规任务消耗。

3. 如果缺口是长期容量不足，才考虑招聘或组织扩容

长期招聘必须有持续需求作为依据。至少需要观察两个以上计划周期，并确认缺口不是由流程低效、返工、项目优先级混乱或临时需求造成。否则，企业可能招来更多人，却只是扩大了等待、沟通和协调成本。

长期扩容应同时回答：未来 6 至 12 个月需求是否稳定、关键技能是否能通过培养获得、岗位是否存在明确的持续工作、招聘到岗周期是否匹配业务节奏、管理跨度是否会增加新的瓶颈。

4. 如果预算受限，优先保护关键路径而非平均分配资源

预算不足时，平均削减每个项目 10% 的人力，往往比集中暂停低优先级项目更糟。前者会让所有项目都变慢，后者则可以保护少数关键项目的交付确定性。

我的建议是先保留关键路径上的必要能力，再对非关键范围、低价值需求和可延期项目做取舍。资源有限时，最重要的不是让每个项目都“有一点资源”，而是让组织真正重要的项目具备完成条件。

5. 如果数据基础薄弱，先做人工可维护的最小版本

企业不需要等到所有系统打通后才开始资源管理。第一阶段可以使用统一模板和固定周会，先规定口径；第二阶段再接入任务、工时和项目进度；第三阶段才做自动预警、容量预测和情景模拟。

工具建设必须跟着管理规则走。没有统一任务粒度和优先级规则时，直接上线复杂资源系统，只会把混乱搬进系统，产生更多看似精确、实际不可信的报表。

八、不同情况下的取舍：每一种资源决策都有代价

1. 招聘、外包、借调和延期的对比

2. 快速交付和稳定质量之间的取舍

当管理层要求“既不能增加人，又不能延期，还不能减少范围”时，PMO 必须明确说明这不是资源方案，而是未解决的约束冲突。项目可以通过加班暂时压缩时间，但通常会增加缺陷、返工和人员流失风险。

建议把决策拆成三个层次：哪些目标不可牺牲，哪些范围可以调整，哪些风险可以接受。只有把取舍写下来，后续才不会出现“当时大家都同意，后来没人承认”的责任争议。

3. 精确计划和维护成本之间的取舍

计划越细，理论上越准确，但维护成本也越高。对于变化快的探索型项目，过细计划会制造大量无效更新；对于交付窗口刚性的迁移、上线和合规项目，过粗计划又会掩盖真正风险。

九、如何用项目管理平台支撑人力资源计划

1. 工具应该记录事实，而不是替管理者做判断

项目管理平台可以帮助企业记录任务、负责人、计划日期、工时、依赖关系、资源占用和变更历史，但它不能自动判断一个项目是否值得优先，也不能替管理层承担资源取舍责任。

选择系统时，我会重点看五个能力：是否支持跨项目资源视图，是否能关联任务与技能，是否可以区分计划工时和实际工时，是否能追踪资源变更，是否能按角色、部门和项目输出容量分析。只提供日历排班而没有任务实际数据的系统，往往只能做展示，不能支撑决策。

2. PingCode 类平台适合什么组织

对于 100 人以上、项目并行度较高、部门协作复杂的组织，PingCode 类平台的价值不只是替代表格，而是把项目任务、需求、迭代、工时、资源和交付结果放在同一条数据链上。PMO 可以用项目视图看组合优先级，用资源视图看时间冲突，用工时数据校准估算，用变更记录追踪计划为什么变化。

但工具是否适合，不能只看功能清单。企业还要评估员工是否愿意及时更新任务、职能经理是否认可资源口径、项目优先级是否有管理层授权、历史数据是否足以支撑容量预测。没有这些前提，平台上线后可能出现“任务填得很满，实际进展没人相信”的情况。

3. 资源管理系统上线的三个阶段

1. 阶段一：统一口径。确定任务粒度、工时单位、资源状态、优先级和预警阈值，先解决“大家说的不是同一件事”。
2. 阶段二：连接执行。将项目任务、负责人、计划日期、实际工时和变更记录关联起来，让资源计划能够反映执行事实。
3. 阶段三：形成预测。基于历史偏差、人员容量、技能供给和项目组合，建立未来四至八周的资源预测。

建议不要一开始就追求自动排班和智能预测。先让项目经理愿意使用，让职能经理相信数据，让管理层愿意依据数据做取舍，系统才有持续价值。

十、衡量人力计划是否有效：不要只看“有没有按时交付”

1. 结果指标：项目是否更可预测

结果指标可以包括计划完成率、关键里程碑准时率、资源缺口关闭率、峰值超配次数和范围变更后的重新计划时长。结果指标适合向管理层汇报，但不能单独用于诊断问题。

2. 过程指标：计划是否反映真实执行

过程指标包括任务估算偏差、实际工时回填及时率、资源计划更新及时率、依赖等待时长、返工工时占比和临时任务占比。过程指标可以帮助 PMO 判断，是估算能力有问题，还是执行纪律有问题。

3. 风险指标：组织是否过度依赖少数人

风险指标包括单一专家依赖任务数、无替代资源的关键任务数、关键岗位连续超负荷周数、技能覆盖率和人员流失敏感度。一个项目即使按时交付，如果关键知识集中在一两个人身上，也可能留下严重的后续风险。

4. 不要把利用率作为唯一绩效指标

高利用率可能意味着资源紧张、计划过满或管理者把所有时间都塞进了任务。真正值得关注的是有效交付率，即计划投入中有多少转化为通过验收的成果。把利用率和返工率、等待时间、延期率一起看，才能避免鼓励低质量的“忙碌”。

十一、最后的操作清单：用四周启动一套最小可行机制

1. 第一周：统一口径和选定样本

• 选择 3 个代表性项目作为试点。
• 确定任务拆分标准和工时单位。
• 定义角色、技能、能力等级和资源状态。
• 建立项目优先级和冲突裁决规则。
• 明确哪些数据必须由项目经理、职能经理和 PMO 更新。

2. 第二周：完成任务和资源映射

• 把项目目标拆成交付物，再拆成活动和工时。
• 标记关键路径、前置依赖和不可替代技能。
• 建立每个人的可用日期、投入比例和已承诺工作。
• 找出未来四周的资源冲突和技能瓶颈。
• 为每个红色缺口准备至少两种替代方案。

3. 第三周：启动周度资源评审

• 只讨论变化、冲突、缺口和需要裁决的事项。
• 检查计划工时与实际工时的偏差。
• 检查临时任务是否侵蚀项目容量。
• 确认资源变更是否同步到了项目计划。
• 将未解决的红色风险提交项目委员会。

4. 第四周：复盘并校准基线

• 计算不同任务类型的估算偏差。
• 区分执行时间、等待时间和返工时间。
• 调整单人有效工时和资源预警阈值。
• 检查是否存在长期单一专家依赖。
• 决定哪些岗位需要招聘、培养、外包或自动化。

四周之后，不要急着宣布资源计划体系已经完成。真正的成熟需要至少经过两个到三个滚动周期，观察计划是否持续更新、冲突是否提前暴露、管理层是否依据数据做取舍，以及历史偏差是否被用于下一轮估算。

十二、总结：好的工作量管理，本质上是在管理不确定性

人力资源计划的核心不是把每个人的日历填满，而是让组织知道哪些工作必须完成、哪些能力不可替代、哪些资源冲突需要裁决，以及当资源不足时应该牺牲什么。工作量只有被拆成任务、放到时间轴、关联到技能并持续校准，才会从“感觉很忙”变成可以管理的事实。

我最看重的判断标准只有一个：当项目发生资源缺口时，PMO 能不能在问题变成延期之前，给出至少两种可比较的选择，并清楚说明每种选择的成本、速度、质量和风险。如果只能说“缺人”，说明组织还没有真正完成资源计划。

下一步可以从一个真实项目开始：列出未来八周的交付物，拆成可验收任务，标注技能和工时，再把每个人的可用容量放到同一张时间轴上。先找出最大的三个冲突，不要试图一次解决所有问题；用实际执行数据校准估算，用周度机制推动决策，最终再决定是否需要招聘、外包、换工具或调整组织结构。