资源约束下的项目选择，关键是把“能承接多少”先算清楚，再用统一标准排序，按容量分批纳入。本文按容量盘点、需求估算、准入排序、取舍结论四步展开，并给出角色分工、示例与检查清单。项目清单、估算与决策记录可在ONES中承载，方便后续复核。
要点总览（TL;DR）
- 资源约束下的项目选择分四步：按角色盘点可用容量、按角色估算候选项目工作量与依赖、用硬性准入加维度打分排序、按时间窗逐批装入并形成纳入/排队/放弃三张清单。
- 容量盘点要落到角色或技能，扣除已承诺项目与日常运维占用，并预留缓冲，输出按角色和时间窗列出的可用容量表。
- 排序先锁定合规、合同承诺、战略必做等硬性准入项目，再按价值密度、风险、紧迫度、资源匹配度打分，权重在一个规划周期内保持稳定。
- 超容量时优先排队或拆分，任一角色容量耗尽即停止装入；取舍结论需记录决策依据、决策人和日期，并约定重评触发条件。
- 项目清单、角色工作量估算与决策记录可在ONES中承载，资源与工时管理能力可辅助查看成员规划安排与工作饱和情况。
先算清可承接容量：资源约束下项目选择的起点
项目选择的第一步是回答“我们到底还有多少余量”。容量盘点要落到角色或技能上，用可用人天和时间窗表达，才能直接用于筛选项目。仅统计部门总人数，容易掩盖结构性缺口：后端缺两人、测试富余三人，总人数看起来平衡，实际排不进任何新项目。
盘点按以下顺序进行：
- 确定规划周期。通常取一个季度或半年，与预算、考核周期对齐。周期太短看不清项目全貌，太长则估算失真。
- 按角色/技能统计名义容量。用“人数 × 周期内可用工作日”计算，扣除法定假期、培训、休假等非项目时间。
- 扣除已承诺占用。包括已立项项目的排期、日常运维、技术支持、值班等固定投入。这部分是硬占用，不能挪给新项目。
- 设定容量缓冲。预留一定比例应对需求变更、故障处理和估算偏差。缓冲比例按团队历史波动情况设定，波动大的团队留高一些。
- 输出可用容量表。按角色和时间窗列出可用人天，作为后续筛选的供给基线。
| 角色 | 规划周期 | 名义容量（人天） | 已承诺占用 | 缓冲后可用容量 |
|---|---|---|---|---|
| 后端开发 | Q3（约65个工作日） | 390 | 260 | 约90 |
| 前端开发 | Q3 | 260 | 180 | 约55 |
| 测试 | Q3 | 195 | 120 | 约50 |
| 产品/设计 | Q3 | 130 | 90 | 约28 |
表中数字为演示情景，实际取值以团队工时记录和排期为准。容量表的完成标志是：每个角色在每个时间窗都有明确的可用人天，且能追溯到占用来源。ONES的资源与工时管理可查看成员规划安排与工作饱和情况，支持跨项目团队资源规划，并将成员在不同项目的投入比重可视化，便于把已承诺占用从名义容量中剥离出来。
候选项目的工作量与依赖估算
容量表回答供给，估算回答需求。每个候选项目都要按角色拆分工作量，并标注依赖与前提，否则无法与容量表对齐比较。
估算的具体做法：
- 按角色拆分。把项目拆到可估算的工作项，分别估算后端、前端、测试、产品设计等角色的人天，而不是只给一个总人天。总量相同但角色结构不同的两个项目，对容量的消耗完全不同。
- 标注关键依赖与前置条件。例如依赖第三方接口就绪、依赖某系统上线、依赖法务合同签署。依赖未满足的项目即使排进计划也无法按期启动，应在排序时单独标记。
- 给出精度分级与不确定性区间。需求清晰、有历史类似项目的可给较窄区间；只有概念方案的可给较宽区间，并注明“需在立项前细化”。区间用于判断项目是否落在容量缓冲之内。
- 明确估算责任人与复核方式。由项目发起人或技术负责人主导估算，资源负责人复核角色工作量是否与历史效率一致，避免单方拍数。
每个候选项目的交付物是一份“角色工作量 + 依赖清单”：列出各角色人天、估算区间、关键依赖、前置条件和估算责任人。这份清单是排序和取舍的直接输入。
准入条件与排序规则怎么定
有了供给和需求，还需要一套统一标准决定谁先谁后，避免资源按声音大小分配。规则分两层：先过硬性准入，再按维度打分排序。
硬性准入条件
不满足以下任一条件的项目，不进入本轮排序：
- 合规要求：监管、审计、安全整改等必须完成的事项。
- 合同承诺：已签约、有明确交付节点的客户项目。
- 战略必做：经管理层确认、与年度重点方向直接相关的项目。
硬性条件的作用是先把“必须做”的项目锁定，剩余容量再用于排序竞争。
排序维度与权重
| 维度 | 含义 | 打分口径示例 |
|---|---|---|
| 价值密度 | 预期收益与投入人天的比值 | 收益按收入、成本节约或关键指标影响折算，除以总人天 |
| 风险 | 技术、依赖、需求不确定性 | 风险越高得分越低，依赖未落实的项目降档 |
| 紧迫度 | 交付时间窗的刚性程度 | 有外部截止日期的优先，可灵活排期的靠后 |
| 资源匹配度 | 所需角色与可用容量的吻合程度 | 角色缺口小、可直接启动的得分高 |
权重由组合管理者与资源负责人共同商定，并在一个规划周期内保持稳定，避免每次评审临时调整。评分完成后要做校准：把得分接近的项目放在一起对比，检查打分是否受发起人职位或表达能力强弱影响。出现争议时，回到打分口径逐项核对，而不是投票决定。评分表和准入条件清单应作为固定模板留存，供下一轮复用。
按容量取舍：纳入、排队与放弃
排序结果要落到容量上才有意义。做法是按时间窗逐批装入：从得分最高的项目开始，逐项扣减对应角色的可用容量，直到某一角色容量耗尽为止。
超容量时的处理策略：
- 排队。项目本身可行但当前窗口容量不足的，放入下一时间窗的候选队列，并注明预计可启动时间。
- 拆分。项目可分期交付的，把首期范围压缩到容量可承受的程度，后续阶段排入后续窗口。拆分要保证首期本身有独立价值。
- 放弃或延期。价值密度低、依赖长期无法满足、或与战略方向偏离的项目，明确列入放弃清单，并说明理由，避免下一轮重复讨论。
取舍结论要形成三张清单：纳入清单（本轮执行）、排队清单（候补及预计窗口）、放弃清单（含理由）。每张清单记录决策依据、决策人和日期。同时约定变更触发条件，例如关键依赖延期、容量出现重大变化、战略方向调整，触发后重新评审。
在ONES中，项目清单、角色工作量估算和评审结论可以放在同一工作项体系内管理，资源报表实时反馈项目投入情况，决策记录随项目留存，复核时可直接对照当时的容量与评分。
角色分工与各环节交付物
流程能否运转，取决于每个环节是否有人负责、有明确产出。三类角色分工如下：
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 组合管理者 | 组织容量盘点与评审，维护准入条件和评分规则，汇总取舍结论 | 候选项目清单、容量表、评分表 | 纳入/排队/放弃清单、决策记录 |
| 资源负责人 | 提供各角色可用容量，复核项目估算的角色工作量，确认排期可行性 | 工时记录、已承诺项目排期、项目估算 | 可用容量表、估算复核意见 |
| 项目发起人 | 提交候选项目，组织工作量与依赖估算，说明价值与紧迫度 | 业务需求、历史项目数据 | 角色工作量与依赖清单、价值说明 |
评审节点建议设两个：一是容量与估算确认会，由资源负责人和发起人核对数据；二是取舍决策会，由组合管理者主持，按评分规则确定三张清单。决策权限归属管理层或组合管理委员会，组合管理者负责执行和记录。信息承载上，容量表、评分表和清单应放在团队可共同访问的工具中，保持单一数据源，避免多份表格版本不一致。
一个可套用的示例：三个候选项目如何取舍
以下为演示情景，数字仅用于说明流程。
某团队Q3后端可用容量约90人天，前端约55人天，测试约50人天。三个候选项目：
| 项目 | 后端人天 | 前端人天 | 测试人天 | 关键依赖 | 综合得分 |
|---|---|---|---|---|---|
| A：客户合同项目 | 40 | 20 | 20 | 合同已签，硬性准入 | 直接纳入 |
| B：内部效率工具 | 35 | 25 | 20 | 依赖第三方接口 | 82 |
| C：数据看板升级 | 30 | 30 | 15 | 无硬依赖 | 76 |
先锁定A：扣除后后端剩50、前端剩35、测试剩30。按得分装入B：后端需35、前端需25、测试需20，装入后后端剩15、前端剩10、测试剩10。此时C的后端需求30已超出剩余容量，前端需求30也超出。C进入排队清单，预计下一窗口启动；若C可拆分，可先做后端工作量较小的部分，但需确认首期有独立价值。B的第三方接口依赖需在启动前确认，若接口延期，B也应转入排队，释放的容量可重新评估C。
这个示例的规律是：硬性准入项目先占容量，剩余容量按得分依次装入，角色容量中任一角色耗尽即停止装入，拆分和排队是超容量时的两种主要出路。
完成检查：这套流程是否真的跑通了
流程落地后，用以下清单逐项核对：
- 容量数据是否可追溯：每个角色的可用人天能否对应到工时记录和已承诺项目排期。
- 估算与排序是否同口径：所有候选项目是否都按角色拆分工作量，评分是否使用同一套维度和权重。
- 取舍结论是否有记录与责任人：三张清单是否注明决策依据、决策人和日期。
- 依赖是否被跟踪：关键依赖是否有负责人和确认时间，未落实的是否已标记。
- 复核周期是否明确：是否约定固定的重评时间，以及依赖延期、容量重大变化等触发条件。
- 信息是否单一来源：容量表、评分表和清单是否在同一处维护，避免版本冲突。
检查中发现容量数据无法追溯或评分口径不一致，说明流程还停留在表格层面，需要回到容量盘点和规则定义环节补齐，再进入下一轮取舍。
常见问题
容量缓冲比例应该留多少？
缓冲比例没有统一标准，取决于团队历史波动情况。需求变更频繁、故障处理多的团队应留高一些，交付节奏稳定的团队可适当降低。建议先用过去几个周期的实际偏差反推：统计计划人天与实际消耗人天的差距，把平均偏差作为缓冲下限，再结合下一周期的已知风险上调。缓冲比例确定后写入容量表，并在复核时检查是否被频繁突破，突破则说明比例偏低或估算口径有问题。
候选项目估算精度不够，还能进入排序吗？
可以进入排序，但要标注估算精度和不确定性区间。需求清晰、有历史类似项目的可给较窄区间；只有概念方案的给较宽区间，并注明需在立项前细化。排序时把区间上限与容量缓冲对照：区间上限仍落在缓冲内的项目可正常参与竞争；区间上限明显超出缓冲的，先列入排队或要求发起人补充细化后再评。这样既不因估算粗糙直接排除项目，也避免用过于乐观的数字挤占容量。
硬性准入项目已经占满容量，其他项目怎么办？
硬性准入项目优先占用容量，剩余容量才用于排序竞争。如果硬性项目已占满全部容量，其他项目全部进入排队清单，并注明预计可启动的时间窗。此时需要向发起人说明的是容量事实和排队顺序，而不是简单拒绝。同时检查硬性项目的工作量估算是否偏大、是否存在可拆分或可延后的部分，在合规和合同允许的前提下释放容量。若连续多个周期硬性项目占满容量，应把这一情况反馈到资源规划层面，考虑增补人力或调整承诺节奏。
取舍结论做出后，什么情况下需要重新评审？
建议约定几类触发条件：关键依赖延期或落空，例如第三方接口未就绪、合同签署推迟；容量出现重大变化，例如核心成员离职、新增紧急项目占用大量人力；战略方向调整导致项目优先级变化；以及固定的周期复核节点。触发后不必推翻全部结论，只需重跑受影响部分的容量扣减和排序，更新三张清单并记录变更原因。把触发条件写进决策记录，可以减少临时起意式的重新讨论。
这套流程在ONES中如何承载？
项目清单、角色工作量估算和评审结论可以放在同一工作项体系内管理，保持单一数据源。ONES的资源与工时管理可查看成员规划安排与工作饱和情况，支持跨项目团队资源规划，并将成员在不同项目的投入比重可视化，便于把已承诺占用从名义容量中剥离；资源报表可反馈项目投入情况，决策记录随项目留存，复核时可直接对照当时的容量与评分。具体功能范围与版本可用性建议向厂商核实。
