资源约束决策要回答的是组合层面“接哪些、缓哪些、放弃哪些”。做法是把候选项目的资源需求按角色和技能折算成工时或人天，盘点可用容量并留出缓冲，算出缺口后按价值、时间窗口和依赖排序，用两三个情景比较取舍结果，最后形成有负责人、有依据、可复核的承接清单与决策记录。决策过程可以在工作管理工具中登记和留痕，ONES 的相关能力会在最后一节说明。
要点总览（TL;DR）
- 资源约束决策按五步推进：需求折算、容量盘点、缺口计算、情景比较、承接确认，每步都有输入、动作、输出和完成标志。
- 需求侧按角色、技能、阶段拆分，统一折算为工时或人天，标注假设、置信度和复核人，稀缺技能单独成行。
- 供给侧从在岗人力中扣除休假、培训、运维等固定占用，按技能维度汇总，并设置组合级缓冲，区分稳定容量与临时可借用容量。
- 情景比较至少给出基准、压缩、延后两到三个方案，比较交付时间、缺口和风险，并写明每个情景成立的前提假设。
- 决策产出是一份可复核的记录：承接清单、延后或放弃项目、取舍理由、负责人、时间窗口和重评触发条件。
资源约束决策的核心步骤：从需求盘点走到承接清单
资源约束决策可以拆成五步，每一步都有明确的输入、动作、输出和完成标志。五步走完，决策会得到一份承接清单和一份记录，而不是一次口头拍板。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 需求折算 | 候选项目清单、范围说明、初步排期 | 按角色、技能、阶段拆解资源需求，统一折算为工时或人天 | 项目资源需求表 | 每个候选项目的需求可按角色汇总，假设与置信度已标注 |
| 2. 容量盘点 | 在岗人员名单、考勤与占用数据、技能标签 | 扣除休假、培训、运维等固定占用，按技能维度汇总，设定组合级缓冲 | 可用容量盘点表 | 每个技能方向有可用容量数字和缓冲比例说明 |
| 3. 缺口计算 | 需求表、容量表 | 按角色和技能对齐需求与供给，计算缺口与富余 | 需求供给缺口表 | 缺口能定位到具体技能和时间段 |
| 4. 排序与情景 | 缺口表、项目价值依据、依赖关系 | 按战略价值、时间窗口、依赖排序，形成基准、压缩、延后等情景并比较 | 情景对比表与推荐情景 | 每个情景的交付结果、缺口和风险可比较 |
| 5. 承接确认 | 推荐情景、决策会意见 | 确认承接清单、延后或放弃项目、重评触发条件 | 资源约束决策记录 | 承接项目有负责人和时间窗口，取舍理由对应到具体约束 |
五步的顺序有依赖关系：需求口径不统一，缺口就算不准；容量不扣固定占用，缺口会被低估；没有情景比较，排序容易变成部门之间的博弈。实际执行时可以在一步内反复修正，但不要跳过任何一步直接进入拍板。
需求侧怎么估：把项目资源需求折算成可比口径
不同项目对“需要多少人”的描述往往口径不一，有的按人头，有的按阶段，有的只写“需要前端支持”。需求侧的任务是把这些描述统一成可比较的字段，让组合层面的加总成为可能。
建议每个候选项目按以下字段填写需求：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 项目与阶段 | 标明项目名称和需求所属阶段 | 会员系统改造 / 开发阶段 |
| 角色 | 按实际承担工作的角色填写 | 后端开发、测试、产品 |
| 技能 | 标注关键技能，稀缺技能单独列出 | 后端开发（支付网关经验） |
| 工作量 | 统一折算为工时或人天，注明折算依据 | 120 人天，按历史同类项目均值折算 |
| 时间窗口 | 需求发生的起止时间 | 第 2 季度第 1–8 周 |
| 假设 | 估算依赖的前提 | 复用现有支付组件，不含联调返工 |
| 置信度 | 高、中、低，并说明原因 | 中：需求范围尚未冻结 |
| 复核人 | 对估算负责的人 | 项目负责人与对应技术负责人 |
填写时有两个容易出错的点。一是只按角色汇总而忽略技能：同样是后端开发，具备特定中间件或领域经验的人可能只有一两位，这类稀缺技能要单独成行，不能混在角色总量里。二是把估算当成确定值：置信度低的项目应在情景比较中单独标注，必要时按区间估算，避免一个未经复核的数字直接进入承接清单。
完成标志是：所有候选项目的需求都能按角色和技能加总，每个数字背后有假设和复核人，组合层面可以直接与容量对照。
供给侧怎么盘：可用容量与缓冲的确定方法
可用容量不等于在岗人数乘以工作日。把名义人力直接当作可用容量，是资源约束决策中最常见的偏差来源。
可用容量的计算口径建议分三层：
- 名义人力：在岗人员数量与合同工时。
- 可支配容量：从名义人力中扣除休假、培训、例会、值班运维等固定占用后，真正能投入项目的时间。
- 组合可用容量：在可支配容量基础上再扣除组合级缓冲，作为承接项目的实际上限。
缓冲比例的设定要有依据，常见依据包括：历史需求变更导致的返工比例、线上问题处理的平均占用、新人上手期的效率折损。缓冲不是越多越安全，比例过高会让组合承接能力被低估，比例过低则一次突发问题就会挤占交付。建议在首次盘点时用过去两三个季度的实际数据反推，之后按季度复核。
容量要按技能维度汇总，而不是只按人数。一个十人的后端团队，如果其中只有两人具备某项关键技能，那么该技能的可用容量就是这两人的可支配时间，而不是十人的总和。同时要区分稳定容量与临时可借用容量：前者是团队长期可依赖的投入，后者来自其他团队的短期支援或外部资源，在情景比较中应单独标注，不能默认其可持续。
完成标志是：每个技能方向都有可支配容量数字、缓冲比例及其依据，稳定容量与临时容量分开列示。
情景评估：用两到三个方案比较取舍结果
只给决策者一个方案，讨论很容易变成“行或不行”的表态。给出两到三个情景，讨论才能落到“在什么条件下交付什么结果”。
常见的情景设定：
| 情景 | 设定方式 | 比较重点 |
|---|---|---|
| 基准情景 | 按现有容量和优先级承接，不做额外调整 | 哪些项目能按期交付，哪些出现缺口 |
| 压缩情景 | 优先保障高价值项目，压缩或暂停低优先级项目 | 高价值项目的交付时间提前多少，被压缩项目的代价是什么 |
| 延后情景 | 将部分项目整体后移一个时间窗口 | 缺口是否消除，延后对时间窗口和依赖方的影响 |
每个情景都要比较三类结果：交付时间、资源缺口、风险。交付时间看关键项目的完成节点；资源缺口看剩余缺口集中在哪些技能和时间段；风险看情景成立所依赖的假设，例如“压缩情景成立的前提是低优先级项目可以暂停且不影响合同约定”。前提假设要写在情景旁边，假设不成立时该情景的结论也随之失效。
推荐情景的选择依据是战略价值与约束的匹配程度，而不是缺口最小的方案。缺口最小往往意味着承接项目最少，可能牺牲了时间窗口紧迫的高价值项目。推荐情景确定后，要同时记录被放弃的选项及其原因，这部分内容在后续复盘和重评时同样重要。
角色分工与交付物：谁估、谁盘、谁决策
资源约束决策脱节，通常不是方法问题，而是估算的人不参与决策、决策的人看不到估算依据。明确角色和交接物可以减少这类断裂。
| 角色 | 职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 项目负责人 | 提供本项目的资源需求估算、优先级依据和时间窗口 | 项目资源需求表 | 组合管理者 |
| 资源负责人 | 提供各技能方向的可用容量、固定占用和临时可借用资源 | 可用容量盘点表 | 组合管理者 |
| 组合管理者 | 汇总缺口、组织情景比较、主持决策会、维护决策记录 | 缺口表、情景对比表、决策记录 | 决策层 |
| 决策层 | 确认承接清单、延后或放弃项目、重评触发条件 | 签认的决策记录 | 组合管理者与各项目负责人 |
分工的关键在于复核环节：需求估算由项目负责人提出，但应有技术负责人或资源负责人复核，尤其是稀缺技能的需求。容量数据由资源负责人维护，组合管理者在使用前应确认数据的时间口径一致。决策层的职责是确认取舍，而不是替代前三个角色重新估算。
示例：一次季度组合资源约束决策的完整过程
以下为演示情景，数字用于说明方法，不代表任何组织的真实数据。
背景与候选项目。某研发组合下一季度有四个候选项目：A 支付渠道接入（时间窗口紧迫，有合同约定）、B 会员体系改造（战略价值高，范围未冻结）、C 内部报表平台（价值中等，可延后）、D 移动端性能优化（价值中等，依赖 A 的部分组件）。
需求与容量缺口。按角色和技能折算后，四个项目合计需要后端开发 260 人天、测试 90 人天，其中“支付网关经验”这一稀缺技能需要 60 人天。容量盘点显示：后端可支配容量 200 人天，扣除 15% 组合缓冲后可用 170 人天；测试可用 80 人天；具备支付网关经验的仅两人，可支配容量合计 40 人天。缺口为后端 90 人天、测试 10 人天、稀缺技能 20 人天。
情景比较与取舍。基准情景下四个项目全部承接，后端缺口 90 人天，A 和 B 均无法按期。压缩情景优先保障 A 和 B，暂停 C、D 部分范围后移，后端缺口降至 20 人天，稀缺技能缺口仍为 20 人天，需外部支援或调整 A 的范围。延后情景将 B 整体后移一个季度，缺口基本消除，但 B 的战略价值兑现推迟。最终选择压缩情景，同时确认稀缺技能缺口通过一名外部顾问在第一个月支援解决，C 延后至下季度，D 缩减为仅做与 A 相关的部分。
决策记录的关键字段。记录包含：承接清单（A、B、D 缩减版）、延后项目（C）、取舍理由（对应到后端与稀缺技能缺口）、各项目负责人与时间窗口、情景成立的前提（外部顾问按期到位、B 的范围在第二周冻结）、重评触发条件（外部顾问未到位或 B 范围扩大超过 20% 时重新评估）。
完成检查：决策记录是否可复核、可执行
决策会结束后，用以下清单逐项核对，判断本次决策是否达到可执行标准：
- 需求与容量是否使用同一时间口径和同一工作量单位，折算假设是否写在记录中。
- 稀缺技能是否单独列出，其缺口是否有明确的解决方式。
- 每个被延后或放弃的项目，理由是否对应到具体的角色、技能或时间缺口，而不是笼统的“资源不足”。
- 承接清单中每个项目是否有负责人、时间窗口和范围说明。
- 推荐情景的前提假设是否写明，假设失效时由谁发起重评。
- 重评触发条件是否具体可判断，例如“关键人员离职”“范围扩大超过约定比例”“外部支援未按期到位”。
- 决策记录是否可被未参会的人读懂，并追溯到需求表和容量表。
清单中任何一项无法确认，说明决策还停留在口头层面，需要补充后再发布承接清单。
用工具承载决策过程：需求、容量与结论留痕
资源约束决策涉及多轮数据汇总和一次正式取舍，靠表格邮件往返容易丢失版本。把候选项目、资源需求、容量数据和决策结论放在同一套工作管理工具中，可以让每次重评都有据可查。
在 ONES 中，可以把候选项目与资源需求作为工作项统一登记，用统一字段记录角色、技能、工作量、时间窗口和置信度，使组合层面的加总不必依赖人工合并多张表格。ONES 资源管理提供资源规划视图，管理者可以按业务优先级安排和计划团队资源，并通过甘特视图查看成员排期、按筛选与分组掌握成员在不同项目的投入比重；资源利用率与负荷度、成员每日投入饱和明细可用于识别规划风险。这些视图依赖成员工时与任务数据的持续录入，容量盘点的准确性取决于基础数据的完整程度。
决策结论、情景假设和取舍理由适合放在文档中留痕，并与对应项目关联，使承接清单、延后项目和重评触发条件可以随项目状态一起被追踪。重评触发条件可以对应到工作项状态或提醒机制，在条件变化时提醒组合管理者发起复核。按技能维度汇总容量、组合级缓冲设定和多情景模拟是否能在工具内直接完成，现有资料未作说明，选型时可向厂商确认，必要时先用字段和视图组合实现。
常见问题
候选项目很多、需求估算来不及细做时，怎么保证决策还能按期进行？
可以按项目分层处理：时间窗口紧迫或战略价值高的项目做完整估算，其余项目先按区间估算并标注置信度低。进入情景比较时，把低置信度项目单独列出，说明其数字可能在什么范围内变化，以及变化后是否影响承接结论。这样决策仍能按期形成，同时把不确定性写在记录里，等估算细化后再触发一次复核。
组合级缓冲设多少合适，设了缓冲是不是就等于少接项目？
缓冲比例建议用过去两三个季度的实际数据反推，参考需求变更返工比例、线上问题处理占用和新人上手效率折损。缓冲的作用是让承接清单在遇到常见波动时仍能兑现，比例过高会低估组合承接能力，比例过低则一次突发问题就会挤占交付。缓冲比例应随季度复核调整，并在决策记录中写明依据。
决策会上各方对优先级判断不一致，怎么让讨论回到约束本身？
把讨论从“哪个项目更重要”转到“在给定容量下不同取舍各自交付什么”。用基准、压缩、延后三个情景分别列出交付时间、剩余缺口和风险，让每个主张对应到一个具体情景和它的前提假设。组合管理者的职责是保证情景数据口径一致，决策层确认取舍结论，而不是在会上重新估算。
承接清单发布后，什么情况下需要重新做一次资源约束决策？
重评触发条件要在决策记录中写具体，例如关键稀缺技能人员离职、外部支援未按期到位、项目范围扩大超过约定比例、时间窗口发生变更。条件触发后由记录中指定的责任人发起复核，复核可以只针对受影响的项目和技能方向，不必每次重跑全部五步。
资源约束决策的过程和结论怎么在工具里留痕？
在 ONES 中，可以把候选项目与资源需求作为工作项统一登记，用统一字段记录角色、技能、工作量、时间窗口和置信度；ONES 资源管理提供资源规划视图，支持按业务优先级安排团队资源，并通过甘特视图查看成员排期、按筛选与分组掌握成员在不同项目的投入比重，资源利用率与负荷度、成员每日投入饱和明细可用于识别规划风险。决策结论、情景假设和取舍理由适合放在文档中留痕并与项目关联，重评触发条件可对应到工作项状态或提醒机制。按技能维度汇总容量、组合级缓冲设定和多情景模拟能否在工具内直接完成，现有资料未作说明，选型时可向厂商确认。
