项目组合容量规划表用来回答一个具体问题：现有资源能承接哪些项目、承接顺序怎么排。做法是把各角色可用工时与各项目分阶段所需工时放进同一张表，按周期对齐后看差额。下面给出可直接复制的空白表、逐字段填写口径、必填与选填清单、一份季度示例，以及后续维护规则。
要点总览（TL;DR）
- 项目组合容量规划表按“供给—需求—差额结论”三张表组织，用同一套周期和角色口径对齐后相减，回答现有资源能承接哪些项目、按什么顺序排。
- 必填字段包括周期、角色、净可用工时、项目名称、优先级、需求工时、容量差额和承接结论；取数来源、估算依据、需求提出人等可按团队成熟度选填。
- 容量差额＝净可用工时−（已承接需求＋候选需求），占用率＝需求工时÷净可用工时；判断阈值由团队自定，但同一张表内应保持一致。
- 示例中后端角色差额为负，候选项目C需排队或补外援；前端余量很小，测试角色可承接，说明结论要按角色分别判断。
- 维护上按季度或月度固定更新，并在新增高优先级项目、关键人员变动时触发更新；每次保留带日期的版本，记录变更原因和决策人。
可复制空白模板：项目组合容量规划表
模板分三张表：供给表记录“有多少”，需求表记录“要多少”，差额结论表记录“能不能接、先接谁”。三张表使用同一套周期和角色口径，才能横向相减。建议先在表格工具中建三个工作表，表头照抄即可使用。
表一：资源供给区
| 周期 | 团队/小组 | 角色 | 人员姓名或人数 | 可用人数 | 人均可用工时 | 可用工时合计 | 非项目占用工时 | 净可用工时 | 取数来源 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| 如2025 Q1 | ||||||||||
表二：项目需求区
| 项目编号 | 项目名称 | 优先级 | 计划周期 | 阶段 | 所需角色 | 需求工时 | 需求提出人 | 估算依据 | 是否已立项 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
表三：容量差额与承接结论区
| 周期 | 角色 | 净可用工时 | 已承接项目需求工时 | 候选项目需求工时 | 容量差额 | 占用率 | 承接结论 | 排队顺序 | 结论依据与决策人 |
|---|---|---|---|---|---|---|---|---|---|
| 可承接/需排队/需外援 | |||||||||
复制使用时注意三点：三张表的“周期”和“角色”取值必须来自同一份清单；需求表按项目阶段拆行，一个项目跨阶段就占多行；差额结论表按“周期×角色”汇总，一行对应一个格子，便于直接看出哪个角色在哪个周期吃紧。
字段说明：每个字段填什么、怎么算
字段口径不统一是这类表最常见的失效原因。下表给出每个字段的含义、取数来源和计算方式，填写前先确认团队使用同一套工时单位（建议人时或人天，全表统一）。
| 字段 | 含义 | 取数来源/口径 | 计算方式 |
|---|---|---|---|
| 周期 | 容量核算的时间粒度 | 按季度或月度，与排期节奏一致 | — |
| 角色 | 可互换的技能分组，如后端、前端、测试 | 团队现有分工，颗粒度到能独立排期的层级 | — |
| 可用人数 | 该周期内可投入该角色的人数 | 花名册扣除休假、离职、借调 | — |
| 人均可用工时 | 单个成员在该周期的有效工作时间 | 工作日×每日工时×可投入比例 | 工作日数×日工时×投入系数 |
| 可用工时合计 | 该角色全部可用工时 | 由前两列推导 | 可用人数×人均可用工时 |
| 非项目占用工时 | 运维、支持、培训等不归属具体项目的时间 | 历史统计或团队约定比例 | — |
| 净可用工时 | 真正可用于项目承接的工时 | 由供给区推导 | 可用工时合计−非项目占用工时 |
| 优先级 | 项目在组合中的排序依据 | 业务价值、合同节点、战略方向 | — |
| 阶段 | 项目当前或计划进入的交付阶段 | 项目计划 | — |
| 需求工时 | 该阶段该角色所需投入 | 类比估算、专家判断或历史项目数据 | 按阶段×角色分别估算后汇总 |
| 容量差额 | 供给与需求的缺口或余量 | 由供给与需求推导 | 净可用工时−（已承接需求+候选需求） |
| 占用率 | 需求占供给的比例 | 由供给与需求推导 | 需求工时÷净可用工时 |
| 承接结论 | 该周期该角色能否再接项目 | 依据差额与占用率判断 | 差额≥0且占用率低于阈值可承接 |
差额与占用率建议固定一套判断规则，例如差额为正且占用率不超过85%判为可承接，差额为负判为需排队或需外援。阈值由团队自行设定，但同一张表内应保持一致，避免不同周期用不同标准。
周期与角色口径统一是计算成立的前提。周期上，供给按季度、需求按月会导致无法相减，需先折算到同一粒度；角色上，若一个项目同时需要“后端”和“服务端”两个名称指代同一批人，汇总时会重复计算供给。填写前把角色清单定稿，全表引用同一份清单。
必填与选填：哪些字段不能空
必填字段决定这张表能否算出结论，缺一项结论就不可信；选填字段用于补充判断依据，可按团队成熟度取舍。
必填字段清单
- 周期、角色：缺少任一项，供给与需求无法对齐，差额计算失去意义。
- 净可用工时：差额计算的减数，缺失则无法判断余量。
- 项目名称、优先级、需求工时：承接顺序和缺口都依赖这三项，优先级缺失时排队顺序只能靠主观判断。
- 容量差额、承接结论：这是表的输出，空缺等于表没有完成。
选填字段清单
- 取数来源、估算依据：用于复核和追溯，团队首次使用时建议填写，稳定后可简化。
- 需求提出人、决策人：涉及跨部门争议时填写，便于回溯结论由谁拍板。
- 排队顺序：候选项目较多时填写，只有一个候选项目时可省略。
- 是否已立项：用于区分确定需求和意向需求，组合变动频繁时建议保留。
必填缺失时的降级处理
净可用工时暂时无法精确统计时，可先用“可用人数×标准工时×经验投入系数”估算，并在备注中标注为估算值，待有工时数据后替换。优先级缺失时，先按合同节点或业务方确认的排序填入，并注明“待确认”，避免用默认顺序冒充决策结果。需求工时完全无法估算的项目，不进入本期承接结论，单独列入待评估清单。
不同团队规模下的字段取舍
十人左右的团队可只保留周期、角色、净可用工时、项目名称、需求工时、差额、结论七个字段，减少维护负担。跨多个小组的团队需要保留团队/小组字段，否则汇总时无法定位缺口归属。角色种类多、人员可跨角色复用的团队，建议保留“人员姓名或人数”字段，便于判断供给是否真实可调配。
填写示例：一个季度周期的完整填法
以下为演示情景，数据均为假设，用于说明填写过程，不代表任何真实团队。
示例背景与假设条件
某研发团队2025年第一季度有后端8人、前端5人、测试3人。按每季度60个工作日、每日8小时、投入系数0.8计算，人均可用工时为384人时。非项目占用按20%计。组合内有三个项目：A为已立项的合同项目，B为已立项的内部平台项目，C为待决策的新项目。
供给区填写结果
| 周期 | 角色 | 可用人数 | 人均可用工时 | 可用工时合计 | 非项目占用工时 | 净可用工时 |
|---|---|---|---|---|---|---|
| 2025 Q1 | 后端 | 8 | 384 | 3072 | 614 | 2458 |
| 2025 Q1 | 前端 | 5 | 384 | 1920 | 384 | 1536 |
| 2025 Q1 | 测试 | 3 | 384 | 1152 | 230 | 922 |
需求区填写结果
| 项目 | 优先级 | 阶段 | 角色 | 需求工时 | 是否已立项 |
|---|---|---|---|---|---|
| A | 1 | 开发 | 后端 | 1200 | 是 |
| A | 1 | 开发 | 前端 | 800 | 是 |
| A | 1 | 测试 | 测试 | 500 | 是 |
| B | 2 | 开发 | 后端 | 700 | 是 |
| B | 2 | 开发 | 前端 | 400 | 是 |
| C | 3 | 开发 | 后端 | 600 | 否 |
| C | 3 | 开发 | 前端 | 300 | 否 |
| C | 3 | 测试 | 测试 | 350 | 否 |
差额计算与承接结论
| 角色 | 净可用工时 | 已承接需求 | 候选需求 | 容量差额 | 占用率 | 承接结论 |
|---|---|---|---|---|---|---|
| 后端 | 2458 | 1900 | 600 | −42 | 101.7% | 需排队或需外援 |
| 前端 | 1536 | 1200 | 300 | 36 | 97.7% | 余量很小，谨慎承接 |
| 测试 | 922 | 500 | 350 | 72 | 92.2% | 可承接，需关注峰值 |
结论：A、B两个已立项项目在本季度可以排入；C项目的后端需求超出净可用工时42人时，若按原计划承接将挤压A项目的开发时间，建议C延后至下季度或为后端补充外援。前端余量仅36人时，承接C后几乎没有缓冲，需在计划中预留风险时间。测试角色差额为正，C的测试需求可以承接。
示例中每个数字都能对应回字段说明：净可用工时由可用工时合计减去非项目占用得出，容量差额等于净可用工时减去已承接与候选需求之和，占用率为需求合计除以净可用工时。填写自己的表时按同样顺序推导，可避免口径漂移。
调整与维护方法：让表随组合变化持续可用
容量规划表的价值在于持续使用。一次性填完就归档，下一季度又要重新摸索口径，反而增加成本。维护重点在更新节奏、字段增减和版本留痕三件事。
更新频率与触发条件
- 固定节奏：按季度或月度更新一次，与项目排期评审同步，更新后重新计算差额与结论。
- 事件触发：新增高优先级项目、关键人员离职或借调、项目范围明显变化、合同节点调整时，立即更新对应周期和角色。
- 结论复核：每次更新后检查排队项目是否仍按原顺序，避免旧结论长期沿用。
字段增减的判断标准
新增字段的前提是它能改变承接结论或减少争议。例如增加“技能标签”字段，是因为同角色内人员能力差异导致供给不可直接互换；增加“外部资源成本”字段，是因为外援方案需要比较。若某字段连续两个周期无人查看、也未影响任何结论，可以删除，保持表简洁。删除字段前确认历史数据已归档，避免追溯困难。
版本与留痕方式
每次更新保留一份带日期的版本，记录变更内容、变更原因和决策人。表格工具中可使用版本历史或另存副本；若在协作平台中维护，建议将规划表作为文档保存，结论变更时在文档中写明调整依据。留痕的作用是当承接结论被质疑时，能说明当时的供给和需求数据。
与项目集资源协调的边界划分
这张表回答“组合层面能承接哪些项目、按什么顺序排”，输出的是承接结论和排队顺序。项目一旦进入执行，具体人员之间的调配、冲突处理、日排期调整属于项目集资源协调和资源负载管理的范围，不在本表内展开。保持这条边界，可以避免把组合决策表做成日常排班表，导致维护成本失控。
承接结论确定后，需要落到可跟踪的载体上。ONES 提供资源规划视图，管理者可以按业务优先级安排团队资源，并通过资源利用率、负荷度和成员每日投入饱和明细查看规划是否被执行；规划结论可作为文档留存，相关任务进入工作项跟踪。这样容量表负责决策，执行数据回流用于下一周期修正供给与需求估算。
常见问题
团队只有十人左右，这张表可以精简到哪些字段？
小团队可以只保留周期、角色、净可用工时、项目名称、需求工时、容量差额、承接结论七个字段，先把“能不能接”算清楚。取数来源、估算依据、需求提出人、排队顺序等字段在出现争议或候选项目增多时再补。精简的前提是周期和角色口径仍然统一，否则差额算出来也不可信。
净可用工时暂时统计不出来，能不能先用估算值填？
可以先用“可用人数×标准工时×经验投入系数”估算，并在备注中标注为估算值，等有工时数据后替换。需要注意，估算值只用于过渡，不能长期替代实际统计，否则容量差额会持续偏离真实情况。若某个项目的需求工时完全无法估算，建议不进入本期承接结论，单独列入待评估清单。
容量差额为正就一定可以承接新项目吗？
差额为正说明该周期该角色还有余量，但还要看占用率和缓冲空间。示例中前端差额为36人时、占用率97.7%，余量很小，承接后几乎没有风险缓冲，结论写的是“谨慎承接”。团队可以设定自己的占用率阈值，例如不超过85%判为可承接，超过则需评估风险或排队。阈值一旦确定，同一张表内各周期应保持一致。
这张表和项目集资源协调是什么关系，会不会重复维护？
这张表回答组合层面“能承接哪些项目、按什么顺序排”，输出承接结论和排队顺序。项目进入执行后，具体人员调配、冲突处理和日排期调整属于项目集资源协调与资源负载管理的范围。把边界划清，可以避免把组合决策表做成日常排班表。承接结论确定后，可以落到可跟踪的载体上，例如在 ONES 的资源规划视图中按业务优先级安排团队资源，并通过资源利用率、负荷度和成员每日投入饱和明细查看执行情况，相关任务进入工作项跟踪。
更新频率应该怎么定，哪些情况需要临时更新？
固定节奏建议按季度或月度更新一次，与项目排期评审同步。出现新增高优先级项目、关键人员离职或借调、项目范围明显变化、合同节点调整时，应立即更新对应周期和角色。每次更新后要复核排队项目是否仍按原顺序，避免旧结论长期沿用。版本上保留带日期的副本，记录变更内容、原因和决策人，便于结论被质疑时回溯当时的供给和需求数据。
