资源约束下的项目选择，先算清可用容量，再按战略价值与资源占用给候选项目排序，用情景组合验证容量是否够用，最后确定本期承接清单和暂缓清单。核心产物是一张带资源口径的项目选择表：每个候选项目标注所需角色工时、优先级、依赖和可延后性，与可用容量逐项比对后做出取舍。本文覆盖从容量测算到决策确认的完整动作，不展开已选项目之间的人员协调；ONES可用于承载候选项目登记与容量汇总，具体做法在相关章节说明。
要点总览（TL;DR）
- 项目选择从资源侧开始：按角色统计可用人力，扣除休假、运维等固定占用，换算成人天后冻结容量数据。
- 候选项目按统一字段登记，资源需求必须拆到角色工时，并标注依赖、可延后性和估算误差。
- 排序后按角色逐项累加占用，找到先触顶的角色和截断线，形成承接清单与暂缓清单，暂缓项目写明原因和复审时点。
- 用收紧、放宽等情景检验清单稳健性，定义触发重新选择的信号，提前写明顺延预案。
- 选择会结束前逐项核对容量口径、依赖、暂缓说明和确认记录，全部通过才算可执行。
先算可用容量：资源约束下的选择从哪一步开始
项目选择的起点是资源侧的可用容量，先把这个数字算出来，后续排序才有比较基准。凭“大家都很忙”的直觉判断，无法回答“还能再接几个项目”，也无法在多个候选项目之间做取舍。容量测算的目标是产出一张按角色列出的可用容量表，明确统计周期和固定占用扣除项。
具体做法分三步。第一步，按角色或技能分组统计可用人力，例如后端开发、前端开发、测试、产品经理、UI设计等，同一角色内再区分可独立承担任务的人员。第二步，从名义人力中扣除固定占用：休假与法定假期、运维支持与线上问题处理、例行会议与培训、已有承诺项目的占用。扣除后的剩余部分才是本期可分配给新项目的容量。第三步，把剩余容量换算成人天或人周，统一口径，便于与项目需求逐项比对。
容量表建议包含以下字段：
| 字段 | 说明 | 示例口径 |
|---|---|---|
| 角色/技能组 | 按可独立承担任务的能力分组 | 后端开发 |
| 名义可用人力 | 统计周期内可投入的人数 | 6人 |
| 固定占用扣除 | 休假、运维、例行事务等 | 折合12人天 |
| 可投入项目容量 | 扣除后的净容量 | 折合108人天 |
| 统计周期 | 容量对应的时间范围 | 2025年Q3（7—9月） |
| 冻结时点 | 容量数据确认后不再随意变更的日期 | 季度首月第5个工作日 |
统计周期要与项目选择周期一致，按季度选择就按季度算容量，按月滚动就按月算。冻结时点的作用是让后续排序基于同一份数据，避免边排边改导致结论反复。容量表完成后由资源负责人签字确认，作为本期选择的输入。
候选项目清单怎么建：字段与资源估算口径
容量算清后，需求侧要建立一份可比较的候选项目清单。清单的价值在于让每个项目用同一套字段描述，排序时才能横向对比。字段缺失或口径不一，排序就会退化成拍脑袋。
候选项目必填字段包括：项目名称与一句话目标、战略价值说明（对应哪个业务目标或客户承诺）、优先级、所需角色与工时、外部与内部依赖、可延后性（可延后一个季度、可延后半年、不可延后及原因）。其中资源需求必须按角色分别估算，只写一个总人天无法判断关键角色是否超载。例如某项目写“需要120人天”，无法看出后端占80人天还是测试占80人天，而这两者对容量比对的影响完全不同。
估算粒度建议按角色给出人天区间，并标注估算依据和待确认项。早期项目信息不足时，可以给出区间估算并注明“需求待细化，误差约±30%”，同时列出需要澄清的问题。估算误差本身不是问题，隐瞒误差才是问题；把待确认项写进清单，排序时可以对不确定性高的项目留出缓冲。
候选项目清单表示例：
| 项目 | 优先级 | 后端(人天) | 前端(人天) | 测试(人天) | 依赖 | 可延后性 |
|---|---|---|---|---|---|---|
| 项目A | 高 | 40 | 20 | 15 | 无 | 不可延后（合同承诺） |
| 项目B | 中 | 30 | 25 | 10 | 依赖项目A的接口 | 可延后一个季度 |
| 项目C | 中 | 20 | 10 | 8 | 无 | 可延后半年 |
清单建好后，由项目负责人提交估算，资源负责人核对角色口径是否与容量表一致。口径一致是后续累加比对的前提，例如容量表按“后端开发”统计，项目估算就不能混入“架构师”工时而不单独列出。
排序与取舍：在容量内选出本期承接的项目
排序的目标不是给所有项目排出一个完整名次，而是找到本期容量能够覆盖的截断线。操作上分四步：先按综合优先级排序，再逐项累加资源占用，然后与容量比对确定截断线，最后处理超容量和冲突情况，形成承接清单与暂缓清单。
综合排序建议同时看三个维度：战略价值（对业务目标或客户承诺的贡献）、紧迫性（时间窗口和违约风险）、资源占用（人天总量与关键角色占用）。三个维度不必折算成复杂公式，可以用“高/中/低”分级后按规则排序：战略价值高且不可延后的项目排在最前，战略价值相同则资源占用小的优先，以便在同样容量内承接更多项目。排序规则要在选择会前明确并记录，避免会上临时调整标准。
累加比对时按角色分别累加，而不是只加总人天。某角色累计占用超过该角色容量，即使总人天未超，也构成瓶颈。截断线落在哪个项目之后，取决于哪个角色的累计占用先触顶。触顶后，后续项目进入暂缓清单，或调整到下一周期。
超容量和冲突的处理规则可以预先约定：关键角色冲突时，优先保障不可延后项目，可延后项目顺延；存在依赖前置的项目，若前置项目未进入承接清单，后续项目一并暂缓；单个项目占用超过某角色容量一半时，评估是否拆分交付范围。暂缓清单要写明暂缓原因（容量不足、依赖未满足、优先级靠后）和复审时点，例如“下季度容量测算后复审”。
取舍会议的输出是两份清单：本期承接清单，列明项目、承接角色工时和启动时间；暂缓清单，列明项目、暂缓原因和复审时点。两份清单共同构成选择结论，暂缓不等于否决，写明复审时点才能让暂缓项目有明确的回归路径。
情景验证：容量变化时组合怎么调整
基准情景下的承接清单只代表一种容量假设。人员休假集中、关键角色离职、紧急需求插入都会改变可用容量，用两到三个情景检验清单的稳健性，可以提前准备调整预案。
情景设定通常包括三类：基准情景，按容量表原始数据；收紧情景，假设关键角色容量减少一定比例，例如后端减少20%，模拟人员变动或紧急支持占用；放宽情景，假设新增一名关键角色或部分固定占用释放，观察能否多承接项目。每个情景只需调整容量假设，项目需求估算保持不变，便于对照。
观察重点有两个：一是关键角色瓶颈在收紧情景下是否加剧，哪些项目最先需要顺延；二是项目顺延的连锁影响，依赖被顺延项目的后续项目是否也要调整。情景对照结果建议用表格记录：
| 情景 | 容量假设 | 承接项目 | 顺延项目 | 主要瓶颈 |
|---|---|---|---|---|
| 基准 | 后端108人天 | A、B | C | 后端 |
| 收紧 | 后端86人天 | A | B、C | 后端 |
| 放宽 | 后端128人天 | A、B、C | 无 | 测试 |
情景验证还要定义触发重新选择的信号：关键角色实际可用容量低于基准一定比例、出现不可延后的新需求、承接项目范围发生重大变更。信号出现时，按同一套排序和累加规则重新比对，而不是临时插队。调整预案写明“若发生X，则顺延Y项目，保留Z项目”，让调整有据可依。
角色分工与交付物：谁算容量、谁做取舍、谁确认
项目选择涉及三类角色，职责和交接产物要事先明确，否则容易出现容量数据没人认、取舍结论没人拍板的情况。
| 角色 | 职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 资源负责人 | 统计各角色可用容量，扣除固定占用，确认统计周期与冻结时点 | 可用容量表 | 组合管理角色 |
| 项目负责人 | 提交候选项目字段与按角色的资源估算，标注依赖和待确认项 | 候选项目清单 | 组合管理角色 |
| 组合管理角色 | 组织排序与取舍会议，累加比对容量，形成承接与暂缓清单 | 承接清单、暂缓清单、取舍理由 | 决策层 |
| 决策层 | 确认承接清单与暂缓清单，确认情景调整预案 | 决策确认记录 | 资源负责人、项目负责人 |
交接的关键是记录。容量表要有确认人和确认日期；候选项目清单要有估算人和估算依据；取舍会议要有参会人、排序规则和结论；决策确认记录要写明确认的清单版本和生效周期。这些记录在后续复审和情景调整时是追溯依据，也能避免同一项目在不同会议上得到不同结论。
当候选项目数量较多、容量数据分散在多个表格中时，可以用ONES承载候选项目登记和容量汇总：项目负责人按统一字段提交候选项目，资源负责人维护各角色容量数据，组合管理角色在同一处比对承接清单与暂缓清单并留存确认记录。工具承载的是数据和流程，排序规则和取舍判断仍由上述角色完成。
示例：一个季度选择会的完整推演
以下示例为演示情景，数据经过简化，用于说明从容量表到承接清单的推演过程。
某团队选择2025年Q3承接项目。容量表显示：后端可用108人天，前端可用90人天，测试可用60人天，统计周期为7—9月，容量数据在季度首月第5个工作日冻结。候选项目清单有四个项目：
| 项目 | 优先级 | 后端 | 前端 | 测试 | 依赖 | 可延后性 |
|---|---|---|---|---|---|---|
| A | 高 | 40 | 20 | 15 | 无 | 不可延后 |
| B | 高 | 35 | 25 | 12 | 依赖A接口 | 可延后一个季度 |
| C | 中 | 30 | 20 | 10 | 无 | 可延后半年 |
| D | 中 | 25 | 30 | 18 | 无 | 可延后一个季度 |
排序按“战略价值高且不可延后优先，同级按资源占用小优先”的规则：A排第一，B排第二，C与D同级，C资源占用略小排第三，D排第四。逐项累加：承接A后，后端累计40、前端20、测试15；加入B后，后端累计75、前端45、测试27，均在容量内；加入C后，后端累计105、前端65、测试37，后端接近108的上限；再加入D，后端累计130，超过108，截断线落在C之后。本期承接A、B、C，D暂缓，暂缓原因为后端容量不足，复审时点为下季度容量测算后。
情景验证中，收紧情景假设后端容量减少20%至86人天：承接A、B后后端累计75，加入C会达到105，超出86，因此C也顺延，本期只承接A、B；B依赖A接口，A保留使B的依赖满足。放宽情景假设后端新增一名成员、容量增至128人天：A、B、C、D全部可承接，此时测试累计55，接近60的容量上限，测试成为新的瓶颈。调整预案据此写明：若后端容量收紧，顺延C；若容量放宽，承接D前先确认测试排期。
完成检查：选择结果是否可执行
选择会结束后，用以下清单逐项核对，确认结果达到可执行状态再对外发布。
- 容量口径一致：容量表与项目估算使用相同的角色分组，统计周期相同，固定占用扣除项已列明。
- 估算口径一致：每个候选项目按角色给出人天，标注估算依据和待确认项，误差范围已说明。
- 承接清单在容量内：按角色累加后均未超过对应容量，关键角色无超载；截断线位置有明确依据。
- 依赖已检查：承接项目的前置依赖均在承接清单内或已确认满足，暂缓项目不阻塞承接项目。
- 暂缓清单完整：每个暂缓项目写明暂缓原因和复审时点，可延后性字段与暂缓结论一致。
- 情景预案已记录：至少完成收紧与放宽两个情景的对照，触发重新选择的信号已定义。
- 确认记录留存：容量表、候选清单、取舍会议结论和决策确认记录均有确认人和日期，版本可追溯。
清单全部通过，说明本次项目选择形成了可执行的承接清单与暂缓清单；若有条目未通过，回到对应环节补齐数据或重新比对，再提交确认。
常见问题
容量数据该由谁确认，冻结后还能改吗？
容量数据由资源负责人统计并签字确认，确认内容包括角色分组、统计周期、固定占用扣除项和净容量。冻结时点之后，容量数据作为本期排序的统一基准，不随个别项目需要临时调整。
遇到人员变动、紧急支持占用等确实影响容量的情况，按预先定义的触发信号处理：重新测算容量，用同一套排序和累加规则重新比对，并记录调整原因和影响的项目。这样调整有据可查，也能避免会上临时改数导致结论反复。
候选项目信息不足、估算误差很大时，还能进入排序吗？
可以进入排序，前提是把不确定性写清楚。按角色给出人天区间，标注估算依据和待确认项，并说明误差范围，例如“需求待细化，误差约±30%”。排序时对这类项目留出缓冲，或在承接清单中注明需在启动前完成需求澄清。
如果某个项目的关键角色估算区间跨度大到无法判断是否超容量，可以先列入暂缓清单，待估算细化后在下一次比对中重新评估。隐瞒误差比误差本身更影响选择质量。
多个项目同时争抢同一个关键角色，取舍规则怎么定？
先看可延后性：不可延后且有合同或客户承诺的项目优先保障，可延后项目顺延到下一周期。可延后性相同的情况下，按战略价值和资源占用综合排序，资源占用小的项目优先，以便在同样容量内承接更多项目。
如果单个项目占用超过该关键角色容量的一半，可以评估拆分交付范围，把部分功能放到后续周期。取舍规则应在选择会前明确并记录，会上按规则执行，减少逐项争论。
暂缓清单里的项目，什么时候重新评估？
每个暂缓项目都要写明复审时点，常见做法是绑定下一次容量测算，例如“下季度容量测算后复审”。复审时沿用原来的候选项目字段，更新资源估算和依赖状态，再按同一套排序规则重新比对容量。
如果出现触发信号，例如关键角色容量释放、出现新的不可延后需求或项目范围重大变更，可以提前复审。暂缓不等于否决，写明复审时点让项目有明确的回归路径。
情景验证要做几个情景，做到什么程度算够？
至少完成基准、收紧、放宽三个情景。基准情景使用容量表原始数据；收紧情景假设关键角色容量减少一定比例，观察哪些项目最先顺延；放宽情景假设容量增加，观察是否出现新的瓶颈角色。
每个情景只需调整容量假设，项目需求估算保持不变，便于对照。情景对照结果记录承接项目、顺延项目和主要瓶颈，并写明“若发生X，则顺延Y项目”的调整预案。做到能回答容量波动时先动哪个项目，情景验证就达到了目的。
