研发容量规划要回答的是“未来一段时间，团队真正能投入的工时有多少，已承诺和待评估的工作需要多少”，并把两者放在同一口径下对齐。会压缩可用工时的约束通常集中在人力供给、需求范围、时间节奏、组织制度四个方面。本文按“定口径—核约束—算缺口—定分工—做检查”的顺序，给出一套可执行的流程和配套清单。
要点总览（TL;DR）
- 研发容量规划要把可用人力供给与已承诺加待评估的需求放在同一口径下对齐，先固定计量单位、统计周期和可用工时折算规则。
- 需要逐项核对的约束分四类：人力供给、需求与范围、时间与节奏、组织与制度；前两类决定缺口大小，后两类决定缺口出现的时间点。
- 落地按五步走：建供给台账、建需求台账、同口径比对、用调整范围/调整时间/调整人力三种手段收敛缺口、形成结论并设滚动复核节点。
- 整体缺口为零不代表没问题，要按技能维度分别看，关键角色超载常被总量掩盖。
- 结论交付前用检查表核对口径、约束核对、缺口责任人、复核机制和负责人确认，出现阻断项需重新测算。
先定口径：容量规划算的是哪种工时
容量规划最常见的失败原因，是供给和需求用了两套计量方式：一边按在岗人数估，一边按需求条数排，最后无法相减。开始核对约束之前，先把口径书面固定下来，后续所有约束检查才有共同基准。
计量单位与折算方式
供给侧和需求侧必须使用同一单位。常见选择有三种：人天、人时，或以故事点折算工时。人天适合按季度做粗粒度规划，人时适合迭代内精细排布，故事点折算适合已有稳定估算体系的团队。无论选哪种，都要写明折算规则，例如“1 人天按 8 人时计”“1 故事点按团队历史均值折算为若干人时”。折算系数来自本团队历史数据，不照搬外部经验值。
统计周期与滚动频率
周期决定约束检查的粒度。按季度规划适合承接跨团队项目和年度目标，按迭代规划适合交付节奏稳定的团队。建议主周期按季度，滚动更新按迭代或按月，并在口径说明中写明：哪些变化触发重算，例如需求范围变更超过约定比例、关键角色离岗、交付窗口调整。
名义工时与可用工时
名义工时是编制人数乘以工作日，可用工时是名义工时扣除各类占用后的实际可投入时间。可用工时比例应基于本组织历史数据取值，取值来源要写清楚：考勤与请假记录、会议与培训日历、支持运维工单量、评审与合规活动的历史耗时。比例一旦确定，在周期内保持稳定，避免每次测算临时调整导致结论不可比。
计入容量占用的活动
口径说明中要列出计入项清单，至少覆盖：需求交付、缺陷修复、支持与运维、评审与合规活动、培训与会议。清单之外的活动如果占用工时，也要登记，否则可用工时会被高估。这份口径说明是后续所有台账和结论的附件，随规划周期一起归档。
约束清单：四类约束逐项核对
约束核对的目标不是把所有因素都算进公式，而是逐项判断它如何压缩可用容量或改变需求规模，并留下取数来源。下表按四类约束给出判断问题、影响方式和数据来源，可直接作为核对模板使用。
| 约束类别 | 核对项 | 判断问题 | 对容量的影响方式 | 取数来源 |
|---|---|---|---|---|
| 人力供给 | 在岗人数 | 周期内各角色实际在岗人数是多少，是否有入离职计划 | 直接决定名义工时总量 | 花名册、入离职计划 |
| 技能结构 | 待承接工作中哪些类型只有少数人能做 | 关键角色形成瓶颈，整体富余但局部超载 | 技能矩阵、历史任务分配记录 | |
| 请假与流失 | 周期内已批准的假期和可预期的流动有多少 | 扣减可用工时 | 考勤系统、休假计划 | |
| 招聘到岗周期 | 计划招聘的岗位从启动到独立产出需要多久 | 新增人力在周期内只能部分计入 | 招聘记录、历史到岗与上手周期 | |
| 需求与范围 | 需求总量 | 已承诺和待评估的需求合计工作量是多少 | 决定需求侧总负荷 | 需求台账、估算记录 |
| 优先级分布 | 高优先级需求占比是否超过容量可承受范围 | 决定哪些工作必须排进周期 | 需求优先级字段 | |
| 变更频率 | 历史周期内需求范围平均变更幅度多大 | 变更带来返工和重新估算，侵蚀可用容量 | 变更记录、版本对比 | |
| 外部依赖与前置条件 | 哪些需求依赖外部团队交付或环境就绪 | 依赖未就绪时工时无法按期投入 | 依赖清单、联调排期 | |
| 时间与节奏 | 交付窗口 | 周期内有几个固定交付节点，分布是否集中 | 节点集中造成阶段性超载 | 发布计划、里程碑 |
| 发布冻结期 | 冻结期有多长，期间可做哪些工作 | 冻结期内交付类工时受限 | 发布管理制度 | |
| 评审与测试周期 | 评审和测试平均占用多少日历时间 | 拉长交付周期，压缩并行空间 | 历史评审与测试记录 | |
| 跨团队依赖排期 | 依赖方的排期是否已确认 | 排期错位导致等待和返工 | 跨团队排期表 | |
| 组织与制度 | 审批与合规活动 | 周期内有哪些强制评审、审计或合规检查 | 占用固定工时且不可压缩 | 合规日历、评审计划 |
| 支持与运维占用 | 历史支持工单和运维值班平均占用多少工时 | 从可用工时中持续扣减 | 工单系统、值班记录 | |
| 培训与会议 | 固定会议和培训在周期内的总时长 | 降低人均可用工时比例 | 日历统计、培训计划 |
核对时对每一项标注“已确认、待确认、不适用”，待确认项要写明责任人和确认时点。四类约束中，人力供给和需求范围决定缺口大小，时间节奏和组织制度决定缺口出现的时间点，后者常被忽略，却往往是阶段性超载的直接原因。
操作步骤：从供给台账到缺口收敛
约束核对完成后，进入测算。五步流程的每一步都有明确输入、动作、输出和完成标志，完成标志用于判断这一步是否可以结束、进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 建立供给台账 | 在岗名单、技能矩阵、请假与招聘计划、可用工时比例 | 按角色与技能分组，逐人计算周期内可用工时，标注关键技能持有人 | 供给台账：各角色可用工时合计与关键技能供给量 | 每个角色的可用工时可追溯到人和折算规则 |
| 2. 建立需求台账 | 需求清单、估算结果、优先级、交付窗口、依赖关系 | 按优先级和交付窗口归集工作，标注所需技能类型和外部依赖 | 需求台账：按周期和技能类型汇总的工作量 | 每条需求有估算值、优先级和交付窗口 |
| 3. 同口径比对 | 供给台账、需求台账 | 按同一周期和技能维度相减，计算各周期缺口与富余 | 缺口表：分角色、分周期的缺口数值 | 缺口可定位到具体角色和具体时间段 |
| 4. 收敛缺口 | 缺口表、约束核对清单 | 按调整范围、调整时间、调整人力三种手段逐项处理，评估每种手段受哪些约束限制 | 收敛方案：每项缺口的处理手段、责任人和预期效果 | 每项缺口都有明确处理手段和责任人 |
| 5. 形成结论并设复核节点 | 收敛方案、口径说明 | 汇总容量结论，设定滚动复核时点和触发重算的条件 | 容量结论文档与复核计划 | 结论经研发负责人确认，复核节点已进入团队日历 |
第三步比对时，整体缺口为零不代表没有问题：某类角色超载、另一类角色富余是常见情况，需要按技能维度分别看。第四步的三种手段各有适用条件：调整范围适用于优先级可重新排序的需求，调整时间适用于交付窗口有弹性的工作，调整人力适用于招聘周期或内部调配能覆盖缺口的场景。三种手段都受限时，缺口需要作为风险上报，由研发负责人做取舍决策。
需求台账和工时记录需要持续维护，容量结论才有可复核的数据基础。在 ONES 中，需求以工作项形式承载优先级和估算信息，资源管理支持通过工作数量和工时规模了解成员排期，并支持筛选与分组掌握成员在不同项目的投入比重；工时登记后，可实时查看成员每日投入饱和明细，识别规划风险，并导出工时日志用于复核。这些记录对应的是本文流程中“需求台账”和“供给台账”的数据留存环节，具体功能范围以所购版本为准。
角色分工与交付物
容量规划涉及多个角色，职责不清会导致台账无人维护、结论无人拍板。下表明确各角色的职责、交付物和提交时点。
| 角色 | 职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 研发负责人 | 确认容量结论，对范围、时间、人力三种收敛手段做取舍决策 | 容量结论确认记录、取舍决策说明 | 缺口收敛完成后、周期开始前 |
| 项目经理或交付负责人 | 维护需求台账，确认交付窗口和外部依赖排期 | 需求台账、交付窗口清单、依赖确认记录 | 每个规划周期开始前更新 |
| 团队负责人 | 提供技能结构、可用工时数据和请假计划 | 供给台账、技能矩阵更新 | 与需求台账同步提交 |
| 人力或HRBP | 提供在岗、招聘进展与流动信息 | 在岗与招聘计划表 | 周期开始前及滚动复核时 |
各角色的交付物应汇总到同一份容量结论文档中，作为附件留存。滚动复核时，只更新发生变化的台账部分，结论文档保留版本记录，便于回溯某次缺口判断的依据。
示例：一个季度的容量缺口如何算出来
以下数据均为演示假设，用于说明约束如何进入计算并影响结论，不代表任何真实团队情况。
假设一个 12 人的研发团队，规划周期为一个季度，约 60 个工作日。按历史数据，可用工时比例取 75%，扣除会议、支持运维、评审与合规活动、培训与请假后，人均可用工时约 45 人天，团队总供给约 540 人天。其中后端 5 人、前端 4 人、测试 3 人。
需求侧，已承诺需求估算合计 480 人天，待评估需求约 120 人天。按优先级分布，高优先级需求约 420 人天，集中在季度前两个月交付。按技能类型拆分，后端相关工作量约 300 人天，前端约 180 人天，测试约 120 人天。
同口径比对后，整体缺口约 60 人天，但结构性问题更突出：后端供给约 225 人天，需求 300 人天，缺口 75 人天；前端供给约 180 人天，基本持平；测试供给约 135 人天，需求 120 人天，略有富余。同时，季度内有一个发布冻结期约 5 个工作日，冻结期内后端交付类工时进一步受限，缺口在第二个月集中显现。
收敛取舍：第一，调整范围，将待评估需求中优先级较低的部分推迟到下季度，减少约 40 人天后端工作量；第二，调整时间，把一项交付窗口有弹性的需求后移，避开冻结期；第三，调整人力，申请一名后端短期支援或加快在招岗位到岗，覆盖剩余缺口。测试侧的富余人力可临时支援验收类工作，但受技能约束，支援幅度有限。最终结论需研发负责人确认，并在季度中期设一次复核，若需求变更超过约定比例则触发重算。
完成检查：容量结论是否可用
容量结论交付前，用以下检查表逐项核对。通过标准全部满足，结论才可用于排期和承诺；出现阻断项时，需要重新测算后再提交。
| 检查项 | 通过标准 | 阻断情形 |
|---|---|---|
| 口径与周期 | 计量单位、统计周期、可用工时折算规则已书面固定，各方认可 | 供给与需求单位不一致，或折算规则未书面化 |
| 约束核对 | 四类约束逐项核对，每项有取数来源和确认状态 | 关键约束（如技能结构、发布冻结期）未核对 |
| 缺口与收敛 | 每项缺口有处理手段、责任人和预期效果 | 存在无责任人的缺口，或缺口仅以“加强协调”描述 |
| 复核机制 | 已设定滚动复核节点和触发重算的条件 | 无复核节点，或触发条件未定义 |
| 结论确认 | 研发负责人已确认结论与取舍决策 | 结论未经确认即用于对外承诺 |
需要重算的典型情况包括：需求范围变更超过约定比例、关键角色离岗或招聘计划落空、交付窗口或冻结期调整、外部依赖排期未按期确认。这些情况发生时，按第五步重新形成结论，并保留上一版记录以便对比。
常见问题
团队整体工时够用，为什么容量规划还是显示超载？
总量平衡掩盖了结构性问题。常见情况是某类角色（如后端或特定技能持有人）需求集中，而其他角色有富余，但富余人力受技能约束无法直接转移。做法是在比对时按角色和技能维度分别相减，把缺口定位到具体角色和时间段，再判断能否通过内部支援、外部招聘或调整范围来消化。
可用工时比例应该取多少，能不能直接套用行业经验值？
可用工时比例应基于本组织历史数据取值，从名义工时中扣除会议、培训、支持运维、评审与合规活动、请假等占用后得出。直接套用外部经验值会让测算结论与团队实际脱节。比例确定后在周期内保持稳定，并写清取值来源，便于复核时对比。
需求变更频繁，容量结论刚出就失效，怎么处理？
在口径说明中预先定义触发重算的条件，例如需求范围变更超过约定比例、关键角色离岗、交付窗口或冻结期调整、外部依赖排期未按期确认。触发后按流程重新测算，并保留上一版记录以便对比。变更频率本身也应作为需求与范围约束的一项，在核对时用历史变更幅度评估它对可用工时的侵蚀。
三种收敛手段都用上了缺口还在，应该怎么办？
当调整范围、调整时间、调整人力都受约束限制时，剩余缺口应作为风险上报，由研发负责人做取舍决策，明确哪些工作延后、哪些接受风险交付。这一步的结论要写入容量结论文档，记录取舍依据和责任人，避免缺口在无记录的情况下被默认承接。
容量规划的数据在工具里怎么留存，方便下次复核？
需求台账和工时记录需要持续维护，容量结论才有可复核的数据基础。在 ONES 中，需求以工作项形式承载优先级和估算信息，资源管理支持通过工作数量和工时规模了解成员排期，并支持筛选与分组掌握成员在不同项目的投入比重；工时登记后可查看成员每日投入饱和明细，识别规划风险，并导出工时日志用于复核。这些记录对应需求台账与供给台账的数据留存环节，具体功能范围以所购版本为准。
