项目组合容量评估要回答的是“在给定周期内，团队能承接哪些项目、哪些需要取舍”。支撑这个判断的依据可以归为五类：候选项目及投入估算、各角色可用工时与技能分布、评估周期与排期窗口、预算与依赖等硬约束、统一的估算单位与数据来源。本文按“先定口径、再收需求与供给、纳入约束、做情景对比、明确分工、最后检查”的顺序展开，适用于季度或半年度组合规划场景，不涉及已选项目之间的人员冲突协调。
要点总览（TL;DR）
- 项目组合容量评估的依据分五类：候选项目与投入估算、各角色可用工时与技能分布、评估周期与排期窗口、预算与依赖等硬约束、统一的估算单位与数据来源。
- 评估顺序是先锁定周期与口径，再汇总需求与供给，纳入约束后做情景对比，最后输出可承接项目清单与缺口清单。
- 需求与供给必须使用同一估算单位和折算规则，并按角色比对；总量够但关键角色不够，同样构成缺口。
- 结论要写明所依据的情景和假设，低置信度项目单独列出，避免用不确定数字挤占确定项目的容量。
- 评估前用完成检查清单核对数据完整性、口径一致性和约束覆盖情况，不通过项应补充数据或注明限制条件。
容量评估先定周期与口径
容量评估最常见的失败原因是需求用“人月”、供给用“人天”，或者需求按自然月统计、供给按工作日统计，导致两边数字无法直接相减。因此在收集任何数据之前，先锁定两件事：评估覆盖的时间范围，以及所有数据的计量单位。
评估周期通常与项目排期窗口对齐。例如按季度评估时，需要明确周期起止日期、周期内可用于项目交付的工作日数量，以及跨周期项目的投入如何切分——是只计本周期部分，还是按里程碑整体计入。周期一旦确定，后续需求估算和供给统计都以此为边界，中途不随意调整。
计量口径需要统一三方面内容：估算单位、折算规则、数据来源。估算单位可选人天、人月或故事点，选择哪种取决于团队已有的估算习惯，关键是需求侧和供给侧使用同一单位。折算规则用于处理单位换算和工时定义，例如一人天按多少小时计、故事点与工时的换算系数、兼职成员投入比例如何折算。数据来源则要指定唯一出处，避免同一角色在不同表格里出现两个数字。
| 口径项 | 需要明确的内容 | 示例写法 |
|---|---|---|
| 评估周期 | 起止日期、有效工作日、跨周期项目处理方式 | 2025年Q2，4月1日至6月30日，共64个工作日 |
| 估算单位 | 人天、人月或故事点，需求与供给一致 | 统一使用人天 |
| 折算规则 | 工时定义、兼职折算、单位换算系数 | 1人天=8小时；50%投入成员按0.5人天/日计 |
| 数据来源 | 需求与供给数据各自的唯一出处 | 需求取项目立项估算表，供给取资源排期表 |
这张口径说明表应在评估启动时由组合管理者确认并分发给所有数据提交方，作为后续汇总和对比的唯一基准。
需求侧依据：候选项目与投入估算
需求侧依据的核心是一张组合需求汇总表，它把本周期内所有候选项目的投入折算成与口径一致的单位，并按角色拆分。没有这张表，容量评估只能停留在“感觉人手紧张”的层面。
汇总表至少包含以下数据项：项目名称与编号、所属业务线、优先级、计划起止时间、按角色拆分的投入估算（如后端多少人天、测试多少人天、产品多少人天）、估算依据与置信度、待确认事项。优先级用于在容量不足时决定取舍顺序，按角色拆分则是为了与供给侧的技能分布对齐——总量够但某个角色不够，同样构成缺口。
估算方法上，处于立项阶段的项目可采用类比估算或专家判断，已有明确范围的项目可采用自下而上的任务分解。无论哪种方法，都要标注置信度：高置信度表示范围清晰、有历史数据支撑；中置信度表示存在部分待确认需求；低置信度表示仅有意向、范围可能大幅变化。低置信度项目在情景对比中应单独列出，避免用不确定的数字挤占确定项目的容量。
待确认项要具体记录，例如“第三方接口方案未定，可能增加联调投入”“测试环境到位时间未确认”。这些标注让评审者知道哪些数字可能变化、变化方向如何，而不是把一个估算值当作确定事实使用。
供给侧依据：可用人力与技能分布
供给侧依据是一张可用容量基线表，回答“本周期内各角色实际能投入多少”。它与人员花名册的区别在于：花名册记录的是人数，容量基线记录的是可投入工时，并且已经扣除了不可用于项目交付的时间。
可用工时的计算从周期内工作日总数出发，逐项扣减：法定节假日与团队统一休假、个人年假与调休计划、培训与认证时间、内部会议与例行事务、已承诺的运维和支持工作。扣减后的结果才是可用于候选项目的净容量。扣减项要基于已提交的请假单和培训计划，而非粗略估计比例，否则基线会系统性偏高。
技能分布是供给侧的第二个维度。同样是人天，资深架构师和初级开发的可替代性不同。基线表应按关键角色和稀缺技能分组统计，例如按前端、后端、测试、数据、架构等角色列出可用人天，并对只有个别人掌握的关键技能单独标注。稀缺技能对应的容量上限往往就是组合的瓶颈，需要在约束环节重点处理。
外部资源与外包的可用性也要纳入基线：外包团队的合同周期、进场时间、可承担的工作范围、与内部团队的协作成本。外部资源不能简单按人数计入，要确认其在本周期内实际可交付的时间和技能匹配度。
| 角色 | 人数 | 周期工作日 | 扣减项合计 | 净可用人天 | 备注 |
|---|---|---|---|---|---|
| 后端开发 | 6 | 64 | 请假与培训约120人天 | 约264人天 | 含1名兼职成员按0.5折算 |
| 测试 | 3 | 64 | 请假与支持工作约60人天 | 约132人天 | 自动化测试技能仅1人掌握 |
| 产品 | 2 | 64 | 会议与调研约40人天 | 约88人天 | — |
表中数字为演示性假设，实际评估应以团队提交的排期与请假数据为准。
约束依据：预算、依赖与瓶颈岗位
需求与供给都算清楚之后，还有一类依据决定“即使容量够也不能全接”：硬约束。约束清单把这类限制显性化，避免在情景对比中得出过于乐观的结论。
预算与采购周期约束包括：本周期可用于新增人力的预算额度、外部采购的审批与到货周期、需要提前锁定的许可证或服务。如果某个项目依赖尚未获批的预算，它的投入在预算落地前不能计入可承接范围。跨团队依赖与外部交付节点包括：依赖其他团队提供的接口、数据或环境，依赖供应商的交付时间，依赖客户侧的验收安排。这些节点如果晚于项目排期窗口，项目即使人力充足也无法按期完成。
瓶颈岗位的容量上限需要单独列出。当某个关键角色（如架构评审、安全测试、数据库管理）的可用人天远低于需求总量时，这个角色就是组合的硬上限。处理方式有两种：在情景对比中按瓶颈角色截断可承接范围，或者把缓解措施（外部支持、流程简化、错峰安排）作为待确认项列入结论。
约束清单建议逐条记录：约束类型、影响的项目、影响方式、当前状态、责任人与确认时间。状态分为已确认、待确认、已解除，评审时优先处理待确认项。
情景评估：做需求与供给的对比
情景评估把前四类依据放到同一张表里比较，输出可承接项目清单和缺口清单。操作上分三步：设置情景、按角色比对、形成结论。
第一步，设置基准情景与增减情景。基准情景按当前已确认的需求和供给计算，作为对比起点。增减情景用于回答“如果……会怎样”，常见设置有：优先级最高的项目全部承接、增加一个外部资源、某关键成员请假延长、某项目范围缩减。情景数量控制在两到三个，每个情景只改变一到两个变量，便于归因。
第二步，按角色比对需求与供给。把需求汇总表中各角色的投入合计，与可用容量基线表中对应角色的净可用人天相减，得到每个角色的缺口或余量。总量层面的对比只能作为参考，角色层面的缺口才是取舍依据。比对时注意单位一致，并把低置信度需求单独标注。
| 角色 | 需求合计（人天） | 净可用（人天） | 缺口/余量 | 说明 |
|---|---|---|---|---|
| 后端开发 | 300 | 264 | -36 | 缺口集中在两个高优先级项目 |
| 测试 | 120 | 132 | +12 | 自动化测试为瓶颈技能 |
| 产品 | 100 | 88 | -12 | 可通过延后低优先级项目缓解 |
第三步，输出结论。可承接项目清单列出在基准情景下容量可以覆盖的项目；待取舍清单列出因角色缺口或硬约束无法全部承接的项目，并注明取舍依据（优先级、依赖节点、预算状态）。缺口清单按角色和技能列出缺口数量、影响的项目、可选缓解措施。结论要写明所依据的情景和假设，便于后续复盘时判断偏差来源。
当评估依赖的项目清单、投入估算和资源排期需要持续维护时，可以把这些数据放在统一的项目管理工具中。ONES 的资源与工时管理支持跨项目团队资源规划，查看项目和团队的资源利用率及负荷度，并多维度统计项目和成员的资源投入情况，便于在评估周期内保持需求与供给数据同源。
角色分工与交付物
容量评估的依据要可追溯，前提是每个数据项都有明确的提交人和提交时间。角色分工不必复杂，但要覆盖数据产生、汇总、评审三个环节。
| 角色 | 职责 | 提交物 | 时间点 |
|---|---|---|---|
| 组合管理者 | 锁定评估周期与口径，组织评审，输出最终结论 | 口径说明表、情景对比表、可承接项目清单 | 评估启动时发布口径，评审后输出结论 |
| 项目经理 | 提交候选项目的投入估算与优先级建议 | 项目投入估算表（含置信度与待确认项） | 数据收集截止日前 |
| 资源负责人 | 统计各角色可用工时、技能分布与外部资源情况 | 可用容量基线表 | 数据收集截止日前 |
| 财务 | 提供预算额度、采购周期与已承诺支出 | 预算与采购约束说明 | 数据收集截止日前 |
评审与确认机制建议分两步：先由组合管理者核对数据完整性和口径一致性，退回缺项或单位不一致的提交；再组织项目经理、资源负责人、财务共同评审情景对比结果，对缺口清单中的缓解措施逐条确认责任人和完成时间。评审结论形成书面记录，作为下一周期评估的基线。
示例：一个季度的容量评估
以下示例为演示情景，数据为假设值，用于说明评估过程而非真实案例。
某研发组织按季度做组合容量评估。本季度有效工作日64天，统一使用人天作为估算单位。需求侧汇总了5个候选项目：A项目优先级最高，后端需120人天、测试50人天；B项目后端需100人天、测试40人天；C项目后端需80人天、测试30人天；D和E为低置信度意向项目，合计后端约60人天。后端需求合计约360人天，测试需求合计约120人天。
供给侧基线显示：后端净可用264人天，测试净可用132人天，产品净可用88人天。约束清单记录了两项硬约束：B项目依赖外部供应商在5月中旬交付接口，若延期则B项目本季度只能完成部分范围；测试团队中自动化测试仅1人掌握，该技能容量上限约40人天。
情景对比结果：基准情景下后端缺口约96人天，测试有余量。按优先级排序，A项目和B项目的后端需求合计220人天，在264人天容量内可以承接；C项目后端需求80人天，超出剩余容量，列入待取舍清单。测试侧容量充足，但自动化测试技能上限限制了部分测试工作的并行度，需要在排期中错峰。D和E作为低置信度项目不占用基准容量，在增减情景中单独评估。
结论：本季度可承接A、B两个项目，C项目延后或缩减范围，D、E待范围明确后重新评估。B项目的供应商交付节点列为跟踪项，若5月中旬未交付，则触发范围调整。该结论连同假设条件一并记录，供季度末复盘。
完成检查：依据是否齐全可用
评估结论提交评审前，用以下清单逐项核对。任何一项不通过，都应补充数据或调整结论，而不是带着缺口进入决策。
- 评估周期、有效工作日、跨周期项目处理方式已书面确认，所有提交方使用同一版本。
- 需求与供给使用同一估算单位和折算规则，抽查两到三个项目的数据可以复算。
- 候选项目清单完整，每个项目有优先级、按角色拆分的投入估算和置信度标注。
- 可用容量基线已扣减请假、培训、例行事务和已承诺工作，扣减项有依据。
- 关键角色和稀缺技能已单独列出，瓶颈岗位的容量上限已明确。
- 预算、采购周期、跨团队依赖和外部交付节点已纳入约束清单，待确认项有责任人和确认时间。
- 情景对比至少包含基准情景和一个增减情景，角色层面的缺口或余量已计算。
- 可承接项目清单和待取舍清单均有取舍依据，低置信度项目未被当作确定需求占用容量。
- 结论中写明了所依据的假设和情景，数据来源可追溯，评审记录已归档。
清单全部通过，说明本次评估的依据满足决策需要；若部分项因客观原因无法满足，应在结论中注明限制条件及其对判断的影响范围。
常见问题
评估周期跨月或跨季度时，项目投入应该怎么切分？
常见做法有两种：只计本周期内实际发生的投入，或按里程碑整体计入。选择哪种取决于评估目的——判断本周期能承接多少工作时，按周期内投入切分更准确；判断项目整体能否启动时，可按里程碑计入。无论哪种，都要在口径说明表中写明规则，并在所有项目中一致执行，避免同一批数据里两种算法混用。
候选项目估算置信度低，是否应该直接排除在容量评估之外？
不必排除，但要区别对待。低置信度项目可以列入需求汇总表，在基准情景中不占用容量，放到增减情景中单独评估。这样既保留了项目信息，又避免不确定的估算值挤占确定项目的资源。同时要记录待确认事项和预计确认时间，等范围明确后重新纳入基准情景。
关键角色容量不足但总量有余量，评估结论应该怎么给？
按瓶颈角色截断可承接范围，而不是按总量判断。具体做法是在情景对比表中单独列出该角色的需求与供给差额，把受其影响的项目列入待取舍清单，并注明缓解措施：外部支持、流程简化、错峰安排或范围缩减。缓解措施要明确责任人和完成时间，作为待确认项跟踪，确认后再调整结论。
评估所需数据分散在多个表格中，如何保证需求与供给同源？
关键是给每类数据指定唯一出处，并在口径说明表中写明。需求侧取项目立项估算表，供给侧取资源排期表，预算约束取财务提供的额度说明，避免同一角色在不同表格里出现两个数字。当项目清单、投入估算和资源排期需要持续维护时，可以把这些数据放在统一的项目管理工具中。ONES 的资源与工时管理支持跨项目团队资源规划，查看项目和团队的资源利用率及负荷度，并多维度统计项目和成员的资源投入情况，便于在评估周期内保持数据同源。
评估结论在什么情况下需要重新做？
出现以下变化时应触发重评：候选项目范围或优先级大幅调整、关键成员长期缺位、预算审批结果与假设不符、外部依赖节点延期。重评不必全量重做，可以只更新变化的数据项，重新跑一遍情景对比，并在结论中注明与上一版的差异及原因，保持评估记录可追溯。
