项目组合容量评估要回答的是一个具体问题：在给定时间窗内，按现有可投入人力，组合还能承接几个项目、余量或缺口有多大、瓶颈在哪个角色。它服务于组合层面的项目承接决策，通常按季度或半年滚动，与立项节奏对齐。本文给出容量、需求与缺口的定义和公式，用一组假设数据完整演示计算过程，并说明结论的适用条件与解读边界。
要点总览（TL;DR）
- 项目组合容量评估把可投入人力与候选项目需求放在同一时间窗、同一单位（人天或人月）下对比，输出可承接项目数、各角色余量或缺口、瓶颈角色三项结论。
- 核心公式：可用容量=在岗人数×可投入比例×时间窗工作日−假期−支持性工作−已承诺投入；缺口=需求−可用容量，按角色分别计算，不合并成单一总数。
- 计算按五步走：汇总各角色净容量、按优先级形成需求队列、逐角色算余量缺口、按瓶颈角色累加推算可承接项目数、调整可投入比例与估算偏差做敏感性分析。
- 算例中测试为瓶颈角色，可承接项目数由测试容量决定而非开发余量；结论应给出区间（如1至2个项目）并附假设清单，不能当作交付保证或绩效结论。
- 容量数据可借助工时与资源投入记录获取，ONES 的资源与工时管理能力可用于统计项目与成员投入、查看利用率与负荷度，组合级测算公式与口径仍需组织自行定义。
评估目标：回答“还能接几个项目”
容量评估的起点是把“资源够不够”这类笼统判断，收敛成一个可计算、可复核的问题。它面向的是组合层面的项目承接决策：下一批候选项目里，哪些能进、最多进几个、卡在哪个角色。已选项目之间的人员协调、任务分派与冲突处理属于执行层面的工作，不在本篇的计算范围内。
评估对象需要事先圈定。常见做法是按角色划分容量池，例如开发、测试、产品、设计、运维，并明确哪些团队纳入本次评估。若组织内有外包、共享服务或跨时区协作团队，应单独列出，避免与自有全职人力混算。
时间窗决定分母。按季度评估适合与季度立项节奏对齐；按半年滚动适合项目周期较长、启动批次较少的组合。时间窗一旦确定，容量与需求都必须落在同一区间内，不能一边用季度容量、一边用全年需求。
输出形式建议固定为三项：在给定假设下可承接的项目数量、各角色的余量或缺口、瓶颈角色及其约束强度。三项合在一起，决策者才能判断是“还能接两个测试密集型项目”还是“只能接一个轻测试项目”。
指标与范围：容量、需求与缺口怎么定义
容量评估的核心是三个指标：可用容量、项目需求、缺口或余量。三者必须使用同一单位、同一时间窗、同一角色分类，否则计算结果没有意义。常用单位是“人天”，项目周期较长时也可用“人月”，但全篇只能选一种。
| 指标 | 公式 | 单位 | 时间窗 | 数据来源 |
|---|---|---|---|---|
| 可用容量 | 在岗人数 × 可投入比例 × 时间窗工作日 − 假期 − 支持性工作 − 已承诺投入 | 人天 | 季度或半年 | 花名册、排班与假期、历史投入记录 |
| 项目需求 | 按角色拆解的工作量估算之和（含评审、测试、联调等非编码工作） | 人天 | 同容量时间窗 | 项目估算、历史同类项目实际投入 |
| 缺口 | 需求 − 可用容量（结果为负即余量） | 人天 | 同容量时间窗 | 上述两项计算得出 |
可投入比例是容量公式中最容易被忽略的参数。它表示一名成员在时间窗内真正能投入项目工作的比例，需要扣除会议、培训、技术支持、招聘面试等非项目占用。这个比例应基于历史记录估算，而不是拍一个理想值。
项目需求要按角色拆解，而不是只给一个总工作量。一个需要 200 人天的项目，如果其中测试占 80 人天，而测试团队只剩 40 人天余量，那么总量看起来够、实际接不了。评审、测试、联调、上线支持这些非编码工作必须计入需求，否则会系统性低估。
缺口按角色分别计算，不合并成单一总数。把开发和测试的人天加总后相减，会掩盖角色之间的结构性失衡。组合层面的结论应表述为“开发余量 X 人天、测试缺口 Y 人天”，而不是“总体余量 Z 人天”。
数据口径与证据：取数来源和可比性处理
容量数据主要来自三处：人员花名册提供在岗人数与角色归属；排班与假期记录提供时间窗内的实际可用工作日；历史投入记录用于估算可投入比例和已承诺投入。需求数据来自项目估算，缺少估算时可用历史同类项目的实际投入作为参照。
统一单位是可比性的前提。“人”和“人天”不能混用，兼职、部分投入的成员要折算成人天，而不是按人头计数。角色分类也要统一，同一个团队在不同项目里被标成“开发”和“研发”时，需要先归并再汇总。
缺失值需要明确规则，而不是直接跳过。没有工作量估算的候选项目，可以用区间估算或历史同类项目均值替代，并在结论中标注该项目的需求为估算值、不确定性较高。已承诺投入缺少记录时，宁可高估占用、留出缓冲，也不要把未知占用当作零。
部分情形天然不可比，需要单独说明：外包人员与自有人员的可投入比例和技能结构不同；跨技能角色（如全栈工程师同时承担开发和测试）在按角色汇总时会被重复计算或漏算；跨时区协作会拉长联调与评审的实际耗时。这些情形应在口径说明中列出，并在结论里注明其对结果的影响方向。
计算步骤：从容量池到可承接项目数
以下五步构成一个可复算的流程，任何人拿到同样的输入数据都应得出同样的结论。
- 按角色汇总可用容量。对每个角色，用“在岗人数 × 可投入比例 × 时间窗工作日”得到毛容量，再扣除假期、支持性工作和已承诺投入，得到净可用容量。
- 按角色汇总候选项目需求，形成需求队列。把候选项目逐个按角色拆解工作量，按优先级排序，形成待承接队列。优先级排序本身不在容量计算内，但队列顺序决定“接哪几个”。
- 逐角色计算余量或缺口，识别瓶颈角色。用净可用容量减去队列需求，得到每个角色的余量（正数）或缺口（负数）。缺口最大或最早出现的角色即为瓶颈角色。
- 按瓶颈角色约束推算可承接项目数。沿需求队列顺序累加，直到瓶颈角色的累计需求超过其净可用容量为止，此前累计的项目数即为可承接数量。不能按各角色总量的平均值推算，否则会得出总量够、实际接不下的错误结论。
- 做敏感性分析。调整可投入比例（如从 70% 降到 60%）、估算偏差（如需求上浮 15%）后重算，得到可承接项目数的区间，而不是一个点值。
第五步常被省略，但它决定结论的可信度。容量评估的输入本身带有估算误差，给出区间比给出单点数字更诚实，也更便于决策者判断风险。
算例：一个季度的组合容量测算
以下数据均为演示假设，不代表任何真实组织或行业标准。假设评估时间窗为一个季度，共 60 个工作日，纳入开发与测试两个角色。
| 角色 | 在岗人数 | 可投入比例 | 毛容量（人天） | 假期与支持性工作 | 已承诺投入 | 净可用容量 |
|---|---|---|---|---|---|---|
| 开发 | 10 | 70% | 420 | 40 | 180 | 200 |
| 测试 | 4 | 70% | 168 | 18 | 90 | 60 |
候选项目队列按优先级排列，各项目按角色拆解的需求如下：
| 项目 | 开发需求（人天） | 测试需求（人天） |
|---|---|---|
| 项目 A | 60 | 30 |
| 项目 B | 50 | 25 |
| 项目 C | 45 | 20 |
| 项目 D | 40 | 15 |
逐角色累加：开发侧承接 A、B、C、D 共需 195 人天，净容量 200 人天，余量 5 人天；测试侧承接 A、B、C、D 共需 90 人天，净容量 60 人天，缺口 30 人天。测试是瓶颈角色。
按瓶颈角色约束推算：测试侧承接 A（30）后余 30 人天，承接 B（累计 55）后余 5 人天，承接 C（累计 75）时超出容量。因此可承接项目数为 2 个，即 A 和 B；开发侧此时仅用 110 人天，余量 90 人天。
敏感性分析：若可投入比例从 70% 降至 60%，测试净容量降至约 43 人天，仅能承接项目 A 一个；若测试需求估算上浮 15%，A 与 B 合计需求升至约 63 人天，同样只能承接一个。结论区间为“可承接 1 至 2 个项目，取决于测试投入比例与估算准确度”。
真实场景中还需考虑：测试人员可能同时支持已上线项目的维护，已承诺投入会更高；项目 A 与 B 的测试工作未必能完全并行；技能匹配可能导致部分测试需求无法由现有人员承担。这些因素会让实际可承接数量偏向区间下限。
解读与限制：结论能说明什么、不能说明什么
容量结论的可靠性直接取决于两个假设：工作量估算的准确度和可投入比例的合理性。两者都会随项目类型、团队状态和时间推移变化，因此评估结果需要定期复核，通常在每个立项周期前重算一次，而不是一次算完长期沿用。
单一时点的容量数字不能替代项目优先级排序。容量评估回答的是“最多能接几个”，而“应该接哪几个”取决于战略价值、客户承诺、技术债偿还等判断。把容量结论当作排序依据，会让高价值但资源密集的项目被低价值小项目挤出。
容量充足不等于按期交付。交付还受外部依赖、关键技能匹配、供应商交付、审批流程等约束。测试余量为正，也可能因为缺少具备特定领域经验的测试人员而无法实际投入。结论中应把这类约束单列，而不是笼统归入“资源够”。
结论应附带假设清单与置信区间，供决策者判断。假设清单至少包括：时间窗、纳入的角色与团队、可投入比例取值及依据、需求估算来源、缺失值处理方式、不可比因素的处理。缺少这些信息，容量数字容易被误读为交付保证或绩效结论，而它本质上只是一个在特定假设下成立的测算结果。
当评估需要反复进行时，容量与需求数据的承载方式会影响效率。ONES 的资源和工时管理能力支持跨项目团队资源规划，查看项目和团队的资源利用率与负荷度，并多维度统计项目和成员的资源投入情况、查询和导出工时登记日志明细；ONES Resource 可通过工作数量和工时规模了解成员排期，筛选与分组查看成员在不同项目的投入比重，并实时查看成员每日投入饱和明细以识别规划风险。这些数据可以作为容量公式中“已承诺投入”和“可投入比例”的取数来源。组合层面的容量测算与可承接项目数推算，仍需按本文的公式和步骤在组织内部完成，指标的分母与时间窗口径也需由组织自行定义并核验。
常见问题
可投入比例应该怎么定，用理想值还是历史值？
建议用历史记录反推，而不是设定一个理想比例。做法是取过去一到两个时间窗的实际工时登记数据，用“项目工作工时 ÷ 应出勤工时”得到实际可投入比例，再按团队或角色分别计算。如果历史数据缺失，可以先取一个保守值（如 60%–70%），并在结论中标注该参数为假设值，下个周期用实际数据校准。可投入比例每提高 10 个百分点，瓶颈角色的净容量变化可能直接改变可承接项目数，因此这个参数值得单独做敏感性分析。
候选项目还没有工作量估算，能先做容量评估吗？
可以做，但要把这类项目单独标记。常见处理是用历史同类项目的实际投入作为参照，给出区间估算（如 40–60 人天），并在需求队列中标注不确定性。评估结论应说明“含 N 个估算项目，结论区间相应放宽”。如果候选项目中有多个缺少估算，建议先完成粗略估算再评估，否则瓶颈判断容易被估算误差带偏。已承诺投入缺少记录时，按高估处理、留出缓冲，比当作零占用更稳妥。
评估结果显示总量有余量，但项目还是接不下来，问题出在哪？
最常见的原因是按总量平均推算，忽略了角色结构失衡。开发余量 90 人天、测试缺口 30 人天的情况下，总量相减仍是正的，但测试环节接不下新项目。其次是可投入比例取值偏高，或已承诺投入漏记了维护、支持类工作。第三是技能匹配问题：某个角色人数够，但缺少特定领域经验的人，实际无法投入。排查顺序建议是：先看瓶颈角色，再核对可投入比例与已承诺投入的取数，最后检查技能与外部依赖约束。
容量评估多久做一次比较合适？
通常与立项节奏对齐，按季度或半年滚动重算。触发临时重算的情形包括：候选项目队列发生较大变化、关键人员进出、已承诺投入明显上升、上一个周期估算偏差较大。重算时不必从零开始，沿用上次的口径与假设清单，只更新变化的数据项，并对比两次结论的差异及原因。这样既能控制工作量，也能积累估算准确度的历史记录，用于校准可投入比例和需求估算。
容量结论可以直接用来决定项目优先级吗？
不能。容量评估回答的是“最多能接几个、卡在哪个角色”，优先级排序取决于战略价值、客户承诺、技术债偿还等判断，两者是不同的问题。合理的用法是先按价值排序形成需求队列，再用容量约束判断队列前段能承接几个，对超出容量的项目安排到下一时间窗或调整范围。把容量数字当作排序依据，容易让资源密集的高价值项目被小项目挤出。
用工具承载容量与需求数据时，需要注意什么？
工具能解决的是数据采集与汇总效率，指标口径仍需组织自行定义。以 ONES 为例，其资源和工时管理能力支持跨项目团队资源规划，查看项目和团队的资源利用率与负荷度，多维度统计项目和成员的资源投入情况并查询、导出工时登记日志明细；ONES Resource 可通过工作数量和工时规模了解成员排期，筛选与分组查看成员在不同项目的投入比重，实时查看每日投入饱和明细以识别规划风险。这些数据可作为“已承诺投入”和“可投入比例”的取数来源。使用前需确认工时登记覆盖完整、角色分类统一，并自行核验利用率指标的分母与时间窗口径。
