项目组合资源需求图要回答的是：在既定周期内，按角色或技能看，组合还有多少可用容量，哪些候选项目能承接、哪些需要推迟。设计的关键在于把需求与容量统一到同一口径，再配套评审与更新机制。本文按口径定义、需求估算、图形结构、责任机制、示例和检查清单逐步展开，并说明如何借助ONES的组合视图与工作项数据承载这张图。
要点总览（TL;DR）
- 资源需求图的核心是把候选项目的需求按角色或技能、周期、数量统一口径，再与组合可用容量并列对照，用于判断组合还能承接哪些项目。
- 设计顺序是：先定角色/技能分类与容量口径，再把项目清单拆成需求明细并标注置信度，然后画出需求与容量的对照表，最后配套评审规则与更新节奏。
- 容量口径在人数、工时、占比中选一种并全图统一，需求单位与时间颗粒度必须与容量一致，否则汇总结果无法相加。
- 读图先看总量缺口，再看按角色的结构性错配，最后结合置信度落到具体项目的承接、推迟或拆分结论。
- 图要持续可用，需明确组合管理者、资源负责人、项目经理的分工，并在新项目进入、人员变动等条件下触发更新。
先定口径：角色、技能与容量怎么划分
资源需求图能否用于决策，首先取决于分类和计量是否统一。如果A部门按“人数”报需求、B部门按“人天”报需求，或者同一角色在不同项目里叫法不同，汇总结果就无法相加。设计的第一步是产出一张角色/技能分类与容量口径定义表，作为后续所有数据的基准。
分类粒度怎么选
分类粒度取决于组合需要回答的问题。若组合主要判断“某类项目还能不能排进去”，按角色分类（如后端开发、测试、产品经理）通常够用；若项目之间争抢的是特定技能（如数据建模、嵌入式驱动、安全测试），则需要在角色下再设技能子类。粒度太粗会掩盖结构性错配，粒度太细则维护成本高、估算误差大。一个可行的做法是：先按角色建一级分类，对瓶颈角色再拆技能子类，并在定义表中注明每个分类包含的岗位范围。
容量口径怎么算
可用容量有三种常见口径，选择一种并全图统一使用：
| 口径 | 计算方式 | 适用场景 | 注意事项 |
|---|---|---|---|
| 人数 | 周期内可投入该角色的人数 | 早期粗排、人员稳定的团队 | 无法体现兼职与投入比例差异 |
| 工时 | 人数 × 周期工作日 × 每日可投入工时 × 投入比例 | 需要精确比较项目需求量的组合 | 需扣除休假、培训、支持性工作 |
| 占比 | 某角色可分配给组合内项目的投入百分比 | 共享角色、跨组合协调 | 需明确剩余占比的去向 |
无论选哪种口径，都要在定义表中写明计算规则和扣除项。例如“可用工时 = 在岗人数 × 周期工作日 × 6小时 × 项目投入比例，扣除已批准休假”。
时间颗粒度与常见错误
需求单位与容量单位必须一致，时间颗粒度也要一致。组合层面常用月度或季度作为汇总周期，项目需求若按周估算，需要先折算到汇总周期再上图。常见口径错误包括：同一张图混用人数与工时；跨部门对“一个全职人力”的定义不同；把已批准休假计入可用容量；需求侧按自然月、容量侧按工作日统计。定义表应设置一列“口径校验”，在每次更新时逐项核对。
需求侧怎么估：从项目清单到资源需求行
需求侧的任务是把候选项目清单转成可汇总的结构化明细，每一行对应“项目—角色—周期—需求量”，并附估算依据与置信度。输入是已通过初筛的候选项目清单及其初步范围说明；输出是项目资源需求明细表。
拆分与估算方法
先按项目阶段或时间周期拆分需求。例如一个项目在需求分析阶段主要占用产品经理和业务分析，在开发阶段集中占用开发与测试。拆分后对每个“项目—角色—周期”组合估算需求量，常用三种方法：
- 类比估算：参照历史相似项目的资源投入，按规模差异调整。适合有可比案例的项目，速度快但依赖历史数据质量。
- 参数估算：用单位工作量参数乘以规模，如“每个接口约需X人天开发、Y人天测试”。适合范围较清晰、可量化的项目。
- 专家判断：由技术负责人或资源负责人给出估算。适合新型项目，但需记录判断依据。
每种估算都要标注置信度，建议分三档：高（有历史数据或详细范围）、中（有部分依据）、低（仅初步判断）。置信度低的项目在评审时应预留缓冲或列为待验证，避免把不确定需求当成确定需求占用容量。
需求明细表的结构
| 字段 | 说明 | 示例 |
|---|---|---|
| 项目编号与名称 | 与候选项目清单一致 | P-021 客户门户改版 |
| 阶段/周期 | 按汇总周期拆分 | 第三季度 |
| 角色/技能 | 使用定义表中的分类 | 后端开发 |
| 需求量 | 与容量同口径 | 120人天 |
| 估算方法 | 类比/参数/专家判断 | 类比 |
| 估算依据 | 参照对象或参数来源 | 参照P-014，规模系数1.2 |
| 置信度 | 高/中/低 | 中 |
完成标志是：每个候选项目在每个涉及的角色和周期上都有对应行，且每行都有估算方法和置信度；没有“待定”却未标注的行。
需求图怎么画：结构、视图与读图方法
需求图的作用是让需求与容量直接对照。最实用的结构是一张按周期汇总、按角色分列的表格：行是角色或技能，列是周期，每个单元格同时给出需求量和可用容量，并标注差额。项目数量较多时，可在单元格内用堆叠方式列出各项目的需求量，便于追溯。
表格结构与标注方式
| 角色/技能 | 第三季度需求 | 第三季度容量 | 差额 | 状态 |
|---|---|---|---|---|
| 后端开发 | 420人天 | 380人天 | -40 | 缺口 |
| 测试 | 150人天 | 200人天 | +50 | 余量 |
| 产品经理 | 90人天 | 90人天 | 0 | 平衡 |
缺口与余量用统一符号或颜色标注，并在图旁注明口径（如“人天，已扣除休假”）。若需要看趋势，可增加按月的折线或柱状对照；若需要看项目构成，可在缺口单元格下展开项目明细。图形形式服从于读图需求，不必追求复杂。
读图顺序
建议先看总量：所有角色的需求合计与容量合计相比，组合整体是超载还是有余量。再看结构性错配：哪些角色出现缺口而另一些角色有余量，这类错配无法通过总量调整解决，需要跨角色协调或调整项目范围。最后落到项目：结合需求明细中的置信度，判断缺口是由确定需求还是待验证需求造成，再形成承接、推迟或拆分的建议。
角色分工与更新机制：谁维护、谁评审、多久更新
资源需求图做完就失效，通常是因为没有明确谁维护、何时更新。责任体系应覆盖三类角色：组合管理者负责图的整体口径和评审组织；资源负责人提供各角色的可用容量并对数据准确性负责；项目经理提供项目需求明细和估算依据。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 组合管理者 | 维护口径定义、组织评审、形成承接结论 | 评审纪要与组合排期建议 |
| 资源负责人 | 提供并确认容量数据、审核需求合理性 | 容量数据与缺口说明 |
| 项目经理 | 提交项目需求明细、标注置信度、响应变更 | 项目资源需求明细表 |
更新节奏与触发条件
固定节奏建议与组合评审周期一致，例如每季度全面更新一次、每月核对容量变化。除固定节奏外，以下情况应触发临时更新：新项目进入候选清单、人员入离职或长期休假、项目范围发生重大变更、资源负责人调整投入比例。每次更新记录版本号、更新人、变更内容和影响结论，便于回溯。
图与决策的衔接点在于评审规则：评审时先确认口径与数据版本，再按“总量—结构—项目”的顺序讨论，最后形成每个候选项目的承接、推迟或拆分结论，并指定责任人跟进。没有结论的评审应记录待决事项和下次评审时间。
在工具层面，ONES的资源规划视图可按业务优先级安排团队资源，查看成员工作量、可用性与饱和情况，并通过筛选与分组掌握成员在不同项目的投入比重。组合管理者可以把工作项中的项目清单和人员投入数据作为需求明细与容量数据的来源，减少手工汇总；具体字段和时间颗粒度需在实际环境中核对后再定模板。
示例：一个季度的组合资源需求图怎么填
以下为演示情景，数据为假设，用于说明填写过程，不代表任何真实组织。
背景与假设：某研发组合第三季度有四个候选项目，角色分为后端开发、前端开发、测试、产品经理；容量按人天计，已扣除休假和固定支持工作；汇总周期为季度。
需求明细汇总：P-021客户门户改版需后端120人天、前端80人天、测试60人天、产品经理30人天，置信度中；P-022数据报表平台需后端150人天、测试50人天、产品经理20人天，置信度高；P-023移动端适配需前端100人天、测试40人天，置信度低；P-024内部流程优化需后端80人天、产品经理25人天，置信度中。
| 角色 | 需求合计 | 容量 | 差额 | 主要构成 |
|---|---|---|---|---|
| 后端开发 | 350人天 | 300人天 | -50 | P-021 120、P-022 150、P-024 80 |
| 前端开发 | 180人天 | 200人天 | +20 | P-021 80、P-023 100 |
| 测试 | 150人天 | 160人天 | +10 | P-021 60、P-022 50、P-023 40 |
| 产品经理 | 75人天 | 90人天 | +15 | P-021 30、P-022 20、P-024 25 |
读图结论：后端开发存在50人天缺口，其余角色有余量。结合置信度，P-023置信度低且主要占用前端和测试，前端余量可承接；后端缺口主要来自P-022的确定需求，建议优先保障P-022，将P-024推迟到下季度或缩减范围，P-021按原计划承接。若P-023范围明确后测试需求上升，需重新核对测试容量。
适用边界：该示例只处理组合层面“承接哪些项目”的判断，不涉及已选项目之间的人员调配和任务分配；实际使用时容量口径、角色分类和置信度标准应按组织情况调整。
完成检查：这张图能不能支撑决策
在把资源需求图提交评审前，逐项核对以下清单。任何一项不通过，应先修正再进入决策环节。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 口径一致性 | 需求与容量使用同一单位、同一时间颗粒度，分类与定义表一致 | 回到定义表统一口径，重新折算数据 |
| 数据完整性 | 每个候选项目在每个涉及角色和周期上都有需求行，无未标注的空缺 | 要求项目经理补齐或明确标注“未估算” |
| 置信度标注 | 每行需求都有估算方法和置信度 | 补充估算依据，低置信度项目列为待验证 |
| 容量覆盖 | 容量覆盖组合涉及的全部角色，扣除项已说明 | 由资源负责人补充缺失角色容量 |
| 评审与更新机制 | 责任人、更新节奏、触发条件已明确并记录 | 在评审前确定责任人和下次更新日期 |
检查通过后，图即可作为立项与排期评审的输入。评审中形成的承接、推迟或拆分结论应回写到项目清单，并注明依据的图版本，确保后续变更可追溯。
常见问题
候选项目还没立项，需求估算很粗，能先放进资源需求图吗？
可以，但要区分确定与不确定。建议把初筛阶段的候选项目一并纳入，估算时标注方法和置信度，低置信度项目在图上单独标记或列为待验证。评审时先保障高置信度的确定需求，低置信度项目按余量安排或设置验证节点，避免把粗略估算当成确定占用。
组合内不同部门的角色名称和投入比例不一致，怎么统一到一张图上？
先由组合管理者牵头建立一份角色/技能映射表，把各部门的叫法归并到统一分类，并注明每个分类包含的岗位范围。投入比例按同一公式折算，例如统一折算为“人天”后再汇总。映射表随图一起版本化管理，新增角色时先补映射再录入需求，避免各部门各自换算导致口径漂移。
资源需求图应该多久更新一次，临时变化怎么处理？
固定节奏可与组合评审周期对齐，例如每季度全面更新、每月核对容量变化。除固定节奏外，新项目进入候选清单、人员入离职或长期休假、项目范围重大变更、投入比例调整时应触发临时更新。每次更新记录版本号、更新人、变更内容和受影响的结论，评审时以最新版本为准。
图上显示某角色有缺口，是否意味着相关项目都要推迟？
不一定。缺口要结合需求置信度和项目优先级判断：缺口若主要来自低置信度需求，可先安排验证再决定；若来自确定的高优先级需求，则优先保障，把低优先级项目推迟或缩减范围。跨角色有余量时，也可评估技能可迁移性或调整项目组合顺序，但这类协调属于已选项目之间的资源安排，需另行处理。
用ONES承载资源需求图时，需要提前确认哪些设置？
ONES的资源规划视图可按业务优先级安排团队资源，查看成员工作量、可用性与饱和情况，并支持筛选与分组掌握成员在不同项目的投入比重（F2、F3、F4）。落地前建议在实际环境中核对角色分类字段、时间颗粒度、投入比例的统计口径，以及报表可用的分组维度和导出方式，再确定模板，使图上的需求与容量数据能直接从工作项和人员投入记录中汇总。
