资源约束决策要回答的是：在有限人力下，这一期能承接哪些项目、哪些需要延后。做法分四步：先按角色盘点可用容量，再把候选项目折算成按角色和时间段的需求，用统一优先级排序并与容量上限比对，最后形成带条件的立项结论和决策记录。本文覆盖立项取舍这一段，已选项目之间的人员协调不在范围内。
要点总览（TL;DR）
- 资源约束决策的第一步是得到按角色、按时间段的可用容量基线：从名义工时中扣除运维支持、非项目事务和已承诺项目占用，口径固定后不再反复修改。
- 把候选项目折算成角色×时间段的需求清单，稀缺技能角色单独标注，需求给出区间和置信度，再与容量表逐格相减得到供需对照。
- 排序使用事先约定的统一标准（价值、时限、依赖、风险），按分数累加需求直到触发容量上限，超出部分按调时间、缩范围、换资源、延后的顺序处理。
- 对需求不确定或稀缺角色紧张的项目采用条件式立项，写明可验证的约束条件和复核时点，并保留包含容量基线版本与裁剪理由的决策记录。
先算清可用容量：资源约束决策的起点
容量盘点的目标是得到一张“按角色、按时间段”的可用容量基线表。它回答的是：未来一个季度或一个月内，每个角色真正能投入到新项目上的工时有多少。这张表是后续所有取舍的计算基础，口径一旦松动，后面的排序和裁剪都会失去依据。
按角色统计，而不是按人头统计
按人头统计会把不同技能的人混在一起，得出“总人力够用”的错误结论。正确做法是先划分角色，例如后端开发、前端开发、测试、产品经理、UI设计、数据工程师，再分别统计每个角色的人数与可投入工时。同一角色内部如果技能差异明显，例如测试中区分自动化测试与性能测试，可以继续拆分子角色。
从名义人力扣到可投入容量
名义人力是编制上的可用工时，可投入容量是扣掉各类占用后的剩余部分。计算时至少扣除三类占用：
- 日常运维与支持：线上问题处理、客户支持、例行巡检等，通常按历史占比估算，例如每人每月扣除20%–30%。
- 已承诺项目占用：已经立项、正在执行的项目对本角色的工时需求，按剩余阶段逐月分摊。
- 非项目事务：招聘面试、培训、内部会议、休假等，按人均固定比例扣除。
计算公式可以写成：某角色某月可投入容量 = 该角色人数 × 人均可用工时 ×（1 − 运维支持占比 − 非项目事务占比）− 已承诺项目占用工时。各项占比应来自历史工时记录，而不是凭感觉设定。
确定时间粒度
容量基线的时间粒度建议与决策周期一致。季度决策用月度粒度，月度排期用周粒度。粒度太粗会掩盖阶段性高峰，太细则估算成本过高。对存在明显交付节点的项目，可以在月度基线上再标注关键月份的高峰需求。
下表是一张可直接套用的容量基线表结构，数值为演示数据：
| 角色 | 人数 | 月份 | 名义工时（人时） | 运维与支持扣除 | 非项目事务扣除 | 已承诺项目占用 | 可投入容量 |
|---|---|---|---|---|---|---|---|
| 后端开发 | 8 | 4月 | 1120 | 280 | 112 | 400 | 328 |
| 前端开发 | 5 | 4月 | 700 | 140 | 70 | 260 | 230 |
| 测试 | 4 | 4月 | 560 | 112 | 56 | 200 | 192 |
这张表完成后，容量侧的数据就固定下来，后续讨论不再反复修改口径，除非出现人员变动或已承诺项目范围变化。
把候选项目折算成资源需求
有了容量基线，下一步是把候选项目清单转成同一口径的资源需求：每个项目在每个时间段需要哪些角色、各多少工时。笼统的“人力紧张”无法支撑取舍，只有折算到角色和时间段，才能与容量表逐格对照。
按角色和阶段拆解需求
一个项目在不同阶段的角色需求差异很大。需求分析与设计阶段以产品和设计角色为主，开发阶段集中在前端、后端，测试阶段集中在测试角色。拆解时按项目阶段列出每个角色的人时需求，并标注需求发生的时间段。对于跨季度项目，按月度分摊，避免把全部需求压在立项当月。
单独标注稀缺技能角色
某些角色人数少、外部替代困难，例如架构师、数据工程师、安全工程师。这类角色的需求要在清单中单独标注，即使总工时看起来够用，稀缺角色一旦超载，项目同样无法按期推进。标注方式可以是在需求清单中增加“是否稀缺角色”一列，并在容量比对时优先检查这些行。
给出区间与置信度
早期项目的需求估算很难精确。建议每个需求给出区间，例如“后端开发120–160人时”，并标注置信度：高（已有详细方案）、中（有类似项目参考）、低（仅有初步设想）。置信度低的需求在排序时应保留更大余量，或在立项结论中写明“需求待细化后复核”。
需求清单的推荐字段如下：
| 项目 | 阶段 | 角色 | 时间段 | 需求工时（区间） | 是否稀缺角色 | 置信度 |
|---|---|---|---|---|---|---|
| 项目A | 开发 | 后端开发 | 5月 | 200–240 | 否 | 中 |
| 项目A | 测试 | 测试 | 6月 | 120–150 | 否 | 中 |
| 项目B | 设计 | 数据工程师 | 5月 | 80–100 | 是 | 低 |
与容量表对齐
把需求清单按“角色×时间段”汇总，与容量基线表逐格相减，得到每个角色每个月的缺口或余量。这一步的产物是一张供需对照表，它直接显示哪些格子已经超载、哪些还有空间。供需对照是排序和裁剪的事实依据，讨论应围绕这张表展开。
当候选项目较多、角色和时间段交叉复杂时，把容量基线与项目需求放在同一套工作项体系中维护，可以减少手工汇总的误差。ONES 的资源规划视图支持按业务优先级安排团队资源，资源报表和成员投入饱和明细可用于核对供需对照结果；具体使用方式以组织现有配置为准。
统一优先级口径，再做组合取舍
供需对照表会显示总需求超过容量的角色和时间段。此时需要一套统一的优先级标准决定谁上谁下，避免按部门声量或立项先后做判断。
优先级标准的构成
建议从四个维度打分，并事先约定权重：
- 价值：预期收入、成本节约、客户影响或战略贡献，用可比较的口径描述，例如合同金额区间或覆盖客户数。
- 时限：是否存在外部截止日期，例如合同约定交付、监管要求、市场窗口。
- 依赖：是否被其他项目依赖，或依赖其他项目的产出，延后是否会连锁影响。
- 风险：技术与需求不确定性，风险高的项目在同等价值下应保留更多缓冲。
四个维度加权后得到每个项目的优先级分数。权重应在决策前确定并记录，同一轮决策内不因个别项目调整。
排序后与容量上限比对
按分数从高到低排列候选项目，依次把每个项目的角色需求累加到供需对照表上。当某个角色某个时间段累计需求超过可投入容量时，该位置即为容量上限的触发点。继续累加会得到一条“容量线”，线以上的项目进入初选，线以下的项目进入待定。
超出容量时的裁剪与延后规则
裁剪不是简单砍掉分数最低的项目，可以按以下顺序处理：
- 先看能否调整时间：把项目整体后移一个时间段，避开峰值月份，需求不变但错开冲突。
- 再看能否缩减范围：把项目拆成两期，首期只交付核心功能，降低当期角色需求。
- 再看能否替换资源：用非稀缺角色承担部分工作，或引入外部资源，但需评估技能匹配与成本。
- 最后才做延后或取消：对分数低且无法调整的项目，明确延后到哪个时间段，并记录再评估条件。
条件式立项
对进入初选但需求置信度低或存在稀缺角色压力的项目，可以采用条件式立项：批准立项，同时写明约束条件，例如“后端开发需求不超过220人时”“数据工程师在5月前到位”“需求细化后复核一次”。约束条件应可验证，并指定复核时点。这样既不让项目空等，也不让容量在无人察觉的情况下被突破。
角色分工与决策交付物
资源约束决策涉及三类角色，各自提供不同输入、做出不同判断。分工不清会导致数据口径混乱或决策无人负责。
三类角色的分工
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 资源负责人（各团队负责人） | 提供本团队按角色的可用工时、已承诺占用与运维支持占比，确认容量基线 | 容量基线表 |
| 项目负责人 | 提供候选项目的角色需求、时间段、置信度与优先级评分依据 | 项目资源需求清单 |
| 组合决策者（如研发负责人或PMO） | 确认优先级权重，主持排序与裁剪，批准立项结论与约束条件 | 决策记录与立项结论 |
决策记录应包含的字段
每次决策留下一份可追溯的记录，至少包含：决策日期与决策周期、参与人与各自角色、容量基线版本、候选项目清单及优先级分数、容量触发点位置、裁剪与延后清单及理由、条件式立项的约束条件与复核时点、下次再评估的触发条件。记录的作用是让后续复核有据可查，也让未入选项目知道自己在什么条件下可以重新进入。
评审时点与频次
建议与规划周期同步：季度决策每季度一次，月度排期每月一次轻量复核。出现以下情况时应触发临时评审：关键角色人员变动、已承诺项目范围重大变化、新增高优先级候选项目、条件式立项的约束条件被突破。临时评审只调整受影响的部分，不重做全量排序。
一个完整的决策示例
以下为演示情景，用于串联前述步骤，数据为虚构。
某研发组织有后端开发6人、前端开发4人、测试3人，决策周期为第二季度。按容量基线表计算，4月后端可投入容量为240人时，前端为180人时，测试为140人时；5月后端为220人时，前端为170人时，测试为130人时。
候选项目有三个：项目甲为合同约定6月交付的客户项目，优先级分数最高；项目乙为内部平台升级，价值中等但被项目甲依赖；项目丙为新业务探索，价值高但置信度低。需求清单显示：项目甲4月需后端180人时、5月需后端160人时；项目乙4月需后端100人时；项目丙5月需后端120人时、数据工程师80人时。
累加后，4月后端需求为280人时，超过容量240人时，触发容量上限。按裁剪规则处理：项目乙是项目甲的前置依赖，不能延后，但可以缩减范围，首期只做接口层，4月需求降至60人时；项目丙整体后移至6月启动，避开4月峰值。调整后4月后端需求为240人时，正好等于容量，5月后端需求为160人时，留有60人时余量。
最终结论：项目甲正常立项；项目乙条件式立项，约束为“4月后端投入不超过60人时，接口层完成后复核剩余范围”；项目丙延后至6月，再评估条件为“5月底后端余量不低于80人时且数据工程师到位”。决策记录中写明容量基线版本、触发点位置和复核时点。
完成检查：决策是否站得住
决策完成后，用以下清单逐项核对。任一项不通过，应回到对应步骤补充数据或修正结论。
| 检查项 | 通过标准 | 对应步骤 |
|---|---|---|
| 容量数据来源与口径一致 | 各角色使用同一套扣除比例和工时口径，数据有历史记录支撑 | 容量盘点 |
| 需求覆盖关键稀缺角色 | 稀缺角色单独列出并参与供需比对，未因总量够用而被忽略 | 需求折算 |
| 优先级标准事先约定 | 权重与评分依据在决策前确定，本轮内未临时调整 | 排序取舍 |
| 裁剪结论有再评估条件 | 每个延后或缩减的项目都写明触发再评估的具体条件 | 排序取舍 |
| 条件式立项的约束可验证 | 约束条件有明确数值或时点，并指定复核人 | 排序取舍 |
| 决策记录可追溯 | 记录包含容量基线版本、参与人、裁剪理由与复核时点 | 角色分工 |
这张清单也可以作为下一次决策的准备检查：在开会前确认容量基线和需求清单已按上述标准准备好，可以减少评审中的反复。决策记录与容量基线应归档保存，便于下一周期对比口径变化，判断是容量真实变化还是估算偏差。
常见问题
容量基线应该多久更新一次，什么情况下需要临时重算？
常规更新与决策周期同步：季度决策每季度重算一次，月度排期每月做一次轻量复核。出现以下情况时应临时重算受影响角色的容量：关键角色人员入职或离职、已承诺项目范围发生重大变化、运维支持占比明显偏离历史水平。临时重算只调整受影响的角色和时间段，不必推翻整张基线表，但要在决策记录中注明基线版本的变化，便于下一周期对比是容量真实变化还是估算偏差。
候选项目需求估算置信度低，还能进入本轮排序吗？
可以进入排序，但处理方式不同。置信度低的需求按区间上限参与累加，并在结论中标注“需求细化后复核”；如果该项目进入初选，优先采用条件式立项，把复核时点写进约束条件。若低置信度项目占用的恰好是稀缺角色，建议先做一次小范围需求澄清再排序，避免用粗略数字挤掉需求明确的项目。
多个项目同时争抢同一个稀缺角色，裁剪规则怎么落地？
先把该稀缺角色的供需对照单独拉出来，确认缺口发生在哪个月份、缺多少。然后按优先级分数从高到低依次满足，分数相近时优先保障有外部截止日期的项目。对无法当期满足的项目，依次尝试整体后移、拆分首期范围、用相近技能角色分担部分工作。每一步调整都要回到供需对照表验证缺口是否真的消除，并在决策记录中写明被调整项目的新时间点和再评估条件。
条件式立项的约束条件被突破时，应该怎么处理？
约束条件被突破属于临时评审的触发情形。处理时先确认突破的性质：是需求估算偏低，还是执行中范围扩大。前者需要重新估算并判断是否仍在容量内，后者需要走范围变更确认。无论哪种，都应回到本轮决策的容量基线版本上重新比对，决定是压缩其他项目、追加资源，还是把该项目部分范围延后。处理结果补充进原决策记录，保持同一条决策链可追溯。
决策记录需要保存多久，后续怎么用？
建议至少保留最近四个决策周期的记录，与对应版本的容量基线一起归档。它的用途有三个：下一周期对比口径变化，判断容量波动来自人员变动还是估算偏差；未入选项目申请重新进入时，核对当初写明的再评估条件是否已满足；复盘时检查优先级权重和裁剪规则是否需要调整。记录不必很长，但容量基线版本、参与人、裁剪理由和复核时点这几项要完整。
