项目承接需求超过团队可用容量时，处理顺序是先把缺口算清，再决定承接范围。具体做法是按角色和技能核算所需工时与可用工时，得出可比较的缺口数字；据此对候选项目排序，通过裁剪范围或分阶段交付降低峰值占用，对暂缓项目写明挂起条件和重启触发点；最后把容量校验、审批门槛和复盘节奏固定下来。本文聚焦”承接哪些项目”这一层决策，已承接项目之间的人员协调不在讨论范围内。
要点总览（TL;DR）
- 先按角色和技能核算可用工时与候选项目所需工时，用同一时间窗口对齐，得到每个关键角色的缺口数字，作为取舍依据。
- 缺口确定后按战略贡献、交付风险、资源占用、时间敏感性排序，对高占用项目做范围裁剪或阶段切分，把峰值压回可用容量之内。
- 暂缓项目要写明挂起原因、保留动作和可观察的重启触发点，并指定跟踪人，避免搁置后无人跟进。
- 把容量校验设为承接审批门槛，配合定期复盘更新基线、设定超载预警条件，才能避免下一轮重复超载。
- 处理是否到位可用四项检查判断：缺口覆盖关键角色、清单有决策依据、暂缓有重启条件、机制落到审批与复盘。
先算清容量缺口：所需与可用的统一口径
容量缺口是后续所有取舍的依据，算法本身不复杂，难点在于所需与可用必须用同一套口径。常见错误是可用侧只数人头，所需侧却按理想投入估算，结果缺口被系统性低估。正确做法是按角色或技能分别核算，并把时间窗口对齐到同一个周期，例如一个季度或一个交付批次。
可用容量怎么算
可用容量指某角色在统计周期内真正能投入项目交付的工时。计算时从名义工时出发，逐项扣除：法定假期与计划休假、培训与内部会议、运维支持与线上问题处理等支持性工作、已承诺项目的占用。扣除后剩余的部分才是可分配给新承接项目的容量。按角色分开统计，是因为后端、前端、测试、特定领域专家的可替代性差异很大，总人数够不代表关键角色够。
所需容量怎么估
把每个候选项目拆到关键角色和主要阶段，分别估算投入。估算粒度到”角色×阶段”即可，例如某项目在需求与设计阶段需要后端 40 人时、测试阶段需要测试工程师 60 人时。估算时注明假设条件，例如是否包含缺陷修复、是否依赖外部团队配合，便于后续复核。对不确定性高的项目，给出区间而非单点数字。
对齐窗口得出缺口
把各候选项目的所需工时按阶段落到同一时间窗口，与对应角色的可用工时相减，得到每个角色的缺口。缺口为正表示该角色超载，为负表示有余量。下表是一张可直接套用的核算表结构：
| 角色 | 可用工时（人时） | 候选项目所需工时 | 缺口 | 说明 |
|---|---|---|---|---|
| 后端工程师 | 已扣除休假、支持性工作与在途项目占用 | 各候选项目本阶段需求之和 | 所需减可用 | 标注估算假设与区间 |
| 测试工程师 | 同上口径 | 同上 | 所需减可用 | 注意测试阶段峰值集中 |
| 领域专家 | 同上口径 | 同上 | 所需减可用 | 可替代性低，需单独看 |
完成标志是：每个关键角色都有一行缺口数字，且所需与可用使用同一时间窗口、同一工时单位。这张表就是取舍决策的输入。
超出容量时的取舍步骤：排序、裁剪与暂缓
缺口确定后，决策目标是在容量约束内选出本期承接的项目组合，并让未承接的项目有明确的后续安排。整个过程分三步：排序、裁剪、暂缓。
第一步：对候选项目排序
排序标准建议固定为几项可比较的维度：战略贡献（与年度目标的关联度）、交付风险（技术不确定性、依赖外部条件）、资源占用（尤其关键角色的占用）、时间敏感性（是否有合同或市场窗口约束）。每项给出粗粒度评级即可，不必追求精确打分。排序结果要形成书面记录，写明每个项目的入选或落选理由，便于后续复盘和向相关方解释。
第二步：对可裁剪项目做范围或阶段切分
排序靠前但资源占用过大的项目，优先考虑裁剪而非直接放弃。常见做法包括：把非核心功能移到后续版本，本期只交付最小可用范围；把项目拆成阶段，本期只启动需求与设计，开发阶段排到下一窗口；调整交付节奏，把测试峰值错开到容量有余量的时段。裁剪后重新核算所需工时，确认峰值占用落到可用容量之内。
第三步：对暂缓项目写明挂起条件与重启触发点
暂缓不等于搁置不管。每个暂缓项目需要记录三项内容：挂起原因（哪个角色缺口、缺多少）、挂起期间的保留动作（如保留需求澄清、技术预研）、重启触发点（如某角色释放出约定工时、上一阶段项目进入维护期、预算窗口开启）。触发点要具体到可观察的事件或数字，避免写成”条件成熟时再启动”。
本步的交付物是两份清单：本期承接清单，含项目范围、关键角色投入和交付节点；暂缓清单，含挂起原因与重启触发点。两份清单共同构成对相关方的正式答复。
角色分工与交付物：谁核算、谁决策、谁跟踪
容量管理容易失效的环节是职责不清：核算的人不掌握项目信息，决策的人看不到缺口细节，跟踪的人没有权限调整。把三个角色和对应交付物定清楚，流程才能稳定运转。
| 角色 | 主要输入 | 输出交付物 |
|---|---|---|
| 资源核算人（如资源经理或项目管理办公室成员） | 人员排班与休假记录、在途项目占用、候选项目估算 | 容量缺口核算表、估算假设说明 |
| 组合决策人（如研发负责人或组合管理委员会） | 缺口核算表、项目排序结果、业务方诉求 | 承接清单、暂缓清单、决策记录 |
| 项目负责人 | 承接清单中的范围与投入约定 | 项目内资源计划、偏差上报、阶段完成确认 |
决策记录与变更留痕是这套分工的关键约束。承接范围调整、暂缓项目重启、估算假设变化，都应记录变更时间、原因和批准人。留痕的目的在于让下一轮核算有据可查，也让超载原因可以追溯到具体决策，而非停留在”大家都觉得很忙”。
当候选项目、估算和决策记录分散在多个表格和邮件中时，核算与决策之间的信息传递容易失真。ONES 的项目管理能力可以把候选项目、资源投入估算和审批记录放在同一处工作项体系中，让容量核算表引用的数据与项目状态保持同步，决策记录随项目留痕，减少反复核对口径的成本。
示例：一次超载承接的完整处理过程
以下为演示情景，用于说明方法如何落地，数字为示意值。
情景设定与初始缺口
某研发团队下一季度收到四个候选项目。按角色核算后，后端可用工时为 1200 人时，四个项目所需合计 1600 人时，缺口 400 人时；测试工程师可用 800 人时，所需 1100 人时，缺口 300 人时；领域专家可用 200 人时，所需 260 人时，缺口 60 人时。三个关键角色全部超载，其中测试峰值集中在季度末。
排序与裁剪后的承接结果
按战略贡献、交付风险、资源占用、时间敏感性排序后，项目 A（合同约束、时间敏感）和项目 B（战略关联度高）排在前两位，项目 C 和 D 靠后。对项目 A 做范围裁剪，把报表模块移到下一版本，后端所需降至 350 人时；对项目 B 做阶段切分，本期只做需求与设计，开发排入下一窗口。裁剪后重新核算：后端所需 1150 人时，缺口收窄至负 50 人时，即有余量；测试所需 850 人时，仍有 50 人时缺口，通过把项目 B 的测试阶段整体后移消除。最终本期承接 A 和 B，C 和 D 暂缓。
暂缓项目的挂起与重启安排
项目 C 挂起原因为测试工程师缺口，保留动作是继续需求澄清，重启触发点为项目 A 进入维护期释放出 100 人时测试工时。项目 D 挂起原因为领域专家占用，重启触发点为专家完成当前在途项目评审后的下一个核算窗口。两项安排均写入暂缓清单，并指定跟踪人。
把容量约束固化为机制：审批门槛与复盘节奏
单次处理解决的是当期超载，机制解决的是下一轮不再重复超载。机制由三部分组成：承接前的容量校验、定期的容量复盘、超载预警。
承接前的容量校验作为审批门槛
新项目进入承接流程时，必须附带该项目的角色投入估算，并与当前容量基线比对。缺口超出约定阈值的项目，不能直接进入执行，需经组合决策人审批并说明缺口填补方式（裁剪、暂缓其他项目或补充资源）。把这一步设为审批门槛，意味着容量校验是流程的必经节点，而非事后提醒。
定期容量复盘与基线更新
按固定周期（如每月或每季度）复盘：实际投入与估算的偏差、暂缓项目的重启触发是否发生、缺口是否按预期收窄。复盘结果用于更新容量基线，包括人员变动、支持性工作占比的变化、估算偏差的修正系数。基线不更新，后续核算就会持续失真。
超载预警的触发条件
设定可观察的预警条件，例如某关键角色缺口超过可用容量的约定比例、连续两个核算窗口同一角色超载、暂缓项目数量超过约定上限。触发预警后启动临时评审，决定是否调整承接范围。预警条件应写入容量管理规则，与审批门槛一并执行。
完成检查：判断本轮容量处理是否到位
本轮处理结束后，用以下清单逐项核对，全部通过才算闭环。
| 检查项 | 通过标准 |
|---|---|
| 缺口核算覆盖关键角色 | 每个关键角色均有可用工时、所需工时和缺口数字，所需与可用使用同一时间窗口和单位 |
| 承接与暂缓清单有决策依据 | 每个项目的入选或暂缓均对应排序结果和书面理由，裁剪后的范围与投入已重新核算 |
| 暂缓项目有重启条件 | 每个暂缓项目写明挂起原因、保留动作和可观察的重启触发点，并指定跟踪人 |
| 机制落到审批与复盘 | 容量校验已纳入承接审批节点，复盘周期与基线更新责任已明确，超载预警条件已写入规则 |
四项全部满足，说明本轮超载承接完成了从核算到取舍再到机制固化的完整处理；任一项缺失，应回到对应章节补齐后再进入下一轮。
常见问题
候选项目所需工时估算不准，容量缺口算出来偏差很大怎么办？
估算偏差主要来自两点：假设条件没写清、只给单点数字。建议在核算表里为每个项目的估算注明假设，例如是否包含缺陷修复、是否依赖外部团队配合；对不确定性高的项目给出区间而非单点值。复盘时把实际投入与估算对比，形成偏差修正系数，下一轮核算时套用。估算精度会随复盘次数逐步提高，不必等估算完全准确才开始做取舍。
关键角色缺口无法通过裁剪消除，是否只能暂缓项目？
暂缓是选项之一，不是唯一选项。在裁剪范围、阶段切分之后仍有缺口时，可以评估三种补充方式：从其他团队借调或外部补充该角色资源；调整交付节奏，把峰值错开到容量有余量的时段；与其他项目交换资源占用顺序。每种方式都要重新核算缺口是否真正消除，并把补充资源的到位时间写进承接清单。若三种方式都不可行，再进入暂缓流程，写明挂起原因和重启触发点。
暂缓的项目过一段时间没人跟进，重启触发点形同虚设，怎么改？
问题通常出在触发点写得不可观察，或者没有指定跟踪人。改进做法是：触发点写成具体事件或数字，例如某角色释放出约定工时、上一阶段项目进入维护期、预算窗口开启；每个暂缓项目指定一名跟踪人，负责在复盘会上逐项核对触发条件是否发生；把暂缓清单纳入定期容量复盘的固定议程，触发条件满足时由跟踪人发起重启评审。这样暂缓项目有明确的责任人和检查节奏。
容量校验作为审批门槛，会不会拖慢项目启动速度？
门槛的作用是让缺口在承接前暴露，而不是在项目执行中才发现。为减少对启动速度的影响，可以约定分级规则：缺口在阈值以内的项目走简化校验，由项目负责人提交估算并附容量基线比对结果；缺口超出阈值的项目才进入组合决策人审批。同时把估算模板和容量基线提前维护好，让校验所需材料随手可得。规则清晰后，多数项目的校验可以在较短时间内完成。
团队规模较小、没有专职资源经理，角色分工怎么简化？
小团队可以把三个角色合并为两个：由技术负责人或项目经理兼任资源核算人，负责维护容量缺口核算表和估算假设；由团队负责人承担组合决策，签署承接清单与暂缓清单。项目负责人仍保留偏差上报和阶段完成确认的职责。关键是把核算与决策分开记录，即使由同一人兼任，也要在决策记录中写明依据和变更原因，保证后续复盘可追溯。复盘周期可以按项目批次而非固定月份安排。
