把资源容量约束纳入项目选择，关键动作是先算清“可用容量”和“候选项目所需容量”两本账，再用容量缺口设定准入条件和排序规则。本文按测算、规则、分工、示例和检查五个环节展开，适用于季度或半年度组合评审前的准备；已选项目之间的人员协调不在本文范围。
要点总览（TL;DR）
- 容量测算按“角色或技能 × 时间窗口”统计可用工时，扣除请假、运维等固定占用后，与候选项目按阶段拆解的角色工时相减，得到各角色缺口。
- 组合层面看瓶颈角色的缺口，而非总工时是否够用；缺口为正表示可承接，缺口为负需排队、拆分范围或补充外部资源。
- 选择规则中，关键角色用硬约束设定准入门槛，一般角色可用加权条件参与排序；规则需写明角色缺口阈值、时间窗口、可调剂资源和例外审批人。
- 资源经理提供可用容量，项目发起人提交需求估算，PMO汇总缺口并组织评审，组合决策层依据缺口取舍并留痕。
- 评审后用检查清单核对口径统一、数据可追溯、规则被执行、决策记录完整和复盘机制运转，判断容量约束是否真正生效。
先算清两本账：可用容量与候选项目所需容量
容量测算要回答一个具体问题：在下一个选择周期内，团队按角色或技能能提供多少工时，候选项目又需要多少工时。两本账用同一时间窗口、同一角色口径统计，相减得到的缺口才能用于决策。
可用容量怎么算
可用容量按“角色或技能 × 时间段”统计，统计对象是能投入候选项目的人，而非全部在册人数。计算时从名义工时中扣除固定占用，得到可分配工时：
- 名义工时：人数 × 周期内工作日 × 每日标准工时。例如某角色3人、一个季度约60个工作日、每日按7小时可投入时间计，名义工时为1260小时。
- 扣除固定占用：已排定的请假与培训、必须维持的运维和支持值班、已承诺项目的延续投入。这些占用在测算前就要锁定，不能留到评审时再临时扣减。
- 扣除合理余量：为突发问题和交接预留一定比例，比例由团队根据历史情况确定，并在规则中写明。
测算结果落到“角色—周期—可用工时”三列，每个数字注明数据来源和确认人，避免评审时对口径产生争议。
候选项目所需容量怎么估
候选项目按阶段或里程碑拆解到角色工时，避免只给一个总数。拆解时至少覆盖需求与设计、开发、测试、上线支持四个阶段，每个阶段标注所需角色、人数和持续周数。估算精度按项目阶段区分：已有方案的项目可按任务清单估算，仅有立项意向的项目用类比估算并标注置信度。每个项目的估算表应包含项目名称、阶段、角色、工时、估算依据和估算人。
缺口计算与示例
缺口等于候选项目所需容量减去可用容量。缺口为正，说明该角色在该周期内还有承接空间；缺口为负，说明容量不足，需要排队、拆分范围或补充外部资源。
| 角色 | 周期可用容量（小时） | 候选项目所需容量（小时） | 缺口（小时） | 判断 |
|---|---|---|---|---|
| 后端开发 | 1260 | 980 | +280 | 可承接 |
| 测试 | 720 | 860 | -140 | 容量不足 |
| 产品经理 | 480 | 420 | +60 | 可承接 |
表中数字为演示情景。可以看到，后端和产品有空间，测试是瓶颈角色。组合层面的缺口要看瓶颈角色，而非总工时是否够用。
统一口径的常见做法
测算中最容易出问题的是口径不一致：有人按人数算，有人按工时算；有人扣了运维，有人没扣；时间窗口一个按自然季度、一个按财季。统一办法是固定一张测算模板，明确工时单位、周期起止日期、角色清单和固定占用清单，所有提交方按模板填写。模板版本变更时通知全部参与方，旧版本数据不进入本轮评审。
当容量数据分散在多个项目团队时，可以用 ONES 的资源规划视图汇总各角色的可用资源和需求，按业务优先级查看资源与需求的匹配情况；工时登记日志也可查询和导出，作为可用容量测算的输入依据。
把容量约束写进项目选择规则
测算出的缺口只有写进选择规则才会影响决策。规则要回答两件事：哪些项目因容量不足不能进入本轮，进入候选的项目按什么顺序排。
硬约束与加权条件的区别
硬约束是准入门槛：关键角色缺口低于设定阈值的项目，本轮不进入实施，直接进入排队或拆分讨论。它适合瓶颈角色少、延期代价高的场景，例如只有一名架构师或一套测试环境。加权条件把容量缺口折算成分数，与其他因素一起排序，适合角色可调剂、项目之间可以错峰的场景。两种方式可以在同一套规则中并用：关键角色用硬约束，一般角色用加权。
规则中必须写明的字段
- 角色缺口阈值：哪些角色是瓶颈角色，缺口低于多少即触发限制。阈值按角色分别设定，并注明依据。
- 时间窗口：规则适用的周期起止日期，以及项目跨周期时如何分段计算。
- 可调剂资源：哪些人员可以在角色之间调剂，调剂需要谁确认，调剂后容量如何重算。
- 例外处理：战略项目或合规项目需要突破容量限制时，由谁审批、需要补充什么资源承诺。
排序时的容量调整方法
排序先看瓶颈角色的缺口大小：缺口越小的项目越容易在本周期内完成，可优先安排。缺口相近时，看关键角色的稀缺程度，占用稀缺角色少的项目优先。对缺口为负的项目，排序结果要附带处理方式：推迟到下一周期、拆分范围只做第一期、或申请外部资源。处理方式与项目绑定，不能只写“待定”。
审批与复核
选择规则由组合决策层审批，PMO 或组合管理者维护。复核周期与评审周期一致，每轮评审前检查阈值是否仍然适用，角色清单是否变化。规则调整要记录调整原因和生效日期，避免同一周期内规则反复变动。
角色分工与各环节交付物
容量测算和选择决策由不同角色完成，职责不清会导致测算数据与决策依据脱节。下表按输入、动作、输出明确各方职责。
| 角色 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 资源经理/职能经理 | 人员名单、请假与培训计划、运维值班安排、已承诺项目投入 | 按角色和周期测算可用工时，标注固定占用 | 可用容量表，注明数据来源和确认时间 |
| 项目经理/项目发起人 | 项目范围、阶段计划、角色需求 | 按阶段拆解所需角色工时，标注估算依据和置信度 | 候选项目资源需求估算表 |
| PMO/组合管理者 | 可用容量表、各项目需求估算、选择规则 | 汇总缺口，组织评审，维护规则版本 | 组合容量缺口汇总表、评审议程、规则说明 |
| 组合决策层 | 缺口汇总、排序结果、例外申请 | 依据缺口做取舍，确认暂缓项目的处理方式 | 决策记录，含取舍理由和责任人 |
分工确定后，测算表与决策记录要能相互追溯：每条决策记录引用对应的缺口数据版本，缺口数据变更时同步通知决策层。ONES 的文档与工作项可以承载容量汇总表和评审记录，把测算依据与决策结论放在同一处，便于后续复盘时对照。
一个组合评审的完整示例
以下为演示情景，数字用于说明计算过程，不代表真实项目数据。
背景：某团队下一季度有三个候选项目，关键角色为后端开发和测试。季度可用容量经测算：后端开发1260小时，测试720小时。三个项目的需求估算如下：
| 候选项目 | 后端开发需求（小时） | 测试需求（小时） | 说明 |
|---|---|---|---|
| 项目A：客户门户改版 | 520 | 380 | 范围明确，测试工作量大 |
| 项目B：内部报表优化 | 300 | 180 | 可拆分，第一期范围较小 |
| 项目C：数据接口升级 | 440 | 300 | 依赖外部系统，时间弹性大 |
缺口计算：三个项目合计后端需求1260小时，恰好等于可用容量，缺口为0；测试需求合计860小时，超出可用容量140小时，缺口为-140。测试是瓶颈角色。
排序与取舍：按测试缺口从小到大排，项目B测试需求180小时，占用最少，优先纳入；项目A测试需求380小时，纳入后测试剩余容量为160小时，不足以承接项目C的300小时。项目C测试缺口为-140小时，本轮暂缓。最终选择项目A和项目B，测试合计占用560小时，留有余量。
暂缓项目的处理：项目C推迟到下一季度，同时评估将部分测试工作前移到开发阶段自测，或申请外部测试资源。处理方式写入决策记录，下一轮评审时重新测算。
这个示例说明：总工时看似平衡时，瓶颈角色仍可能卡住项目。评审时要按角色看缺口，不能只看项目总数或总工时。
完成检查：容量约束是否真正生效
评审结束后，用以下清单逐项核对，判断容量约束是否真正进入了选择过程，而非停留在测算表里。
- 测算口径统一：所有可用容量和需求估算使用同一模板、同一周期、同一角色清单，工时单位和扣除项一致。
- 数据可追溯：每个容量数字有来源和确认人，需求估算标注了依据和置信度，测算表有版本号。
- 规则明确且被执行：选择规则写明了瓶颈角色、缺口阈值、时间窗口和例外审批人；本轮被暂缓的项目能对应到具体规则条款。
- 决策记录完整：每条取舍记录包含缺口数据、排序结果、暂缓项目的处理方式和责任人，决策层已确认。
- 复盘机制运转：周期结束后对比实际投入与测算值，偏差超过设定范围时分析原因，并反馈到下一轮的容量测算和阈值设定中。
如果清单中有项目无法核对，说明容量约束还停留在参考信息层面。补齐测算依据和决策记录，下一轮评审再把容量条件作为准入和排序的实际依据。
常见问题
容量测算时，可用容量应该按人数算还是按工时算？
建议按工时算，并按角色或技能分别统计。按人数算无法反映兼职、请假、运维值班等占用差异，也无法与候选项目的工时需求直接相减。具体做法是：先算名义工时（人数 × 周期内工作日 × 每日可投入工时），再扣除已排定的请假与培训、必须维持的运维和支持值班、已承诺项目的延续投入，以及团队约定的合理余量，得到可分配工时。每个数字注明数据来源和确认人，避免评审时对口径产生争议。
如果总工时够用，但某个关键角色不够，项目还能选吗？
组合层面要看瓶颈角色的缺口，而非总工时是否够用。如果关键角色缺口为负，即使总工时有余，相关项目也可能因该角色无法到位而延期。处理方式有三种：推迟到下一周期、拆分范围只做第一期、或申请外部资源补充该角色。选择规则中应把瓶颈角色设为硬约束或加权条件，并在决策记录中写明缺口依据和处理方式。
容量约束写成硬约束好，还是加权条件好？
取决于角色稀缺程度和延期代价。瓶颈角色少、延期代价高的场景（例如只有一名架构师或一套测试环境），适合用硬约束设定准入门槛，缺口低于阈值即不进入本轮实施。角色可调剂、项目之间可以错峰的场景，适合把容量缺口折算成分数，与其他因素一起加权排序。两种方式可以在同一套规则中并用：关键角色用硬约束，一般角色用加权。
容量测算的数据分散在多个团队，怎么汇总和追溯？
先固定一张测算模板，明确工时单位、周期起止日期、角色清单和固定占用清单，所有提交方按模板填写，模板版本变更时通知全部参与方。汇总时保留每个数字的来源和确认人，测算表标注版本号。当数据分散在多个项目团队时，可以用 ONES 的资源规划视图汇总各角色的可用资源和需求，按业务优先级查看匹配情况；工时登记日志也可查询和导出，作为可用容量测算的输入依据。
评审结束后，怎么判断容量约束真的影响了项目选择？
用检查清单逐项核对：测算口径是否统一（同一模板、同一周期、同一角色清单）；数据是否可追溯（每个数字有来源和确认人，测算表有版本号）；规则是否明确且被执行（瓶颈角色、缺口阈值、时间窗口和例外审批人写清楚，被暂缓项目能对应到具体条款）；决策记录是否完整（包含缺口数据、排序结果、暂缓项目处理方式和责任人）；复盘机制是否运转（周期结束后对比实际投入与测算值，偏差超过设定范围时分析原因并反馈到下一轮测算和阈值设定）。如果清单中有项目无法核对，说明容量约束还停留在参考信息层面。
