项目组合容量约束示例的核心，是用一张按资源类型汇总的容量表，把组合内可投入的总人力与候选项目所需人力放在同一口径下比较。下面这份示例以季度为周期、以人天为单位，先算容量上限，再算已承诺占用，得出剩余可承接容量，最后对照候选项目需求给出承接结论。示例为演示情景，可直接照着填写。
要点总览（TL;DR）
- 示例以季度为周期、人天为单位，按后端、前端、测试、产品设计四类资源分别核算容量上限与剩余可承接容量。
- 计算顺序为：先由人数、理论人天、扣除事务和可投入比例得出容量上限，再减去已承诺项目占用，最后逐项对照候选项目需求。
- 承接结论取决于对照顺序：先接候选C后，候选E仍可承接，候选D因后端与测试需求超出剩余容量需排队或拆分。
- 换团队或换周期时，调整资源分类粒度、周期长度和结论分级，同时保持容量上限、已承诺占用、候选需求三者的计量口径一致。
- 示例为演示情景，只做组合层面的承接判断；已选项目间的人员协调归项目集资源协调与资源负载管理。
示例目标：这张容量表要回答什么
这张表只回答一个问题：本季度项目组合还能承接哪些候选项目。它把组合看作一个整体，用统一的资源口径衡量供给与需求，输出的是承接、排队或拆分的判断，不处理已选项目之间谁先谁后、谁支援谁的问题。
为了让示例可计算，先固定三个口径：
- 周期：一个季度，按13周计，扣除法定节假日与团队例行活动后取整。
- 计量单位：人天。所有容量与需求都换算成人天，避免用“几个人”造成口径混乱。
- 资源类型：按角色划分，示例分为后端、前端、测试、产品设计四类，每类单独核算，不互相挪用。
边界需要提前说明：本示例只做承接判断。项目一旦进入组合，人员之间的调配、冲突化解、关键人依赖处理，属于项目集资源协调和资源负载管理的范畴，不在本表示例的讨论范围内。
完整示例：一个季度的组合容量约束表
示例设定一个20人左右的产品研发组合，季度内已承诺两个项目，另有三个候选项目等待判断。以下三张表依次给出容量上限、已承诺占用和候选项目对照结果。
第一步：按资源类型计算容量上限
容量上限不等于人头数乘以天数。需要先扣除休假、培训、支持性事务等不可用于项目的时间，再乘以可投入比例，得到真正可用于组合项目的可用人天。
| 资源类型 | 人数 | 季度理论人天 | 扣除休假与事务 | 可投入比例 | 容量上限（人天） |
|---|---|---|---|---|---|
| 后端 | 6 | 390 | 40 | 80% | 280 |
| 前端 | 4 | 260 | 26 | 80% | 187 |
| 测试 | 3 | 195 | 20 | 75% | 131 |
| 产品设计 | 2 | 130 | 13 | 70% | 82 |
以行为例说明：后端6人，13周理论人天为390；扣除休假与内部事务40人天后剩350，再按80%可投入比例折算，容量上限为280人天。可投入比例留出的余量用于线上问题、评审、跨团队支持等无法预先排入项目的消耗。
第二步：汇总已承诺项目的占用
已承诺项目指本季度已经立项、资源已经确认投入的项目。把它们的需求按资源类型归集，得到占用数。
| 资源类型 | 容量上限 | 项目A占用 | 项目B占用 | 已承诺合计 | 剩余可承接容量 |
|---|---|---|---|---|---|
| 后端 | 280 | 120 | 90 | 210 | 70 |
| 前端 | 187 | 80 | 60 | 140 | 47 |
| 测试 | 131 | 50 | 40 | 90 | 41 |
| 产品设计 | 82 | 35 | 25 | 60 | 22 |
剩余可承接容量等于容量上限减去已承诺合计。四类资源分别剩余70、47、41、22人天，这就是本季度组合还能对外承接的空间。
第三步：候选项目需求对照与结论
三个候选项目按资源类型估算需求，逐项与剩余容量比较。任一资源类型超出剩余容量，该项目在本季度就无法完整承接。
| 候选项目 | 后端需求 | 前端需求 | 测试需求 | 产品设计需求 | 对照结果 | 结论 |
|---|---|---|---|---|---|---|
| 候选C | 40 | 30 | 20 | 10 | 四类均在剩余容量内 | 可承接 |
| 候选D | 50 | 25 | 30 | 15 | 后端、前端、测试、设计均超出或接近上限，其中设计需求15超出剩余22以内但叠加C后不足 | 排队或拆分 |
| 候选E | 20 | 10 | 10 | 5 | 四类均在剩余容量内 | 可承接 |
承接顺序会影响结果。若先接候选C，剩余容量变为后端30、前端17、测试21、设计12；此时候选E仍可承接，候选D的后端与测试需求均超出剩余，只能排队。若先接候选E再接候选C，结论相同。候选D若要本季度启动，需要缩减范围，例如把后端需求压到30人天以内，或把部分工作推迟到下季度。
逐项解释：每个字段为什么这样填
表格能算对，前提是每个字段的取值有依据。以下解释示例中的关键选择。
容量上限为什么按可用人天而非人头
人头数无法反映休假、培训、支持性事务和并行工作带来的损耗。同样6个后端，有人全职投入，有人一半时间在维护线上系统，按人头算会高估供给。换算成可用人天并乘以可投入比例，才能让容量与项目需求使用同一把尺子。可投入比例不是拍脑袋，应参考上一周期实际投入项目的时间占比。
已承诺占用如何归集到资源类型
归集依据是项目估算中按角色拆分的工时，而不是按部门或按人分摊。一个项目如果后端工作量集中在某两个人身上，仍按后端总量计入后端行，因为容量表衡量的是资源类型的整体供给，个人层面的负载均衡留给后续协调环节。跨类型支援的情况，在估算阶段就折算到实际执行的资源类型下。
缓冲比例或预留容量为什么单独设
示例把缓冲放在容量上限的可投入比例里，而不是在剩余容量上再打一次折。这样做的好处是口径统一：容量上限已经是净可用值，剩余容量可以直接与候选需求比较，不需要读者再做二次换算。若组织习惯单独列一行“预留”，也可以在容量上限之后减去预留值，但同一张表内只采用一种做法，避免重复扣减。
候选需求估算的粒度与不确定性标注
候选项目尚未立项，估算精度天然低于已承诺项目。示例采用按资源类型给区间中值的做法，并在备注中标注不确定性：需求明确的部分按中值填，存在方案未定的部分标注“待确认”，并在结论列注明“需在立项前复核”。粒度上，估算到十人天级别即可支撑承接判断，不必精确到个位数。
当这些数据分散在多个项目文档和工时记录中时，归集本身会消耗大量时间。ONES 可以把项目工作项与工时记录关联起来，按项目和角色汇总投入，让容量上限与已承诺占用来自同一套数据，减少手工拼接表格的误差。这一步只是让示例中的数字更容易获得，判断逻辑仍按上述口径执行。
可迁移规律：换团队、换周期怎么改
示例的结构可以复用，需要调整的是分类粒度、周期长度和结论分级。以下清单按改动点给出做法。
- 资源分类粒度随团队规模调整。20人左右的团队按角色分四类足够；50人以上可细分到技能方向，如后端再分为业务后端与基础架构；10人以下的小团队可合并为研发、测试、设计三类，避免表格过细导致每行样本太小。
- 周期从季度改为月度时，理论人天按当月工作日计算，可投入比例适当下调，因为短周期内事务性消耗占比更高；改为半年度时，可投入比例可略高，但要在期中设置一次复核点，防止前期占用过满导致后期无调整空间。
- 需求估算精度不足时，先按区间估算并取上限做压力测试。若按上限仍能承接，可直接判定可承接；若按上限超出、按下限有余，则标注为“有条件承接”，条件写明需要确认的范围或时间点。
- 结论列可从两档扩展为三档或四档：可承接、有条件承接、排队、拆分后承接。分级的关键是每档对应明确的后续动作，例如“有条件承接”要求在立项评审前补齐需求确认，“拆分后承接”要求给出拆分方案和跨周期安排。
调整时保持一条原则：容量上限、已承诺占用、候选需求三者的计量单位和资源分类必须一致。任何一处改动，另外两处同步调整，否则对照结果失去意义。
适用边界：这个示例不覆盖什么
示例中的数字和结论均为演示情景，用于说明表格结构与计算顺序，不代表任何真实客户的情况，也不构成对承接结果的预测。
需要明确的假设与局限包括：
- 示例只做组合层面的承接判断。已选项目之间的人员协调、冲突处理、关键人依赖，属于项目集资源协调和资源负载与冲突管理的范围，本示例不展开。
- 容量数据的准确性依赖工时记录和人员可用性记录的完整程度。若休假、支持性事务没有及时登记，容量上限会被高估，剩余容量随之失真。
- 示例假设资源类型之间不可随意替换。实际工作中存在一专多能的情况，可在分类时把具备跨类型能力的人员单独标注，但不改变按类型核算的基本结构。
- 示例不涉及具体工具的价格、版本与认证信息，工具选择不影响上述计算逻辑。
把这张表当作季度承接决策的起点，配合立项前的需求复核和周期中的容量复查，才能让承接结论保持有效。
常见问题
候选项目需求估算精度不够时，还能用这张表做承接判断吗？
可以，但要把不确定性写进结论。做法是先按区间估算，取上限做压力测试：按上限仍能承接的，直接判定可承接；按上限超出、按下限有余的，标注为“有条件承接”，并写明需要在立项评审前确认的范围或时间点。这样表格输出的是带条件的判断，后续复核有明确抓手。
如果同一名员工同时具备后端和测试能力，容量表应该怎么记？
基本结构仍按资源类型核算，把具备跨类型能力的人员在分类时单独标注，说明其可支援的方向和大致比例。容量上限仍计入其主要归属的资源类型，避免同一份人天在两类资源中被重复计算。个人层面的具体调配，属于项目集资源协调环节处理的问题。
季度中途有项目提前结束或新增紧急项目，这张表怎么更新？
更新已承诺占用行即可，容量上限通常不变。项目提前结束时，把释放出的人天从已承诺合计中扣除，剩余可承接容量相应增加；新增紧急项目则反向操作，把它计入已承诺占用后重新计算剩余容量，再对照候选项目需求。建议在季度中点设一次复核，避免前期占用过满导致后期没有调整空间。
小团队人数少，按四类资源分表后每行数字都很小，还有必要分这么细吗？
10人以下的小团队可以合并为研发、测试、设计三类，减少行数，让每类资源有足够的样本量支撑判断。分类粒度服务于承接判断：如果合并后仍能看出哪类资源是瓶颈，就够用；如果合并掩盖了关键约束，再拆细。关键是容量上限、已承诺占用和候选需求使用同一套分类。
这张容量表和项目集层面的资源协调是什么关系？
容量表回答的是组合还能不能接新项目，输出承接、排队或拆分的结论。项目进入组合之后，人员之间的调配、冲突化解和关键人依赖处理，属于项目集资源协调与资源负载管理的范围。两者衔接点在立项：容量表给出承接判断，立项后的资源安排由协调机制接手。
