项目组合容量约束示例要回答一个具体问题：在资源有限的一个周期里，组合能承接哪些项目。下面用一份假设的季度组合数据，把候选项目的资源需求、各角色的净可用容量和承接结论放进同一张表，逐项说明数字来源，并给出换一个组合也能照着填的步骤。示例数据仅用于演示计算口径，不代表任何真实组织。
要点总览（TL;DR）
- 示例把候选项目的角色工时需求、各角色净可用容量和承接结论放进同一张季度表，按角色、按周期对齐后判断哪些项目能承接。
- 净可用容量由编制人数、有效工作日、日常运维占用和请假培训逐项折算得出，用名义人力做判断会高估可用容量。
- 三类角色总量都有余量时，前端占用率已达83%，项目排期叠加仍会造成局部超载，承接结论需同时看角色总量和排期分布。
- 承接结论要落到项目动作：入选、延后到何时、分期做哪部分、缩减多少需求，便于执行时直接对应。
- 这套表适用于组合层面的承接与取舍判断，已选项目之间的人员协调与冲突处理不在其范围内。
示例要解决什么问题：从候选项目到可承接清单
假设某季度组合有五个候选项目，涉及产品经理、后端工程师、前端工程师三类关键角色。组合管理者的任务是在季度开始前判断：哪些项目本季度可以承接，哪些需要延后，哪些可以分期或缩减范围。判断口径统一为“按角色、按周期对比需求与净可用容量”，即同一角色在同一季度内，需求工时与净可用工时直接相减，得到缺口或余量。
这张表要输出三部分信息：需求侧是每个候选项目按角色拆分的工时需求；可用侧是每个角色扣除日常运维、请假、培训等占用后的净可用工时；结论侧是每个项目在容量约束下的承接决定。三类信息放在同一张表里，项目之间的取舍才有共同基准。
需要先明确一个前提：示例只处理组合层面的承接判断，即“这个项目本季度进不进组合”。项目入选之后，人员如何在项目间调配、冲突如何解决，属于另一个管理动作，不在本表示例范围内。
完整示例：一张季度组合容量约束表
下表为假设情景的完整示例。需求以人天为单位，周期为一个季度，按每名角色每季度可投入的有效工作日折算。
| 候选项目 | 产品经理需求（人天） | 后端需求（人天） | 前端需求（人天） | 优先级 | 承接结论 |
|---|---|---|---|---|---|
| 项目A 订单流程改造 | 20 | 60 | 40 | 高 | 入选 |
| 项目B 客户门户改版 | 15 | 30 | 50 | 高 | 入选，前端需求缩减至35人天 |
| 项目C 数据报表平台 | 10 | 45 | 20 | 中 | 延后至下季度 |
| 项目D 移动端适配 | 8 | 20 | 30 | 中 | 分期，本季度只做核心页面 |
| 项目E 内部工具优化 | 5 | 15 | 10 | 低 | 延后 |
| 需求合计 | 58 | 170 | 150 | — | — |
可用侧按角色分别折算。假设产品经理2人、后端工程师5人、前端工程师4人，季度有效工作日按每人60天计（已扣除周末与法定假日），再扣减日常运维、请假、培训等占用。
| 角色 | 编制人数 | 名义可用（人天） | 日常运维占用 | 请假与培训 | 净可用容量（人天） |
|---|---|---|---|---|---|
| 产品经理 | 2 | 120 | 20 | 10 | 90 |
| 后端工程师 | 5 | 300 | 60 | 25 | 215 |
| 前端工程师 | 4 | 240 | 40 | 20 | 180 |
把需求合计与净可用容量对齐，得到缺口与占用率：
| 角色 | 需求合计（人天） | 净可用容量（人天） | 缺口（人天） | 占用率 |
|---|---|---|---|---|
| 产品经理 | 58 | 90 | 余量32 | 64% |
| 后端工程师 | 170 | 215 | 余量45 | 79% |
| 前端工程师 | 150 | 180 | 余量30 | 83% |
从总量看三类角色都有余量，但承接结论并非全部入选。原因在于前端占用率已达83%，接近饱和，而项目B和项目D的前端需求集中在同一时段，叠加后局部超载。因此结论是：项目A、B入选，其中B的前端需求从50人天缩减到35人天；项目C整体延后；项目D分期，本季度只做核心页面；项目E延后。这个示例说明，组合承接判断要同时看角色总量和项目排期叠加，只看合计余量容易做出过于乐观的决定。
逐项解释：每个数字是怎么来的
需求侧折算。每个项目的需求先由项目负责人按工作分解估算总工作量，再按角色拆分。例如项目A的订单流程改造，估算总工作量为120人天，按产品设计、后端开发、前端实现的投入比例拆为20、60、40。拆分依据是各角色在该项目中的实际任务量，而非平均分配。估算精度直接影响结论可靠性，工作量估算偏差大的项目应在表中标注置信度。
可用侧折算。净可用容量的计算分三步：编制人数乘以每人季度有效工作日，得到名义可用；减去日常运维、值班、支持等固定占用；再减去已批准的请假与计划内培训。以产品经理为例，2人乘以60天得120人天，扣除运维20人天、请假培训10人天，净可用为90人天。日常运维占用应按历史记录取值，而非凭印象估计。
缺口与占用率的读法。缺口等于净可用容量减需求合计，为正表示余量，为负表示缺口。占用率等于需求合计除以净可用容量。占用率低于70%通常留有一定缓冲，70%至85%需要关注排期叠加，超过85%则局部冲突风险明显。这些区间是示例中的经验参考，各组织应结合自身业务波动调整。
结论列的依据。项目C被延后，是因为其45人天的后端需求与项目A、B的后端排期重叠，叠加后后端占用率超过90%。项目D分期，是因为前端在项目B缩减后仍无足够余量承接全部30人天，只保留核心页面的15人天。项目E优先级最低，在容量紧张时首先让位。结论列写的是项目动作，而非只给一个数字，便于后续执行时直接对应。
当这些数据需要在季度内持续更新时，可以把候选项目清单、角色需求与可用容量维护在统一的项目管理工具中。ONES 的项目管理支持按项目维护工作项与工时信息，资源管理可按角色查看成员负载，组合管理者据此在需求或人员变动时重新核对缺口，减少用过期表格做判断的情况。
可迁移规律：换一个组合也能照着填
把示例迁移到自己的组合，可以按以下步骤填写：
- 确定周期与角色。先选定判断周期（季度或月度），再确定纳入容量测算的关键角色，角色划分与团队实际分工一致。
- 收集候选项目需求。由各项目负责人按角色提交工时需求，并标注估算依据与置信度。
- 折算净可用容量。按编制人数、有效工作日、固定占用、请假培训逐项计算，占用数据取自历史记录。
- 对齐需求与容量。按角色汇总需求，与净可用容量相减，得到缺口与占用率。
- 检查排期叠加。对占用率偏高的角色，核对项目时间分布，识别局部超载。
- 形成承接结论。按优先级和缺口，对每个项目给出入选、延后、分期或缩减范围的决定，并写明调整后的需求量。
迁移时有四点需要注意。第一，先对齐角色与周期，再谈总量，否则不同角色的余缺会互相掩盖。第二，把占用扣减显性化，用名义人力做判断会系统性高估可用容量。第三，用情景对比代替单一结论，例如对比“全部承接”和“延后低优先级项目”两种情景下的占用率，结论更有说服力。第四，结论要落到项目动作，写明延后到何时、分期做哪部分、缩减多少，避免只留下一个数字。
适用边界：这张表能回答和不能回答什么
这张表适用于组合层面的承接与取舍判断，即在一个周期开始前决定哪些项目进入组合、哪些让位。它也能用于周期中期的复核，当需求或人员发生较大变化时重新测算。
它不覆盖已选项目之间的人员协调与冲突处理。项目入选后，同一角色在多个项目间的具体排班、任务切换和冲突解决，需要另行动作处理。它也不替代项目内部的详细排期和任务分配。
结论的可靠性依赖两项数据质量：工作量估算的准确度和占用记录的真实性。估算粗糙或占用凭印象填写时，缺口数字只能作为方向参考。示例中的编制人数、工作日和占用比例均为假设值，实际使用时需替换为本组织的真实数据，并按自身业务波动调整占用率的参考区间。
常见问题
示例中三类角色总量都有余量，为什么还有项目被延后？
因为总量余量会掩盖排期叠加造成的局部超载。示例中前端占用率已达83%，项目B和项目D的前端需求集中在同一时段，叠加后超出净可用容量，所以项目B的前端需求从50人天缩减到35人天，项目D改为分期。判断承接时，先看角色总量，再核对项目时间分布，两步都做才能避免过于乐观的结论。
工作量估算精度不高时，这张表还能用吗？
可以用，但结论的性质会变化。估算偏差较大时，缺口数字更适合作为方向参考，而非精确的取舍依据。建议在需求侧为每个项目标注估算依据与置信度，对置信度低的项目在结论列写明复核节点，例如在需求细化后重新测算一次。占用记录同样影响结论，日常运维占用按历史记录取值比凭印象估计更可靠。
占用率的参考区间需要按组织情况调整吗？
需要。示例中低于70%、70%至85%、超过85%三档只是演示用的经验参考，各组织的业务波动、支持类工作占比和人员技能重叠度不同，区间应随实际情况调整。调整时可以用历史季度数据回看：过去哪些占用率水平下出现过明显延期或冲突，据此设定本组织的关注线和警戒线。
项目入选后，人员如何在项目间调配，这张表管吗？
不管。这张表处理的是组合层面的承接判断，即一个周期开始前决定哪些项目进入组合。项目入选之后，同一角色在多个项目间的排班、任务切换和冲突解决属于另一个管理动作，需要单独处理。把两类判断分开，可以避免在承接阶段就陷入具体排班细节，也能让结论更聚焦于项目取舍。
季度中期人员或需求发生较大变化，怎么用这张表复核？
按原口径重新测算即可：更新需求侧的项目工时，更新可用侧的请假、人员变动和占用记录，重新计算缺口与占用率，再对照原结论调整项目动作。复核时重点看占用率偏高的角色和已延后项目的排期，判断是否需要进一步缩减范围或调整分期安排。若数据维护在统一的项目与资源管理工具中，更新后可直接重新核对缺口。
