研发资源需求与容量规划回答的是“这批需求我们做得完吗、缺多少”，项目组合资源容量规划回答的是“在有限容量下先做哪些项目”。两者使用相近的人力数据，但规划对象、时间跨度和决策权限不同。本文按同一口径对照两个概念，拆解前者的核心环节，并说明它与研发人员排期的边界，帮助判断当前该先建立哪一类规划。ONES 可作为承载需求、工时与跨项目投入数据的管理工具，具体取舍仍取决于团队的组织方式。
要点总览（TL;DR）
- 研发资源需求与容量规划回答“这批需求做得完吗、缺多少”，输出角色级缺口清单与补人、调范围、调时间的处置建议。
- 项目组合资源容量规划回答“有限容量下先做哪些项目”，输出项目优先级排序与承接、延后、缩减结论。
- 前者的核心环节是需求拆解、容量盘点、供需比对、处置方案和复盘校准，按迭代或季度滚动更新。
- 容量规划管角色与团队层面的总量，人员排期管到人到天；容量结论是排期的约束输入，提前锁定到人会压缩调整空间。
- 需求波动大、缺口频繁时先建团队级供需测算；多项目争抢同一批人、立项缺依据时再向上做组合取舍，两层共用角色定义和工时口径。
两个概念各自解决什么问题
研发资源需求与容量规划的核心问题是可用人力的供需是否平衡。它把一批研发任务拆解为角色、技能和工时需求，再对照团队在对应时间段内真正可投入的工时，算出缺口或富余，并给出补人、外协、调整范围或调整时间的处置建议。它的对象通常是一个团队或一批需求，输出物是缺口清单和处置方案。
项目组合资源容量规划的核心问题是在容量约束下承接哪些项目。它面对多个候选项目，需要判断哪些立项、哪些延后、哪些缩减范围。它的对象是组织内的项目组合，输入包括各团队的容量结论、项目价值评估和战略优先级，输出物是项目优先级排序与承接结论。
两者的对象范围差异明显：前者聚焦单批需求与单个团队的匹配，后者聚焦多项目对同一批人的争抢。输出物也不同，前者交付“缺多少、怎么补”，后者交付“先做谁、后做谁、放弃谁”。理解这一层区别，后续的环节设计和数据口径才不会混用。
同口径差异对照：维度、时间跨度与决策权限
把两个概念放在同一组维度下比较，差异会更清楚。下表按规划对象、时间跨度、输入数据、核心动作、输出结果和决策角色六个维度并列呈现。
| 比较维度 | 研发资源需求与容量规划 | 项目组合资源容量规划 |
|---|---|---|
| 规划对象 | 单批需求与单个团队（或若干执行团队）的人力供需 | 组织内多个项目构成的组合 |
| 时间跨度 | 通常按迭代或季度滚动，随需求变化频繁更新 | 通常按季度或年度，与预算和战略周期对齐 |
| 输入数据 | 任务拆解后的角色与工时需求、团队可用工时、休假与支持性工作占用 | 各团队容量缺口汇总、项目价值与投入产出评估、战略优先级 |
| 核心动作 | 供需比对，识别缺口并制定处置方案 | 项目排序，在容量约束下做承接、延后或缩减决策 |
| 输出结果 | 缺口清单与补人、调范围、调时间的建议 | 项目优先级清单与立项、延后、缩减结论 |
| 决策角色 | 研发负责人与团队负责人 | 组合管理角色或管理层 |
两个概念在数据上是上下游关系：需求侧的角色工时估算和容量盘点结果，向上汇总后成为组合容量判断的依据。团队层面的缺口数据如果不准确，组合层面的取舍就缺少可靠基础；反过来，组合层面确定的项目优先级，又会改变各团队需要承接的需求范围，触发新一轮供需测算。
研发资源需求与容量规划的核心环节
这一规划可以拆成五个环节，每个环节都有明确的产出物。环节之间是递进关系，前一步的产出是后一步的输入。
需求收集与拆解
把待做的研发任务按角色和技能拆开，估算每项任务需要的工时。产出是一份按角色分类、带时间窗口的需求清单。估算时区分确定需求和概率性需求，避免把尚未确认的机会也计入刚性缺口。
容量盘点
统计团队在对应时间段内真正可投入的工时。计算口径通常是名义工时扣除休假、培训、线上支持、会议等占用。产出是分角色、分时间段的可用容量表。口径要稳定，否则不同周期的结论无法比较。
供需比对
把需求清单与容量表按角色和时间段对齐，计算每个窗口的缺口或富余。产出是缺口清单，标明缺口出现的角色、时间段和数量。比对时区分峰值缺口和平均缺口，两者的处置方式不同。
处置方案
针对缺口列出可选动作并评估代价：补人涉及招聘周期和融入成本，外协涉及协作与质量风险，调范围涉及砍掉哪些需求及其影响，调时间涉及交付承诺的变更。产出是一份带取舍理由的处置建议，供研发负责人决策。
复盘校准
项目推进后用实际投入与当初估算对比，修正工时估算系数和容量口径。产出是更新后的估算基准。这个环节容易被跳过，但它决定了下一轮规划的可信度。
在承载方式上，ONES 资源管理可展示工作和资源情况，支持资源规划、资源配置、资源监控与预测分析；资源规划视图可按业务优先级安排团队资源，用于平衡可用资源与需求。这些能力对应上述环节中的数据记录与比对动作，估算口径和处置决策仍需团队自己定义。
与研发人员排期的边界：规划管供需，排期管到人到天
容量规划与人员排期常被混为一谈，但两者的管理粒度不同。排期的对象是具体人员与具体时间段的任务分配，回答“张三下周做什么”。容量规划的对象是角色或团队层面的供需总量，回答“这个团队这个季度前端人力缺几个人月”。
两者的衔接点在于：容量结论是排期的约束输入。团队先知道本周期可承接的工作量上限，再在这个上限内把任务分到人。如果容量规划阶段就锁定到人，一旦需求变化或有人请假，调整空间会被压缩，排期频繁返工。
实践中的做法是分层推进：容量规划确定角色级的总量边界，排期在边界内做具体分配，排期结果再反馈实际投入，用于校准容量口径。ONES 资源管理支持通过工作数量和工时规模了解成员排期，并可筛选分组查看成员在不同项目的投入比重，也能查看每日投入饱和明细，这些数据可用于监控排期是否超出容量边界。
组合层面如何用容量结论做项目取舍
两个概念的衔接发生在组合层面。团队完成供需测算后，容量结论需要向上汇总，转化为项目取舍的依据。这个过程可以按以下步骤推进。
- 汇总组合级容量视图。把各团队的角色缺口按时间段汇总，形成组织层面的容量约束。汇总时保留角色维度，因为不同角色的缺口不能互相抵消。
- 对候选项目排序。按战略价值和投入产出对候选项目排序。价值评估的口径要事先统一，避免排序时各说各话。
- 在容量约束下确定承接清单。从高优先级项目开始分配容量，直到容量用尽，形成承接、延后、缩减三份清单。缩减要写明砍掉的范围，延后要写明重新评估的时间点。
- 设定重排触发条件。容量发生显著变化时重新排序，例如关键角色离职、项目范围大幅变更、战略优先级调整。触发条件事先约定，可以减少临时争论。
ONES 资源和工时管理解决方案支持跨项目团队资源规划，可视化展现成员的项目进度，并可查看项目和团队的资源利用率与负荷度。这些数据可作为组合取舍的输入，帮助管理者看到多个项目对同一批人的占用情况。组合层面的优先级排序与承接决策属于管理判断，需要在团队数据之外结合战略口径确定。
适配场景与选择建议
先做哪一类规划，取决于当前最突出的问题。以下条件可作为判断依据。
当需求波动大、缺口频繁出现，团队经常在交付前才发现人力不够时，优先建立研发资源需求与容量规划。它能把缺口提前暴露，让补人、调范围等动作有提前量。判断是否见效，可以看缺口被识别的时间是否提前、因人力不足导致的交付延期是否减少。
当多个项目争抢同一批人、立项缺乏依据、项目之间频繁互相挤占资源时，优先建立项目组合资源容量规划。它能把取舍放到明面上，减少临时插队。判断是否见效，可以看项目优先级争议是否减少、承接决策是否有可追溯的依据。
两者并行推进时，建议先建立团队级的供需测算，把角色工时和容量口径跑顺，再向上汇总做组合取舍。共用同一套角色定义和工时口径，两个层级的数据才能对接。最小可行做法是先选一个团队、一个季度做试点，用缺口清单和处置记录验证口径，再逐步扩展到组合层面。
需要说明的是，组合层面的容量汇总与项目取舍涉及管理机制设计，工具能提供数据视图和投入分析，决策规则仍需组织自行约定。ONES 在资源规划、跨项目投入查看和利用率分析上的能力，可作为这套流程的数据底座，具体配置方式建议结合实际团队结构评估。
常见问题
团队规模不大，还需要把研发资源需求与容量规划和组合容量规划分开做吗？
规模较小的团队可以把两个层级合并成一次会议完成，但建议保留两层判断的顺序。先按角色算出本周期可承接的工作量上限，再在这个上限内决定接哪些项目。合并操作时容易出现的偏差是直接讨论项目取舍，跳过了供需测算，结果承接清单缺少数量依据。哪怕只有一张按角色列出的可用工时表和一份候选项目清单，也能让取舍有据可依。
需求本身不确定，估算误差很大，容量规划还有意义吗？
有意义，但需要调整做法。把需求分成确定需求和概率性需求两类，确定需求按刚性缺口计算，概率性需求按预期值或区间计入，并标注不确定性。这样缺口清单会呈现为区间而非单点数字，处置方案也可以分层：确定缺口优先补人，概率性缺口先准备预案。复盘环节用实际投入修正估算系数，几轮之后误差会逐步收敛。
容量规划已经算出缺口，为什么不能直接排到人？
可以排，但建议分两步。容量规划阶段确定的是角色级总量边界，此时需求可能还会变化，人员也可能请假或调整。如果在这一步就锁定到人，任何变动都会引发排期返工。更稳妥的顺序是先确认总量边界，再在边界内做具体分配，排期结果反馈实际投入用于校准容量口径。ONES 资源管理支持查看成员每日投入饱和明细，可用于检查排期是否超出容量边界。
组合层面的项目取舍，容量数据能直接给出结论吗？
容量数据给出的是约束条件，取舍结论还需要价值判断。可行做法是先把各团队角色缺口按时间段汇总成组合级容量视图，再按事先统一的战略价值和投入产出口径对候选项目排序，从高优先级开始分配容量直到用尽。容量数据决定“能接多少”，价值排序决定“先接谁”，两者缺一不可。汇总时保留角色维度，不同角色的缺口不能互相抵消。
两个层级的规划多久更新一次比较合适？
团队级供需测算通常随迭代或季度滚动更新，需求变化频繁时可以按迭代刷新。组合层面的排序一般与季度或年度预算、战略周期对齐，更新频率更低。两者之间需要约定重排触发条件，例如关键角色离职、项目范围大幅变更或战略优先级调整，触发后不必等到固定周期即可重新评估。触发条件事先写明，能减少临时争论。
