研发容量规划规则要解决的是可用人力与需求人力对不上账的问题：团队到底有多少可投入的工时，需求又需要多少工时，差额怎么处理。规则的价值在于把这两组数字放进同一口径、按固定周期核算，并明确谁提供数据、谁做取舍、何时复盘。本文按口径定义、操作步骤、角色分工、季度示例、偏差处理和完成检查的顺序展开，适合正在建立或修订容量规划机制的研发团队参考。ONES 可作为承载工作项工时与团队容量数据的工具之一，具体用法在相关步骤中说明。
要点总览（TL;DR）
- 先定四类口径：规划周期、可用人力、需求人力、优先级与承诺，形成一份口径定义表，作为所有核算的唯一依据。
- 按五步执行：确定范围与团队边界、汇总需求折算工时、计算可用容量、供需对比识别缺口、形成承接与调整结论。
- 缺口要分技能看，只看总量会掩盖结构性矛盾；示例中总量缺口44人天，后端缺口60人天而前端有余量。
- 用历史数据校正估算偏差、预留10%–15%缓冲应对插入需求、固定月度更新容量数据，是规则可持续的关键。
- 规则上线后按口径统一、周期产出、缺口有结论、角色履职、复盘闭环、例外有记录六项检查是否真正运转。
容量规划规则先定哪几个口径
规则设计的第一步是把口径写死，否则每个季度都要重新争论数字怎么算。建议先定四类口径：规划周期、可用人力、需求人力、优先级与承诺。四类口径合起来构成一份容量口径定义表，作为后续所有核算的唯一依据。
规划周期决定核算频率。季度规划适合需求相对稳定、交付周期较长的团队；月度规划适合需求变化快、迭代节奏短的团队。无论选哪种，都要写明滚动方式，例如每季度末滚动更新下两个季度，或每月初刷新当月与次月。周期一旦确定，供需对比就按这个节奏产出，避免临时起意做核算。
可用人力口径要回答“一个人在一个周期里真正能投入多少”。常见做法是以人数为起点，乘以周期内工作日，再扣除法定假日、年假、培训、值班、公共事务等非项目投入，得到可分配工时。扣减项要列成固定清单，每项给出默认比例或由团队负责人按实际填报。技能结构也属于容量口径的一部分：同样是十个人，前端与后端的比例不同，能承接的需求类型就不同。
需求人力口径要回答“一个需求折算多少工时”。按工作项类型分别设定折算方式，例如需求按估算人天、缺陷按历史平均修复工时、技术债按专项预算。折算单位统一用人天或人时，避免一部分需求用点数、一部分用天数。估算粒度控制在半天到两天之间，过粗会掩盖差异，过细会增加估算成本。
优先级与承诺口径决定哪些需求进入容量核算。建议只把已评审通过、优先级明确的需求纳入当期核算，未评审的想法留在需求池，不占用容量。承诺口径要写明：进入核算的需求是否等于承诺交付，还是仅作为候选排序。两者混用会导致团队既不敢承诺、又无法拒绝。
| 口径项 | 定义内容 | 示例取值 | 维护责任人 |
|---|---|---|---|
| 规划周期 | 核算频率与滚动方式 | 季度规划，每季度末滚动下两季 | 资源或项目管理角色 |
| 可用人力 | 人数×工作日−扣减项 | 10人×60工作日×80%可投入率 | 团队负责人 |
| 需求人力 | 按工作项类型折算工时 | 需求按估算人天，缺陷按历史均值 | 产品角色与团队负责人 |
| 优先级 | 进入核算的需求范围 | 仅已评审且定级的需求 | 产品角色 |
| 承诺口径 | 核算结果与交付承诺的关系 | 核算内需求为承诺候选，评审后确认 | 决策角色 |
从需求收集到供需对比的操作步骤
口径确定后，把规则拆成五个步骤，每步都有明确的输入、动作、输出和完成标志。五步按周期重复执行，形成固定节奏。
步骤一：确定规划范围与团队边界
输入是组织架构与本期规划周期。动作是明确本次核算覆盖哪些团队、哪些人计入容量、哪些共享资源按比例分摊。输出是一份范围说明，列出纳入人员名单与排除项。完成标志是所有相关方对范围无异议，避免后续出现“这个人算不算”的争议。
步骤二：汇总需求并折算工时
输入是需求池中已评审的需求清单。动作是按工作项类型逐条折算工时，标注优先级与依赖关系，剔除未评审或明确延期的条目。输出是一份带工时估算的需求汇总表。完成标志是每条需求都有估算值、估算人和优先级，且估算口径与定义表一致。
步骤三：计算可用容量
输入是范围说明与人员日历。动作是按可用人力口径逐人计算可分配工时，汇总为团队总容量，并按技能维度拆分。输出是团队容量表，包含总工时与分技能工时。完成标志是容量数据经团队负责人确认，扣减项有据可查。
步骤四：供需对比，识别缺口与余量
输入是需求汇总表与容量表。动作是按优先级排序需求，累计工时与容量对比，找出超出容量的部分和剩余余量，同时检查技能维度是否匹配。输出是一份供需对比结果，标明缺口工时、缺口所在技能和余量。完成标志是缺口与余量都有具体数字，而非“大概紧张”这类描述。
步骤五：形成承接与调整结论
输入是供需对比结果。动作是由决策角色确认本期承接哪些需求、延期或转交哪些需求、是否需要补充人力或调整范围。输出是承接结论与调整清单，回写到需求状态。完成标志是每条进入核算的需求都有明确去向：承接、延期、转交或取消。
在这套流程中，需求工时、人员容量与工作项状态需要放在同一处维护，否则每次核算都要手工拼接多份表格。ONES 的工作项管理与工时相关能力可以承载需求估算、工时记录和状态流转，使步骤二到步骤五的数据来自同一套工作项记录，减少口径漂移。具体字段配置需结合团队实际流程设定。
角色分工与各环节交付物
规则能否执行，取决于每个环节是否有人负责、有物可交。建议按以下分工明确职责，避免容量数据无人维护、取舍无人拍板。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 需求方 | 提出需求，说明业务价值与期望时间 | 需求说明与优先级建议 |
| 产品角色 | 组织需求评审，确定优先级，确认进入核算的范围 | 已评审需求清单与优先级排序 |
| 团队负责人 | 维护可用容量、扣减项与技能结构，参与工时估算 | 团队容量表与估算确认记录 |
| 资源或项目管理角色 | 汇总供需数据，组织容量评审会，跟踪结论落地 | 供需对比表与评审纪要 |
| 决策角色 | 确认承接与调整结论，处理跨团队资源协调 | 承接结论与调整清单 |
| 复盘责任人 | 对比计划与实际，记录偏差原因，输出下期改进项 | 复盘记录与下期输入 |
分工中有两个容易空缺的位置需要特别注意。一是容量数据的日常维护人，如果只在核算前临时收集，数据质量难以保证；建议由团队负责人指定固定更新节奏。二是复盘责任人，若无人对偏差做归因，规则会在几个周期后流于形式。角色可以兼任，但职责要写进规则文本。
一个季度容量核算的示例
以下为演示情景，数字仅用于说明核算方法，不代表任何真实团队数据。
假设某研发小组10人，本季度工作日62天，扣除法定假日、平均年假与培训后，按80%可投入率计算，可用容量为10×62×0.8＝496人天。按技能拆分，后端约240人天，前端约160人天，测试约96人天。
需求清单经评审后进入核算的有8项，折算工时合计540人天，其中后端相关300人天、前端150人天、测试90人天。供需对比结果：总量缺口44人天；分技能看，后端缺口60人天，前端余量10人天，测试余量6人天。
| 维度 | 可用容量（人天） | 需求工时（人天） | 差额（人天） |
|---|---|---|---|
| 后端 | 240 | 300 | −60 |
| 前端 | 160 | 150 | +10 |
| 测试 | 96 | 90 | +6 |
| 合计 | 496 | 540 | −44 |
依据缺口，决策角色可采取三类动作：将优先级最低的一项后端需求延期到下季度，约释放50人天；安排一名前端人员在简单后端任务上支援，需评估技能可行性；剩余缺口通过缩减范围或申请外部支援解决。调整后重新核算，确认承接需求落在容量之内，并将结论回写到需求状态。这个示例说明，缺口要分技能看，只看总量会掩盖结构性矛盾。
规则落地中的常见偏差与处理
规则执行几个周期后，通常会出现几类偏差。提前设定处理方式，比事后争论更有效。
工时估算偏乐观
估算普遍偏低会让容量看起来充裕，实际执行时不断超期。处理方式是用历史数据校正：统计同类工作项的计划工时与实际工时比值，作为估算系数；连续两个周期偏差超过一定比例的团队，在估算时强制加入缓冲。校正系数应公开，避免变成个别项目的特殊待遇。
需求中途插入
紧急需求插入是常态，关键是预留缓冲并设定例外流程。建议在容量中预留固定比例的缓冲工时，例如10%至15%，专门用于插入需求；超出缓冲的插入需求必须走例外审批，由决策角色确认被替换或延期的原有需求。缓冲比例按团队历史插入量调整，不宜长期为零。
技能结构不匹配
总量平衡但技能错配，会形成隐性缺口。处理方式是在供需对比中固定输出分技能结果，并在评审时检查跨技能支援的可行性。若某技能长期缺口，应纳入招聘或培训计划，而不是靠加班消化。
容量数据更新滞后
人员变动、休假、借调未及时反映，会让容量失真。处理方式是明确更新频率与责任人：团队负责人每月初更新一次容量数据，人员变动在发生后一周内更新。更新记录保留，便于复盘时追溯。
| 偏差类型 | 识别信号 | 处理规则 |
|---|---|---|
| 估算偏乐观 | 实际工时持续高于计划 | 引入历史校正系数，偏差大的团队加缓冲 |
| 需求中途插入 | 缓冲被快速耗尽 | 预留10%–15%缓冲，超缓冲走例外审批 |
| 技能结构不匹配 | 总量平衡但交付延迟 | 分技能核算，评估支援或补充计划 |
| 容量数据滞后 | 核算结果与实际情况不符 | 固定月度更新，变动一周内同步 |
规则上线后的完成检查
判断规则是否真正运转，可以按以下清单逐项核对。每项都给出通过标准，便于在第一个完整周期结束后做一次检查。
- 口径是否统一：所有团队使用同一份容量口径定义表，字段、单位、扣减项一致；抽查两份核算表，口径无冲突即为通过。
- 供需对比是否按周期产出：每个规划周期都有供需对比表，且按时提交评审；连续两个周期缺失即视为未运转。
- 缺口是否有明确处理结论：每条缺口都对应承接、延期、转交或补充人力的结论，无悬空项。
- 角色是否履职：需求清单有评审记录，容量表有负责人确认，承接结论有决策角色签字或确认记录。
- 复盘是否形成下期输入：复盘记录中包含偏差原因与改进项，且改进项进入下一周期的口径或流程调整。
- 例外是否有记录：插入需求、超缓冲需求均有审批记录，可追溯替换或延期了哪些原需求。
检查不通过的项，应作为下一周期规则修订的输入，而不是简单归因于执行不力。规则本身也需要随团队规模和业务节奏调整，例如团队扩张后重新校准可投入率，需求波动加大后缩短规划周期。把检查、复盘、修订串成闭环，容量规划规则才能持续为承接决策提供可靠依据。
常见问题
团队刚开始做容量规划，第一个周期应该先做全量核算还是先跑通流程？
建议第一个周期先跑通流程，范围可以收窄到一个团队或一条产品线。全量核算需要所有团队同时提供需求清单和容量数据，数据质量往往难以保证，反而让各方对规则产生怀疑。先在一个团队完成口径定义、五步核算和一次评审，验证口径是否可操作、交付物是否有人认领，再逐步扩展到其他团队。扩展时保持口径定义表不变，只增加纳入范围。
需求工时估算经常偏乐观，除了加缓冲还有别的校正办法吗？
加缓冲是事后手段，更根本的做法是建立估算与实际工时的对照记录。按工作项类型统计历史比值，例如需求类工作项实际工时平均为估算的1.3倍，就把这个系数作为下一轮估算的校正依据，并在估算时向估算人展示同类工作的历史数据。连续两个周期偏差超过设定比例的团队，可以要求估算由两人独立完成再取较高值。校正系数和规则应公开，避免变成个别项目的特殊处理。
插入需求超出预留缓冲时，应该由谁决定替换哪些原有需求？
这类决策应由决策角色拍板，资源或项目管理角色提供供需对比数据作为依据，产品角色给出优先级建议。处理顺序建议是：先看缓冲余量，再看能否通过调整范围或延期低优先级需求腾出容量，最后才考虑补充人力。每次例外都要记录插入需求、被替换或延期的原需求以及决策人，便于复盘时评估插入需求的真实频率和影响。若缓冲连续多个周期被快速耗尽，说明缓冲比例或需求准入规则需要调整。
总量供需平衡但交付仍然延迟，问题通常出在哪里？
常见原因是技能结构错配或依赖关系未纳入核算。总量平衡只说明工时总数够用，如果缺口集中在某一技能，其他技能有余量也无法直接转换。处理方式是在供需对比中固定输出分技能结果，并在评审时检查跨技能支援的可行性。另一类原因是需求之间的依赖未在核算中体现，前置需求延期会连带影响后续需求。建议在需求汇总表中标注依赖关系，核算时按依赖顺序检查关键路径上的容量是否充足。
容量规划规则需要多久修订一次，修订依据是什么？
建议每个规划周期结束后结合复盘做一次小检查，每两到四个周期做一次正式修订。修订依据主要来自三方面：完成检查中不通过的项、复盘记录中的偏差原因、以及团队规模和业务节奏的变化。例如团队扩张后需要重新校准可投入率，需求波动加大后可能需要缩短规划周期或提高缓冲比例。修订应聚焦口径和流程的具体条款，保留修订记录，避免规则频繁变动导致各方无所适从。
