项目组合资源需求图的设计思路，是把每个候选或在途项目的资源需求按角色、技能和时间段拆开，再与可用容量放在同一时间轴上对照。它服务于组合层面的承接判断，颗粒度通常落在角色或技能族、周期按月或季度滚动。下面按口径、步骤、角色、示例、情景对比和检查六个环节展开。
要点总览（TL;DR）
- 资源需求图服务于组合层面的承接判断，颗粒度定在角色或技能族，周期按季度规划、月度滚动，不落到个人日程。
- 搭建分四步：整理项目清单、按角色拆解需求、汇总可用容量、在同一时间轴叠加计算缺口，每步都有对应输出物。
- 数据责任分四段：项目经理提供需求，资源负责人确认容量，PMO汇总校验并出图，组合决策层依据缺口做取舍。
- 情景对比用同一口径分别计算基准与调整情景的缺口，比较缺口总量、分布和关键约束点，并记录假设条件。
- 需求图进入决策前核对口径一致性、数据完整性、可解释性、可维护性和决策可用性五项。
先定口径：资源需求图要回答什么
资源需求图在组合管理中承担一个明确任务：回答某段时间内，组合所需资源与组织可用容量是否匹配。它帮助决策层判断哪些项目可以承接、哪些需要错峰、哪些需要补充外部资源。这个定位决定了图的内容以角色和时段为主，不落到个人日程。
口径说明需要写清四件事，建议控制在一页内，作为后续所有数据填报的依据。
| 口径项 | 建议设定 | 说明 |
|---|---|---|
| 资源颗粒度 | 角色或技能族 | 如后端开发、测试、产品经理、UI设计；同一角色内不区分具体人员 |
| 规划周期 | 季度为主，月度滚动更新 | 季度用于组合决策，月度用于跟踪偏差 |
| 工时单位 | 人天或人时，全组合统一 | 统一单位是缺口计算不失真的前提 |
| 使用角色 | 组合决策层、PMO、项目经理、资源负责人 | 各自读取不同视图，不共用一张明细表 |
需要明确划出边界：已选项目之间的人员协调、个人负载冲突处理，属于项目集执行层面的工作，由项目经理和职能经理在日常协作中解决。资源需求图只呈现组合层面的供需关系，不承担排班职能。把这两类工作混在一张图里，往往导致图越做越细、决策价值反而下降。
核心步骤：从项目清单到资源需求图
从零搭建一张需求图，可以按四步推进。每一步都有明确输入、动作和输出，完成标志是输出物通过口径校验。
第一步：整理项目清单
输入是候选项目与在途项目的完整列表。动作是为每个项目标注优先级、计划起止时间、关键里程碑，以及当前所处的阶段（立项评审、执行中、待启动）。输出是一张项目清单表，字段至少包括项目名称、优先级、起止月份、里程碑节点、项目负责人。完成标志是清单经组合管理者确认，没有遗漏在途项目。
第二步：按角色拆解资源需求
输入是项目清单和每个项目的初步方案。动作是项目经理按角色估算各时间段的工时需求，形成“项目—角色—时间段”的三维数据。例如某项目在第二季度需要后端开发120人天、测试60人天。输出是资源需求明细表。完成标志是每个项目的每个角色在每个时间段都有需求数字，且能说明估算依据（如工作量分解、历史类比）。
第三步：汇总可用容量
输入是组织架构、人员技能分布和考勤安排。动作是资源负责人按角色统计各时间段可投入工时，并扣除休假、运维支持、培训等固定占用，只保留可自由调配的部分。输出是容量表，按角色和时间段排列。完成标志是容量数字有来源、有责任人，且与需求表使用同一时间颗粒度和工时单位。
第四步：叠加需求与容量，计算缺口
输入是需求明细表和容量表。动作是在同一时间轴上逐角色、逐时间段计算“需求减容量”，得到缺口或余量，并绘制需求—容量对照图。输出是需求图与缺口汇总表。完成标志是每个缺口都能追溯到具体项目和角色，图上能直观看出缺口集中在哪些角色、哪些月份。
角色分工与各环节交付物
需求图能否持续可用，取决于数据责任是否清晰。四个角色各管一段，交接点明确，图才不会变成PMO的单方面估算。
| 角色 | 主要职责 | 交付物 | 交付时点 |
|---|---|---|---|
| 项目经理 | 提供项目资源需求与时间假设，说明估算依据 | 项目资源需求明细 | 规划周期开始前 |
| 资源负责人/职能经理 | 确认各角色可用容量、技能约束和外部补充可能性 | 角色容量表 | 与需求明细同步提交 |
| PMO或组合管理者 | 汇总数据、校验口径一致性、输出需求图 | 需求—容量对照图、缺口汇总 | 规划评审前 |
| 组合决策层 | 依据缺口图判断承接、排期调整或范围取舍 | 组合决策结论与假设记录 | 组合评审会 |
汇总环节需要处理两类常见问题：一是各项目估算口径不一，有的按人天、有的按人力占比，PMO要在汇总前统一换算；二是容量数据滞后，资源负责人提交的可用工时未反映最新的人员变动。解决方式是把口径校验和容量确认设为汇总的前置条件，数据不齐不进入绘图环节。
当项目数量较多、需求变更频繁时，手工表格容易失真。ONES 的资源规划视图可以按业务优先级安排团队资源，查看项目和团队的资源利用率与负荷度，并支持多维度统计项目和成员的资源投入、导出工时登记日志，适合作为需求与容量数据的汇总和跟踪载体。具体视图配置与统计口径以实际版本为准。
示例：一个季度的资源需求图怎么画
以下为演示情景，数据为简化设定，用于说明从表格到结论的转化过程。设定：三个候选项目A、B、C，两类角色（后端开发、测试），规划周期为一个季度，拆为四个时间段（可按月或按周，示例按月）。
需求汇总表（单位：人天）：
| 项目 | 角色 | 第1月 | 第2月 | 第3月 | 第4月 |
|---|---|---|---|---|---|
| 项目A | 后端开发 | 40 | 60 | 40 | 20 |
| 项目A | 测试 | 0 | 20 | 30 | 20 |
| 项目B | 后端开发 | 20 | 40 | 40 | 30 |
| 项目B | 测试 | 0 | 10 | 20 | 20 |
| 项目C | 后端开发 | 0 | 20 | 40 | 40 |
| 项目C | 测试 | 0 | 0 | 20 | 30 |
| 合计需求 | 后端开发 | 60 | 120 | 120 | 90 |
| 合计需求 | 测试 | 0 | 30 | 70 | 70 |
容量对照表（单位：人天，已扣除休假与固定占用）：
| 角色 | 第1月 | 第2月 | 第3月 | 第4月 |
|---|---|---|---|---|
| 后端开发可用容量 | 80 | 80 | 80 | 80 |
| 测试可用容量 | 40 | 40 | 40 | 40 |
| 后端开发缺口 | +20 | -40 | -40 | -10 |
| 测试缺口 | +40 | +10 | -30 | -30 |
解读这张对照表：后端开发在第2、3月各缺40人天，是组合承接的主要约束；测试在第3、4月各缺30人天，缺口出现时间晚于后端。据此可以判断：项目A和B的后端需求叠加后超出容量，若三个项目同时启动，第2月起后端将成为瓶颈；测试缺口集中在后半段，可通过错峰安排项目C的测试阶段或临时补充测试资源缓解。结论应落到具体项目与角色，例如“项目C的后端启动时间后移一个月，可削平第2月的40人天缺口”。
情景对比与组合取舍
单张需求图给出的是一个时点的供需快照，组合决策往往需要在多个承接方案之间比较。做法是设定基准情景和调整情景，用同一套数据口径分别计算缺口，再对比结果。
| 对比项 | 基准情景 | 调整情景一 | 调整情景二 |
|---|---|---|---|
| 情景设定 | 三个项目按原计划启动 | 项目C延后一个月启动 | 项目C保留，测试资源外部补充1人 |
| 后端最大缺口 | 第2、3月各40人天 | 第2月缺口降至20人天 | 与基准相同 |
| 测试最大缺口 | 第3、4月各30人天 | 缺口整体后移一个月 | 第3、4月缺口基本消除 |
| 主要代价 | 后端超载，交付风险高 | 项目C交付时间推迟 | 增加外部资源成本与磨合期 |
| 适用条件 | 可接受短期超载并快速补充人力 | 项目C时间弹性较大 | 测试技能外部可获得且预算允许 |
对比时关注三个要点：缺口的总量和分布是否改善，关键约束点（本例中的后端第2月）是否被削平，以及每个情景的假设条件是否成立。情景结论要写成可执行的组合选择，例如“采用调整情景一，项目C延后一个月，同时保留测试外部补充作为后备方案”，并把假设条件（项目C可延后、外部测试资源可在一个月内到位）一并记录，便于后续回溯和调整。
情景对比的价值在于把“能不能接”变成“在什么条件下接、代价是什么”。建议每次组合评审至少保留基准情景与一至两个调整情景，情景数量不宜过多，否则比较成本会超过决策收益。
完成检查：需求图是否可用
需求图进入决策使用前，按以下清单逐项核对。任一项不通过，先修正再提交评审。
- 口径一致性：所有项目的资源颗粒度统一到角色或技能族，时间周期一致，工时单位一致；抽查两到三个项目，确认换算无误。
- 数据完整性：项目清单覆盖全部候选与在途项目；每个角色需求有估算依据；容量数据有来源和责任人；无空白单元格或未说明的默认值。
- 可解释性：每个缺口能追溯到具体项目和角色；汇总数字与明细能对上；图上标注了关键约束点。
- 可维护性：明确更新频率（如月度滚动）和触发更新的条件（新项目立项、重大范围变更、人员变动）；指定数据汇总责任人。
- 决策可用性：图能直接支撑“接不接、何时接、缺什么”三类问题；情景对比的假设条件已记录。
这张检查清单也可以作为需求图模板的固定附页，每次更新后由PMO复核签字，再提交组合决策层。随着项目数量增长，需求与容量数据的汇总和跟踪工作量会明显上升，ONES 的资源规划与工时统计能力可以在这一环节承接数据汇总和利用率查看，减少手工表格的维护成本；组合层级的汇总口径和视图配置需结合组织实际情况设定。
常见问题
候选项目还没立项，资源需求估算不准，要不要先画进需求图？
建议画进去，但要标注估算的成熟度。候选项目的需求数字可以来自初步方案或历史类比，在明细表中用“粗估/细估”区分，并在图上单独标识。这样组合决策层能看到潜在需求对容量的挤压程度，又不会把粗估数字当成承诺。随着项目进入立项评审，再逐步替换为细化后的需求。
可用容量按角色汇总后，个别关键技能只有一两个人，缺口怎么表达？
角色颗粒度下仍可能遇到稀缺技能。处理方式是在角色之下再设一个“关键技能”标记，容量表按角色汇总的同时，对稀缺技能单独列一行，注明可投入人数和不可替代性。缺口计算仍按角色进行，但在结论中说明该角色的缺口实际受限于特定技能，补充外部资源或调整排期的难度更高。这样既不把图做成个人排班表，也保留了关键约束的可见性。
需求图多久更新一次，什么情况下要临时重算？
常规节奏建议月度滚动更新，季度做一次完整重算用于组合评审。触发临时重算的条件通常包括：新项目立项或项目取消、重大范围变更导致需求数字明显变化、关键人员变动影响容量、外部资源补充到位或落空。把这些触发条件写进口径说明，并指定由PMO判断是否启动重算，可以避免图长期停留在过期状态。
情景对比做几个比较合适，多了会不会反而难决策？
建议保留基准情景加一至两个调整情景。情景过多时，各方案的假设条件交叉，比较成本会超过决策收益。选择调整情景时优先覆盖主要约束点，例如针对缺口最大的角色或月份设计延后、替换资源、调整范围三类动作。每个情景记录清楚假设条件和代价，结论写成可执行的选择，而不是并列罗列多个方案。
用表格手工维护需求图，项目多了以后怎么减少失真？
手工表格在项目数量增长后容易出现口径不一和更新滞后。可以先把口径校验和容量确认设为汇总的前置条件，数据不齐不进入绘图；再借助工具承接数据汇总与跟踪。ONES 的资源规划视图可以按业务优先级安排团队资源，查看项目和团队的资源利用率与负荷度，并支持多维度统计资源投入、导出工时登记日志，适合作为需求与容量数据的汇总载体，具体视图配置与统计口径以实际版本为准。
