项目组合资源容量规划要回答的是：在现有团队产能下，这一期能承接哪些项目。做法分四步：先按技能与角色折算可用容量，再估算候选项目的分角色需求，把两侧放到同一时间轴上做情景对比，最后在容量约束下确定承接、推迟或缩减范围的项目。本文覆盖组合层面的取舍过程，已选项目之间的人员协调不在讨论范围内。ONES 可用于沉淀资源、工时与项目数据，为这套测算提供可复用的数据基础。
要点总览（TL;DR）
- 容量规划先按技能与角色把可用产能折算成可承诺容量，再对照候选项目的分角色需求做情景测算，最后在容量约束下确定承接、推迟或缩减范围的项目。
- 供给侧用一张容量基线表：名义产能扣除请假、管理事务与非项目投入，再留出缓冲，由资源经理确认并可复算。
- 需求侧用一张项目需求表：按角色估算人天并分布到时间轴，标出峰值月份与峰值角色，估算假设需项目负责人确认。
- 情景对比把供需放到同一时间轴，按基准、乐观、保守三种情景标出超载时段与缺口角色，取舍决策由组合决策层拍板并记录理由。
- 落地后按季度或重大变更刷新数据，用口径一致、数据可复算、缺口有应对、决策有记录四项检查，并通过实际投入与估算的偏差复盘提高下一轮精度。
容量规划先回答哪三个问题
容量规划的对象是技能与角色维度的产能，回答的是组合层面的承接能力。单个人员下周排什么任务属于排班与任务分配，不在本文范围内。把问题收敛到以下三个，规划就有了可计算的结构。
- 可用容量有多少：按角色或技能统计，未来一个季度团队能投入项目工作的有效人天是多少。这个数字要扣除请假、管理事务、培训和非项目支持工作，并留出应对不确定性的缓冲。
- 候选项目需要多少：每个待决策项目在各阶段需要哪些角色、投入多少人天、峰值出现在哪个月。需求要落到角色和时间段，才能与容量对齐。
- 在约束下承接哪些：当需求总量超过容量，或某几个时段某类角色明显不足时，决定哪些项目进入本期组合、哪些推迟、哪些缩减范围或寻求外部补充。
三个问题对应三张表：容量基线表、项目需求表、情景对比表。三张表口径一致、时间粒度一致，后续测算和决策才能复算和追溯。规划边界也需要提前说清：本文处理的是“承接哪些项目”，项目一旦进入组合，项目之间的人员冲突处理、任务级排期属于另一层管理动作，由项目集协调机制解决。
第一步：建立可用容量基线
容量基线是供给侧的起点，目标是把人员编制折算成资源经理认可、可复算的可承诺容量。
输入：人员名单、技能标签或角色归属、合同工时与可用工作日、已批准的请假记录、管理职责与非项目占用（如运维支持、招聘面试、内部培训）。
动作：先按角色或技能把人员归类，同一人具备多技能时明确主角色与可支援角色，避免重复计算。再用可用工作日乘以每日有效工时，得到名义产能；逐项扣除请假、管理事务和非项目投入；最后按一定比例留出缓冲，用于需求波动、返工和临时支持。缓冲比例由团队历史波动情况决定，没有统一标准。
输出：分角色的月度或季度可用容量表。建议字段如下：
| 字段 | 说明 | 示例口径 |
|---|---|---|
| 角色/技能 | 容量统计维度 | 后端开发、测试、产品经理 |
| 人员数 | 该角色可投入项目的人数 | 按主角色计入 |
| 名义产能（人天） | 可用工作日 × 每日有效工时 | 季度口径 |
| 扣除项 | 请假、管理、非项目占用 | 逐项列明 |
| 缓冲 | 预留的波动余量 | 按历史波动设定 |
| 可承诺容量 | 名义产能减扣除项与缓冲 | 资源经理确认 |
完成标志：资源经理或职能负责人能按表复算出同样的数字，并对扣除项和缓冲比例达成一致。容量数字一旦确认，本规划周期内作为基准使用，临时变动单独记录。
第二步：估算候选项目的资源需求
需求侧要把候选项目折算成与容量同口径的分角色、分时段投入，才能做叠加比较。这一阶段允许使用粗略估算，关键是口径统一、假设写明。
输入：候选项目清单、每个项目的粗略规模（如需求数量、模块数、历史同类项目工作量）、阶段划分（如设计、开发、测试、上线）。
动作：按阶段拆解每个项目需要哪些角色，参考历史同类项目的投入比例估算人天；把各角色人天分布到项目时间轴上，识别每个项目的峰值时段。估算时标注假设，例如“按上一同类项目实际投入折算”或“按模块数乘以单模块均值”。
输出：项目资源需求表，每个候选项目一行或一组行，包含：
- 项目名称与优先级初判；
- 计划起止时间与关键阶段；
- 各角色需求人天；
- 峰值月份及峰值角色；
- 估算依据与主要假设。
完成标志：每个候选项目都有分角色需求量和明确的峰值时段，项目负责人对估算假设签字确认。没有需求数据的项目不进入后续对比，避免用空白数据做决策。
第三步：做容量与需求的情景对比
供需两侧数据齐备后，把它们放到同一时间轴上叠加，看哪些时段、哪些角色出现缺口。情景对比的作用是暴露约束位置，取舍决策留到下一步。
输入：容量基线表与项目资源需求表，两者使用相同的角色分类和时间粒度。
动作：先做基准情景：按当前全部候选项目叠加需求，逐月对比各角色需求量与可承诺容量，标出超载月份和缺口角色。再做乐观情景：假设部分项目提前完成或需求估算下浮，观察缺口是否缓解。再做保守情景：假设关键人员流失、需求上浮或交付延期，观察缺口扩大到哪里。每个情景都记录假设条件。
输出：容量情景对比表，按“情景—月份—角色”三个维度列出需求量、可承诺容量、缺口或余量。缺口用正数表示超出容量的人天，余量用负数或单独列表示。
| 情景 | 月份 | 角色 | 需求（人天） | 可承诺容量（人天） | 缺口/余量 |
|---|---|---|---|---|---|
| 基准 | 4月 | 后端开发 | 示例值 | 示例值 | 缺口示例值 |
| 保守 | 4月 | 测试 | 示例值 | 示例值 | 缺口示例值 |
完成标志：每个情景都能明确回答“哪些时段、哪些角色不够、缺口多大”。如果某个情景下所有月份所有角色都有余量，说明候选项目总量偏少或估算偏保守，需要复核需求数据。
第四步：在容量约束下确定承接项目
情景对比给出约束位置后，组合决策层据此决定本期承接哪些项目。取舍不是简单砍项目，而是在约束下寻找价值与可行性的平衡。
排序依据：建议按三个维度综合排序——战略价值（与年度目标的关联度）、交付紧迫性（合同节点、市场窗口、依赖关系）、容量匹配度（项目需求峰值是否落在容量余量区间）。三个维度可以打分，也可以由决策层逐项讨论，关键是排序理由可追溯。
取舍动作：对排序靠前且容量可容纳的项目，列入承接清单；对价值高但峰值冲突的项目，考虑推迟启动时间错开峰值，或缩减首期范围；对价值一般且占用紧缺角色的项目，推迟到下一周期；对必须交付但内部容量不足的项目，评估外部补充（外包、借调）的成本与可行性。
输出：组合承接清单与取舍记录。承接清单列明本期项目、计划起止时间、占用角色与峰值月份；取舍记录列明每个未承接或调整项目的理由，便于下一周期复盘。
完成标志：组合决策层确认承接清单，取舍原因写入记录，资源经理确认承接项目的峰值需求在容量范围内。决策记录是后续偏差复盘的依据，不能省略。
角色分工与各环节交付物
容量规划涉及四类角色，职责边界清晰，数据才能在环节之间顺畅传递。
| 角色 | 主要职责 | 负责的交付物 |
|---|---|---|
| PMO | 牵头规划流程、维护模板、汇总供需数据、组织情景测算与决策会 | 容量基线表汇总版、情景对比表、承接清单草案 |
| 资源经理/职能负责人 | 提供人员技能与可用工时数据，确认容量基线，承接项目后监控负荷 | 分角色可用容量表（确认版） |
| 组合决策层 | 依据情景结果拍板承接、推迟、缩减或外部补充 | 组合承接清单与取舍记录（签认版） |
| 项目负责人 | 提供候选项目的规模、阶段与分角色需求估算 | 项目资源需求表（含估算假设） |
PMO 是流程 owner，负责让三张表口径一致、按时汇总；资源经理对容量数字的真实性负责；项目负责人对需求估算的合理性负责；决策层对取舍结果负责。任何一方缺位，规划都会退化成单方面的数字游戏。
当容量基线和项目需求需要在多个项目、多个团队之间持续维护时，可以把这些数据沉淀到项目管理工具中。ONES 支持跨项目团队资源的规划，提供资源规划视图，管理者可以按业务优先级安排团队资源，并查看项目和团队的资源利用率与负荷度；工时登记数据支持多维度统计和导出，便于在规划周期结束后对比实际投入与估算。具体版本与部署方式需在选型时核验。
一个季度容量规划示例
以下为演示情景，数字为简化假设，用于说明推演过程，不代表任何真实团队的数据。
背景：某研发团队有后端开发 6 人、测试 4 人，规划下季度容量。候选项目三个：项目 A（核心系统升级，战略价值高，计划 4—6 月）、项目 B（客户定制功能，合同节点 5 月底）、项目 C（内部工具优化，价值中等，可延期）。
容量基线：后端开发名义产能按季度 6 人 × 60 个有效工作日 = 360 人天，扣除请假与管理事务 40 人天、非项目支持 30 人天，再留 10% 缓冲约 29 人天，可承诺容量约 261 人天。测试名义产能 4 人 × 60 = 240 人天，扣除项 50 人天，缓冲约 19 人天，可承诺容量约 171 人天。
需求叠加：项目 A 需后端 120 人天、测试 80 人天，峰值在 5 月；项目 B 需后端 90 人天、测试 70 人天，峰值在 5 月；项目 C 需后端 60 人天、测试 40 人天，峰值在 6 月。三个项目合计后端需求 270 人天，略超可承诺容量 261 人天；测试需求 190 人天，超过 171 人天。更关键的是 5 月后端与测试需求同时达到峰值，缺口集中在该月。
缺口识别与取舍：基准情景显示 5 月后端缺口约 15 人天、测试缺口约 20 人天。决策层按战略价值排序：项目 A 承接；项目 B 因合同节点必须交付，承接但缩减非核心范围，把部分测试工作前移到 4 月；项目 C 推迟到下一季度，错开 5 月峰值。调整后 5 月缺口收窄到容量缓冲可吸收的范围。取舍记录写明项目 C 推迟的原因为“峰值角色冲突，非价值不足”。
简化假设说明：示例未考虑人员技能交叉、外包补充和需求变更，实际规划中这些因素会改变缺口大小；缓冲比例和有效工时也需按团队实际情况调整。
规划落地后的检查与维护
一次规划完成后，用以下清单逐项核对，确认结果可用于决策。
- 口径一致：容量表与需求表使用相同的角色分类、时间粒度和工时定义，没有一边按人月、一边按人天的情况。
- 数据可复算：任一张表的汇总数字都能从明细复算出来，扣除项和缓冲比例有书面说明。
- 缺口有应对：每个识别出的缺口角色和超载时段，都对应承接、推迟、缩减或外部补充的具体动作，没有悬空的缺口。
- 决策有记录：承接清单和取舍记录经决策层确认，未承接项目的理由可追溯。
- 假设有标注：需求估算的依据和情景假设写明，便于后续判断偏差来源。
更新节奏：容量数据按季度刷新，与规划周期同步；出现重大项目变更、关键人员变动或合同节点调整时，触发临时刷新，只更新受影响的角色和时段，避免全量重算。
偏差复盘：规划周期结束后，把实际投入与需求估算逐项目对比，记录偏差方向和幅度。偏差持续偏高的角色，下一轮估算时调整系数；偏差集中在某类项目，说明估算方法需要细化。复盘结果反馈到下一轮容量基线和需求估算中，规划精度会随周期逐步提高。
常见问题
容量基线和项目需求估算的精度要求有多高，粗略估算能用吗？
可以用粗略估算，前提是两侧口径一致。容量基线按角色或技能统计，时间粒度统一到月或季度；项目需求按同一角色分类和同一时间粒度估算人天，并写明估算依据，例如按历史同类项目投入折算或按模块数乘以单模块均值。精度不足的风险主要来自口径不一致，而不是估算本身粗糙。若某个候选项目连分角色需求量和峰值时段都给不出，建议先不纳入本轮对比，等需求数据补齐再决策。
缓冲比例应该设多少，有没有通用标准？
没有统一标准，缓冲比例取决于团队历史波动情况。可以参考过去几个周期实际投入与计划的偏差幅度、返工和临时支持工作的占比来设定，并在每轮复盘时调整。缓冲设得过低，容量表看起来饱满，实际执行中容易被临时事务挤占；设得过高，会低估可承接能力，把本可承接的项目推迟。建议在容量基线表中单独列出缓冲字段，写明设定依据，便于资源经理确认和后续复算。
多个候选项目的峰值集中在同一个月时，除了推迟项目还有哪些处理方式？
常见处理方式有四类：一是错开启动时间，把峰值不在关键月份的项目提前或推后；二是缩减首期范围，把非核心功能移出本期，降低峰值需求；三是调整工作顺序，例如把部分测试工作前移到峰值前的月份；四是评估外部补充，如外包或借调，需同时核算成本与上手周期。选择哪种方式取决于项目的战略价值、交付紧迫性和容量匹配度，决策理由应写入取舍记录，便于下一周期复盘。
容量规划多久做一次，中途出现人员变动怎么办？
常规节奏是按季度刷新，与规划周期同步。出现重大项目变更、关键人员变动或合同节点调整时，触发临时刷新，只更新受影响的角色和时段，避免全量重算。临时刷新后要同步检查承接清单是否仍然成立，若缺口超出缓冲可吸收范围，需要重新做一次小范围取舍。规划周期结束后，把实际投入与估算逐项目对比，偏差持续偏高的角色在下一轮估算时调整系数。
容量规划的数据放在表格里维护，还是放到项目管理工具中？
取决于规划涉及的团队和项目数量。单一团队、候选项目较少时，用表格维护三张表即可满足复算和对比需求。当容量基线和项目需求需要在多个项目、多个团队之间持续维护时，放到项目管理工具中更便于数据同步和追溯。ONES 支持跨项目团队资源的规划，提供资源规划视图，管理者可以按业务优先级安排团队资源，并查看项目和团队的资源利用率与负荷度；工时登记数据支持多维度统计和导出，便于规划周期结束后对比实际投入与估算。具体版本与部署方式需在选型时核验。
