资源约束下的项目选择，关键是把“能承接多少”先算清楚，再按战略贡献与资源占用比排序，用明确规则决定进入、排队或放弃。本文给出一套可执行流程：容量基线、需求估算、排序准入、角色分工与完成检查，适用于季度或半年度项目取舍场景。
要点总览（TL;DR）
- 先按角色和技能盘点净可用人天，扣除运维、支持、休假与培训等固定占用，形成带时间窗口和更新责任人的容量基线。
- 候选项目按角色拆解资源需求，给出乐观、基准、悲观三档估算，并标注稀缺技能与外部依赖，避免用单点数字做取舍。
- 排序标准在评审前确定，把战略贡献、资源占用、依赖和风险放在同一口径下评分，并设定准入线与排队池。
- 超出容量的项目要有明确结论：进入、排队、缩范围或放弃，并留下包含容量基线版本和理由的决策记录。
- 用完成检查清单验证每个入选项目是否对应到具体角色容量、排序规则是否一致使用、超容量部分是否有结论。
先算清可承接容量：资源约束下项目选择的起点
项目选择的起点是一份按角色划分的净可用容量表。它回答的是“本周期各角色实际能投入多少天”，而非“团队有多少人”。人数相同但技能结构不同的两个团队，可承接的项目类型差别很大，因此容量必须拆到角色和关键技能。
盘点时先列出本周期内可参与项目工作的成员，按角色归类，例如后端开发、前端开发、测试、产品设计、数据工程。对每个角色，从名义可用天数中扣除固定占用：日常运维与线上支持、例行会议与培训、已承诺的休假，以及组织规定的非项目事务。扣除后的结果才是净可投入人天。
容量基线需要注明时间窗口和更新频率。常见做法是以季度为窗口，每月更新一次；如果人员变动或支持任务波动较大，可改为双周更新。基线应写明统计口径，例如“按自然日扣除周末与法定假日，按 0.8 的可用系数折算会议与事务占用”，避免不同角色用不同算法导致数据不可比。
输出物是一张净可用容量表，至少包含角色、成员、时间窗口、名义天数、扣除项、净可用人天和更新责任人。更新责任人通常由资源负责人或项目管理办公室指定，负责在人员或承诺变化时修订基线。这张表是后续所有筛选动作的分母，没有它，取舍只能停留在“感觉人手紧”的层面。
| 角色 | 时间窗口 | 名义人天 | 固定占用扣除 | 净可用人天 | 更新责任人 |
|---|---|---|---|---|---|
| 后端开发 | Q3（7–9月） | 按成员合计 | 运维支持、休假、培训 | 扣除后余额 | 资源负责人 |
| 测试 | Q3（7–9月） | 按成员合计 | 回归支持、休假 | 扣除后余额 | 资源负责人 |
| 产品设计 | Q3（7–9月） | 按成员合计 | 例行评审、休假 | 扣除后余额 | 资源负责人 |
候选项目的资源需求估算与不确定性标注
容量基线确定后，下一步是为每个候选项目估算资源占用。估算按角色拆解，例如某项目需要后端 40 人天、前端 25 人天、测试 20 人天、产品设计 10 人天。只给一个总人天数字，无法与按角色建立的容量表对照，也无法发现关键技能缺口。
每个角色的估算给出乐观、基准、悲观三档，或给出一个区间。三档的差异来源应写明：需求清晰度、技术方案成熟度、外部依赖的确定性。基准值用于排序，悲观值用于压力测试——如果多个项目的悲观值叠加后远超容量，说明组合存在系统性风险，需要提前压缩范围或延后。
估算表还要标注两类信息。一是关键技能稀缺度：某角色在全组织只有一两人能承担，该项目的资源风险就高，即使人天数字不大。二是外部依赖：第三方接口交付、供应商排期、跨部门审批，这些依赖会改变资源投入的时间分布，甚至造成等待浪费。标注方式可以用高、中、低三级，并附一句说明。
估算结果需要复核。常见做法是由项目发起人提交估算，资源负责人从技能可用性角度复核，技术负责人从方案可行性角度复核。复核的重点是区间是否合理、稀缺技能是否被多个项目同时占用、外部依赖是否被低估。复核后的估算表作为排序输入，未复核的估算不进入决策。
| 候选项目 | 后端（乐观/基准/悲观） | 测试（乐观/基准/悲观） | 稀缺技能标记 | 外部依赖 |
|---|---|---|---|---|
| 项目 A | 三档人天 | 三档人天 | 高：特定中间件经验 | 中：第三方接口 |
| 项目 B | 三档人天 | 三档人天 | 低 | 高：供应商排期 |
排序与准入：把战略价值和资源占用放在同一口径比较
排序规则要在评审前确定，并在本次选择中一致使用。标准通常由四部分构成：战略贡献、资源占用、依赖关系和风险。战略贡献回答“为什么做”，资源占用回答“代价多大”，依赖回答“是否具备启动条件”，风险回答“不确定性是否可接受”。四者放在同一张评分表里，才能避免只凭声量或职级做决定。
评分口径需要具体到可判断的程度。战略贡献可以按“直接支撑年度目标”“支撑关键客户承诺”“改善基础能力”“一般优化”分级赋分；资源占用按基准人天折算，占用越高得分越低；依赖按“无外部依赖”“依赖可控”“依赖不可控”分级；风险按技术、资源、外部三类分别评估后取高者。权重由组合决策者与业务负责人事前商定，例如战略贡献 40%、资源占用 25%、依赖 15%、风险 20%，权重一经确定，本周期内不因单个项目调整。
准入线是进入执行清单的最低分数或必要条件。可以设两条线：一条是分数线，低于该分数的项目不进入本周期；另一条是条件线，例如“关键技能可用容量不足的项目不得进入”，即使分数较高也先排队。排队池按分数排序，容量释放时依次递补，避免每次都要重新争论。
超出容量时的取舍规则要事先写清。常见规则包括：优先保障战略贡献高且资源占用低的项目；同一稀缺技能被多个项目占用时，只保留优先级最高的一个，其余延后；悲观估算叠加超过容量 20% 时，整体压缩范围而非逐个削减；依赖不可控的项目进入观察池，待依赖明确后再评估。每条规则都要对应到具体动作：进入、排队、缩范围或放弃，并记录理由。
| 排序维度 | 评分口径示例 | 权重 | 数据来源 |
|---|---|---|---|
| 战略贡献 | 按目标支撑程度分级赋分 | 40% | 业务负责人评定 |
| 资源占用 | 按基准人天反向折算 | 25% | 需求估算表 |
| 依赖关系 | 按依赖可控程度分级 | 15% | 发起人申报与复核 |
| 风险 | 技术、资源、外部取高者 | 20% | 技术负责人与资源负责人 |
角色分工与决策交付物
选择过程需要三类角色各司其职。资源负责人提供容量基线，维护净可用人天表，复核需求估算中的技能可用性；项目发起人提出候选项目，提交资源需求估算、战略贡献说明和依赖清单；组合决策者主持评审，确认排序规则与权重，对进入、排队、放弃做出最终决定。三类角色之外，记录人负责留存决策依据，通常由项目管理办公室或指定的项目管理人员承担。
每个角色的输入与输出要明确。资源负责人的输入是人员名单、承诺占用和休假计划，输出是容量基线与复核意见；发起人的输入是项目目标与初步方案，输出是估算表和依赖说明；决策者的输入是排序结果与容量对照，输出是准入清单、排队池和放弃清单。记录人把上述材料归档，形成可追溯的决策记录。
决策会议按固定节奏召开，例如每季度一次评审会、每月一次容量更新会。会议记录至少包含：参会角色、使用的容量基线版本、排序评分、每个项目的结论与理由、下次复核时间。决策结果要传达给发起人、资源负责人和执行团队负责人，排队池中的项目发起人应收到明确的递补条件，避免项目在无通知的情况下被搁置。
当项目清单、资源需求和决策记录需要在同一处承载和流转时，可以借助 ONES 的项目与资源管理能力：资源规划视图按业务优先级安排团队资源，成员排期与投入比重帮助核对容量与需求的对应关系，工时与饱和度数据为后续复盘提供依据。具体版本与部署方式以组织实际采购为准。
示例：一个季度窗口内的项目取舍过程
以下为演示情景，用于说明推演过程，数字仅作示例。某团队 Q3 净可用容量为：后端 180 人天、前端 120 人天、测试 100 人天、产品设计 60 人天。候选项目四个，估算取基准值：项目 A 需要后端 60、前端 40、测试 30、设计 15；项目 B 需要后端 50、前端 30、测试 25、设计 10；项目 C 需要后端 40、前端 35、测试 30、设计 20；项目 D 需要后端 45、前端 25、测试 20、设计 10。
按事前确定的权重评分后，排序为 A、C、B、D。A 与 C 合计占用后端 100、前端 75、测试 60、设计 35，均在容量内，进入执行清单。B 加入后后端达到 150、测试 85，仍在容量内，但 B 依赖的第三方接口交付时间未定，依赖项评为不可控，按规则进入观察池。D 与 A 同时占用同一稀缺技能，且 D 的战略贡献评分低于 A，按“稀缺技能只保留优先级最高项目”的规则，D 进入排队池，递补条件为 A 释放该技能或下季度容量增加。
决策记录写明：容量基线版本为 Q3-v1，排序权重为 40/25/15/20，A、C 进入执行，B 观察，D 排队；B 的复核时间为下月容量更新会，D 的递补条件为 A 完成关键模块或 Q4 容量确认。记录同时附上各项目估算区间和复核意见，供下季度复盘对照实际投入。
完成检查：判断这次项目选择是否站得住
选择结束后，用以下清单逐项核对。每一项都应有对应的材料或记录，不能只凭会议上的口头共识。
- 每个入选项目是否对应到具体角色的净可用人天，且合计不超过容量基线。
- 排序标准与权重是否在评审前确定，并在本次所有候选项目上一致使用。
- 超出容量的项目是否有明确结论：排队、观察、缩范围或放弃，并写明理由和递补条件。
- 决策记录是否包含容量基线版本、评分结果、参会角色和每个项目的结论，可供后续追溯。
- 容量基线是否指定了更新责任人和更新频率，下次更新日期是否已确定。
- 稀缺技能与外部依赖是否在估算表中标注，并在排序和取舍中被实际考虑。
- 决策结果是否已传达给发起人和执行团队负责人，排队项目的发起人是否收到递补条件。
如果上述条目大部分可以对应到具体材料，这次选择就具备可解释性和可复盘性；如果容量表缺失或排序规则事后才补，结论即使看起来合理，也难以在下一次选择中复用。
常见问题
容量基线多久更新一次比较合适？
常见做法是以季度为窗口、每月更新一次。如果人员变动频繁，或运维支持任务波动较大，可以改为双周更新。更新频率的关键是让基线在两次项目选择之间保持可信：如果上次评审后已有成员转岗、休假计划调整或新增承诺占用，就应在下一次排序前修订基线，并记录版本号，避免用旧数据做新决策。
候选项目估算只有单点数字，还能进入排序吗？
可以进入排序，但建议先补出区间再用于取舍。单点估算无法反映需求清晰度、技术方案成熟度和外部依赖的差异，多个项目叠加时容易低估总占用。实际操作中，可以要求发起人对每个角色给出乐观、基准、悲观三档，基准值用于排序，悲观值用于压力测试。若时间紧张，至少标注哪些估算不确定性高，并在决策记录中写明后续复核时间。
多个项目同时占用同一稀缺技能时怎么处理？
建议在排序规则中事先写明：同一稀缺技能被多个项目占用时，只保留优先级最高的一个，其余进入排队池并注明递补条件。这样做的原因是稀缺技能的人天数字可能不大，但一旦被并行占用，多个项目都会出现等待和切换成本。排队项目应收到明确的递补条件，例如高优先级项目释放该技能或下季度容量增加，避免项目在无通知的情况下被搁置。
决策记录至少应包含哪些内容，才能支撑后续复盘？
决策记录至少包含：参会角色、使用的容量基线版本、排序评分结果、每个候选项目的结论（进入、排队、观察、缩范围或放弃）及理由、排队项目的递补条件、下次复核时间。记录还应附上各项目的估算区间和复核意见。这样在下季度复盘时，可以对照实际投入与当初估算，判断容量口径和排序权重是否需要调整。
项目清单、资源需求和决策记录分散在多个表格里，如何减少流转成本？
当这些材料需要在同一处承载和流转时，可以借助 ONES 的项目与资源管理能力：资源规划视图按业务优先级安排团队资源，成员排期与投入比重帮助核对容量与需求的对应关系，工时与饱和度数据为后续复盘提供依据。是否适用取决于组织已有的工具链和采购版本，具体版本与部署方式以组织实际情况为准。
