项目组合资源需求图把候选项目的资源需求按角色、技能和时间段汇总，与可用容量放在同一张图上对照，用来判断组合在当前容量约束下还能承接哪些项目。下面以虚构企业的季度组合评审为示例，给出数据字段、填写样例、逐项解释和可迁移规律，帮助读者照着搭建自己的需求图。
要点总览（TL;DR）
- 项目组合资源需求图把候选项目的角色需求与可用容量放在同一张表上对照，用来判断组合在当前容量约束下还能承接哪些项目。
- 示例按优先级从高到低累加需求：P1全部纳入，P2整体可纳入但UI角色出现0.5人月缺口，P3推迟到下季度。
- 关键字段包括优先级、按角色的人月需求、按“在岗人数×可用比例×月数”折算的容量，以及缺口对应的项目动作。
- 可复用规律是：先定评审问题再定粒度，容量口径统一优先于估算精度，按角色汇总，缺口结论落到具体项目动作。
- 该方法只处理组合承接判断，已选项目间的人员协调归执行层排期；示例为虚构情景，数字需替换为组织自身数据。
示例要回答的问题与图的目标
资源需求图在组合评审中承担一个具体判断：在现有容量约束下，候选项目里哪些可以纳入本季度，哪些需要推迟，哪些要缩小范围后再纳入。它处理的是组合层面的承接问题，输入是各候选项目的资源需求与组织可提供的容量，输出是纳入、推迟或缩范围的结论。已经立项项目之间的人员协调、任务分配和冲突处理，属于项目执行层面的排期工作，不在本图的目标范围内。
示例情景设定如下，全部数据为虚构，仅用于演示填写方法：
- 企业：一家虚构的中型软件企业，约120名研发人员，业务覆盖三条产品线。
- 时间：虚构的2025年第三季度（7月至9月），按月度分段统计。
- 角色：后端开发、前端开发、测试、产品经理、UI设计五类角色，人数与技能分布为虚构设定。
- 候选项目：本季度组合评审会上提交的6个候选项目，均已通过立项初筛，等待资源承接判断。
- 评审目标：在季度容量约束下，确定候选项目的纳入、推迟与缩范围方案。
把目标先写清楚，图的粒度才有依据。如果评审问题是“本季度最多能启动几个项目”，按角色汇总到季度即可；如果问题是“哪些项目会在8月卡住测试资源”，就需要按月甚至按周分段。示例选择按月分段，是因为季度评审会上最常见的争议集中在“某个月某类角色是否够用”。
完整示例：一张季度项目组合资源需求图
示例先列出候选项目及其优先级标记。优先级由组合评审会依据战略贡献、客户承诺和投入产出预估确定，标记为P1（本季度必须启动）、P2（本季度尽量启动）、P3（可推迟）。
| 候选项目 | 优先级 | 需求时间段 | 后端（人月） | 前端（人月） | 测试（人月） | 产品（人月） | UI（人月） |
|---|---|---|---|---|---|---|---|
| 项目A 订单系统重构 | P1 | 7–9月 | 6 | 3 | 3 | 1 | 1 |
| 项目B 移动端改版 | P1 | 7–8月 | 2 | 4 | 2 | 1 | 2 |
| 项目C 数据看板 | P2 | 8–9月 | 3 | 2 | 1 | 1 | 1 |
| 项目D 客户门户 | P2 | 7–9月 | 3 | 3 | 2 | 1 | 1 |
| 项目E 内部工具升级 | P3 | 9月 | 2 | 1 | 1 | 0 | 0 |
| 项目F 报表引擎替换 | P3 | 8–9月 | 4 | 0 | 2 | 1 | 0 |
接着给出各角色的可用容量。容量按“在岗人数×可用比例×月数”折算，可用比例扣除休假、培训、支持性工作和已承诺的运维投入，示例取75%。
| 角色 | 在岗人数 | 可用比例 | 季度可用容量（人月） |
|---|---|---|---|
| 后端开发 | 10 | 75% | 22.5 |
| 前端开发 | 6 | 75% | 13.5 |
| 测试 | 5 | 75% | 11.25 |
| 产品经理 | 3 | 75% | 6.75 |
| UI设计 | 2 | 75% | 4.5 |
把需求与容量对照，得到缺口与承接结论。示例按优先级从高到低逐项累加需求，观察哪一步开始超出容量。
| 角色 | P1需求 | P1+P2需求 | 全部候选需求 | 可用容量 | P1+P2缺口 | 承接结论 |
|---|---|---|---|---|---|---|
| 后端 | 8 | 14 | 20 | 22.5 | 无缺口 | P1、P2均可纳入 |
| 前端 | 7 | 12 | 13 | 13.5 | 无缺口 | P1、P2均可纳入 |
| 测试 | 5 | 8 | 11 | 11.25 | 无缺口 | P1、P2均可纳入 |
| 产品 | 2 | 4 | 5 | 6.75 | 无缺口 | P1、P2均可纳入 |
| UI | 3 | 5 | 6 | 4.5 | UI缺口0.5人月 | P2中项目C或D的UI需求需压缩或错峰 |
示例结论：P1两个项目全部纳入；P2两个项目整体可纳入，但UI角色在季度内出现0.5人月缺口，处理方式是把项目C的UI设计推迟到9月下旬启动，或由项目D复用已有设计组件压缩0.5人月；P3两个项目本季度不纳入，其中项目F的后端需求较大，若强行纳入会使后端接近满负荷，建议推迟到下季度并提前锁定后端人员。
逐项解释：每个字段为什么这样填
角色与技能粒度选择五类角色，是因为示例企业的评审争议集中在开发、测试与设计之间的人力腾挪，产品经理数量少且需求稳定，单独列出便于核对。粒度再细到具体技能（如后端中的数据库方向），会增加填写成本，只有当某类技能是稀缺瓶颈时才值得细分。判断标准是：评审会上会被追问“这类人够不够”的类别，就应当单独成列。
需求人月的估算口径按“项目工作量÷人均月产能”折算，示例中假设1人月等于1名该角色人员满负荷工作1个月。时间分段按月，是因为示例的容量约束在季度内分布不均，UI缺口集中在8月。若项目周期短于1个月或跨月波动大，可改为按周分段；分段越细，数据维护成本越高，需要与评审频率匹配。
可用容量的折算方式是“在岗人数×可用比例×月数”。可用比例75%是示例假设，扣除项包括年假、培训、线上支持与已承诺的运维值班。折算时要注意两点：一是已立项项目的占用应先从容量中扣除，示例为简化演示，假设容量表已扣除存量项目占用；二是新入职人员按到岗月份折算，不能整季度计入。
缺口转化为决定时，示例采用优先级累加法：先满足P1，再叠加P2，出现缺口的角色对应到具体项目动作。缺口处理有四种常见动作——纳入并接受风险、推迟低优先级项目、缩小项目范围、错峰安排启动时间。示例中UI缺口0.5人月，选择了错峰与复用组件两种低成本动作，而不是直接砍掉一个P2项目，因为缺口规模小且集中在单一角色。
在工具承载上，候选项目、优先级、角色需求与容量数据需要放在同一处维护，评审时才能随优先级调整实时重算缺口。ONES的项目管理支持以工作项承载候选项目与优先级字段，资源管理可按角色查看成员投入与可用情况，评审结论可以直接回写到项目状态或计划中，减少表格与评审记录之间的反复核对。示例中的容量口径与可用比例仍需企业按自身制度设定。
可迁移规律：换一个组合怎么复用
先定评审问题，再定图的粒度。评审问的是季度承接总量，按角色汇总到季度即可；问的是某月瓶颈，就按月或按周分段。粒度服务于争议点，不追求越细越好。
容量口径统一优先于估算精度。需求估算允许有偏差，但所有项目的估算口径、容量折算方式、扣除项必须一致，否则缺口数字无法比较。示例中所有项目都按同一人月口径填写，容量统一按75%折算，这是结论可信的前提。
按角色而非按人汇总，避免个体绑定。需求图回答的是“这类角色够不够”，写成具体人名会让评审变成人员调配会，也会因人员变动频繁失效。只有在确认缺口后，才进入具体人员安排环节。
缺口结论要落到具体项目动作。每个缺口都应写明对应哪个项目、采取纳入、推迟、缩范围还是错峰，并注明责任人与复核时间。只标红缺口不给动作，图就无法支撑评审决策。
保留版本与假设记录。每次评审的容量假设、优先级调整和结论应留档，下季度复盘时才能判断估算偏差来自哪里。示例中的75%可用比例、优先级标记都属于需要记录的假设。
适用边界与常见误用
该方法适用于组合层面的承接判断，即回答“还能接哪些项目”。已选项目之间的人员协调、任务分派与冲突处理，属于执行层面的排期工作，需要项目计划与人员调度机制解决，资源需求图不承担这一职责。
估算精度与数据时效是主要限制。人月估算在项目早期偏差较大，容量数据随人员变动、休假和紧急支持随时变化，示例中的数字只代表评审时点的快照。建议在评审前一周更新数据，并在结论中标注假设，避免把快照当成长期承诺。
常见误用有三类：把需求图当成排期表，直接据此分配具体任务；把需求图当成绩效表，用需求满足率评价团队；只画图不更新，评审后数据长期不维护。前两类混淆了组合判断与执行管理、绩效管理的边界，第三类会让图失去决策价值。
需要说明的是，本文示例为虚构演示情景，企业、季度、人员与数字均为设定，不代表真实客户数据，也不构成对任何工具实测效果的说明。读者迁移时应以自己的组织数据替换示例数值，并按自身评审制度确定优先级规则与容量口径。
常见问题
候选项目还没立项，怎么估出人月需求？
组合评审阶段的估算允许有偏差，关键是口径统一。常用做法是让项目负责人按角色给出粗略工作量，再除以该角色的人均月产能折算成人月，并标注估算依据（如类比历史项目、拆解主要模块）。所有候选项目用同一套口径填写，缺口数字才有可比性。评审结论中应注明这是评审时点的估算，立项后再按详细计划修正。
可用容量里要不要先扣掉已立项项目的占用？
要扣。资源需求图判断的是“还能承接多少”，可用容量应当是扣除存量项目占用后的剩余容量。示例为简化演示，假设容量表已扣除存量占用；实际操作中建议在容量表里单列“总容量”“存量占用”“剩余可用”三栏，避免评审时把已承诺的人力重复计算。已承诺的运维值班、线上支持等固定投入也应一并扣除。
缺口出现时，先砍项目还是先缩范围？
取决于缺口规模和集中程度。缺口小且集中在单一角色时，优先考虑错峰启动、复用已有组件或临时外部支持，成本较低；缺口大且跨多个角色时，再考虑推迟低优先级项目或缩小项目范围。无论选哪种，都要在图上写明对应项目、动作、责任人和复核时间，只标红缺口不给动作，图就支撑不了评审决策。
按月分段还是按周分段更合适？
看评审争议点在哪里。如果争议是季度总量能否承接，按角色汇总到季度即可；如果争议是某个月某类角色是否卡住，就按月分段；项目周期短于一个月或跨月波动大时，再考虑按周分段。分段越细，数据维护成本越高，需要与评审频率匹配，避免图刚填完就过期。
这张图能直接用来给成员派活吗？
不能。资源需求图回答的是组合层面“这类角色够不够”，按角色汇总，不绑定具体人员。具体任务分派、人员协调和冲突处理属于项目执行层面的排期工作，需要项目计划与调度机制解决。把需求图当排期表用，会让评审变成人员调配会，也会因人员变动频繁失效。
