研发容量规划规则要解决的是“可用人力”和“需求占用”对不上账的问题：一边按人数排计划，一边按项目堆需求，到了月中才发现缺口，只能靠加班或临时调人补。可行的做法是把两者换算到同一时间口径，形成月度或季度的固定循环，并把口径、字段、责任人和评审时点写进规则文档。下面按口径定义、需求估算、供需比对、角色节奏、示例和校准六个环节展开，供研发管理者或项目经理直接套用。
要点总览（TL;DR）
- 容量规划规则先统一口径：确定主单位（建议人天）、规划周期（月度或季度滚动一期）、可用率取值和日历来源，四项写进规则文档后每期只更新数值。
- 需求侧要把项目需求、缺陷与线上问题、支持类工作、技术改进四类工作都登记为容量占用，并设 15%–25% 的预留比例，避免供需比对系统性偏乐观。
- 供需比对按角色分别计算占用率，以 80%、100%、115% 为分档阈值，轻度缺口触发需求排序复核，严重缺口触发借调、削减范围或版本顺延，并对应明确决策人。
- 规则要落到角色职责与评审日历：研发负责人主持评审并审批变更，项目经理负责登记与比对表，职能主管决策严重缺口，一线成员提供估算与实际反馈。
- 运行一到两个周期后按偏差记录校准可用率与预留比例，每季度调整一次，并用口径完整、比对按期、缺口有结论、偏差连续记录等检查项判断规则是否可用。
先定口径：容量按什么单位、什么周期计算
容量口径决定了后续所有数字能否比较。规则文档的第一部分应明确四件事：用什么单位计量、按什么周期规划、可用率取多少、日历从哪里来。这四项一旦确定，团队每期只需更新数值，不必重新讨论算法。
容量单位的选择
人天是最常用的单位，适合按月规划、以任务为颗粒度的团队；人时适合存在大量半天以下碎片工作的支持型团队，但统计成本更高。故事点只在团队已有稳定 velocity 数据时可用，且必须固定“1 点约等于多少人天”的折算系数，否则无法与人力供给对齐。建议规则中只保留一种主单位，其他单位作为辅助展示，避免同一张表里混用。
规划周期与滚动方式
月度周期适合需求变化快、插入工作多的团队；季度周期适合版本节奏稳定、需求批量进入的团队。无论选哪种，都应采用滚动方式：每月或每季度评审时，锁定下一期容量，同时更新再下一期的预测值。滚动的好处是缺口能提前一期暴露，而不是等到执行期才发现。
可用率与有效工时的取值
有效工时不能直接用日历工时。计算方式是：日历工作日 × 标准日工时 × 可用率。可用率需要扣除会议、评审、答疑、招聘面试、培训等非交付时间。初次制定规则时，可先用团队近三个月的时间记录估算一个区间，例如 70%–80%，取中位数作为起始值，再在复盘中校准。规则中要写明可用率的适用对象（按角色还是按团队统一），以及新成员、实习生是否单独取值。
工作日历与假期的处理
日历来源应统一，通常以公司法定工作日历为基准，再叠加团队特殊日历，例如调休、集中培训日、版本封版期。请假按已审批的假期从个人容量中扣除，未审批的假期不计入，避免重复扣减。跨地区团队要分别维护本地假日，不能用一个日历覆盖所有成员。规则中应指定日历维护人，并规定日历在每期规划前几个工作日完成更新。
| 口径项 | 建议取值方式 | 记录位置 |
|---|---|---|
| 容量单位 | 人天为主单位，故事点仅作辅助 | 规则文档第 1 节 |
| 规划周期 | 月度或季度，滚动一期 | 评审日历 |
| 可用率 | 按角色取值，起始值 70%–80%，季度校准 | 容量口径表 |
| 日历来源 | 公司日历 + 团队特殊日历，分地区维护 | 日历维护记录 |
需求侧怎么估：把待办转成容量占用
只统计项目任务会低估真实占用。缺陷修复、线上支持、技术债、评审与答疑同样消耗人力，规则应把这些工作纳入登记范围，否则供需比对会系统性偏乐观。
需求分类与登记范围
建议把占用分为四类：项目需求、缺陷与线上问题、支持类工作（答疑、数据提取、环境协助）、技术改进与预研。每类在登记表中单独成行或单独标记，便于后续分析占用结构。登记范围以“会占用研发人天的工作”为准，纯管理会议不单列，已计入可用率扣除项。
估算方法与粒度
项目需求按任务拆分后估算，粒度控制在半天到三天之间，超过三天的任务继续拆分，减少估算误差。缺陷按历史平均修复时长乘以预计数量估算，支持类工作按过去三个月的实际占用均值估算。估算由需求负责人给出，项目经理复核，两者不一致时以复核值为准并记录分歧原因。
预留比例的设定
临时插入工作和支持类工作无法逐条预估，应设预留比例。常见做法是从总容量中预留 15%–25% 给支持与临时工作，缺陷高发团队可上调。预留比例按团队历史数据设定，不照搬其他团队。预留部分在比对时视为已占用，不再分配给项目需求。
估算偏差的记录
每条需求在执行完成后记录实际占用，与估算值并列保存。偏差记录是后续校准估算方法的依据，也是判断某类需求是否长期被低估的证据。记录字段至少包括：需求编号、估算人天、实际人天、偏差原因分类（拆分不足、需求变更、依赖等待等）。
供需比对与缺口判定规则
供需比对的目的不是算出精确数字，而是尽早识别哪类角色会紧张、紧张到什么程度、需要什么动作。比对结果要能直接触发决策，而不是停留在报表上。
按角色或技能分组比对
按角色比对是最低要求，例如后端、前端、测试、设计分别计算供给与占用。技能稀缺的团队可进一步按技能分组，例如特定中间件、特定平台开发。分组过细会增加维护成本，建议先按角色运行一到两个周期，再根据缺口集中出现的领域细化。
缺口与盈余的判定阈值
用占用率（需求占用 ÷ 可用容量）作为判定指标。常见分档为：低于 80% 为盈余，80%–100% 为平衡，100%–115% 为轻度缺口，超过 115% 为严重缺口。阈值应结合团队实际调整，并在规则中写明调整需经过谁审批。盈余不等于可以随意接需求，还要看需求进入的时间分布。
缺口分级与触发动作
轻度缺口触发需求排序复核，由项目经理与研发负责人确认可延后项；严重缺口触发资源协调，包括跨团队借调、范围削减或版本顺延，由职能主管决策。缺口分级要对应明确的决策人和决策时限，例如严重缺口在评审会后三个工作日内给出处理结论。
比对结果的记录与上报
每期比对结果形成一页供需比对表，包含各角色供给、占用、占用率、缺口等级和处理动作。比对表在评审会上确认后归档，并向上一级研发管理或项目管理办公室上报严重缺口项。归档记录保留至少四个周期，用于观察缺口是否反复出现在同一角色。
| 占用率区间 | 判定 | 触发动作 | 决策人 |
|---|---|---|---|
| < 80% | 盈余 | 评估可提前启动的需求 | 项目经理 |
| 80%–100% | 平衡 | 按计划执行，关注插入工作 | 项目经理 |
| 100%–115% | 轻度缺口 | 需求排序复核，确认可延后项 | 项目经理 + 研发负责人 |
| > 115% | 严重缺口 | 借调、削减范围或顺延版本 | 职能主管 |
角色分工与评审节奏
规则能否持续执行，取决于每个环节是否有明确的责任人和固定的时间点。建议把职责写成一张表，与评审日历一起发布，避免出现“数据没人更新、缺口没人决策”的情况。
各角色职责
研发负责人对容量口径和缺口处理结论负责，主持评审会；项目经理负责需求占用登记、估算复核和比对表编制；职能主管负责跨团队资源协调和严重缺口的最终决策；一线成员负责提供任务估算和实际工时反馈。数据维护由项目经理指定专人承担，或由项目助理兼任。
评审节奏与输入输出
月度评审在每月固定日期召开，输入包括更新后的日历与请假数据、需求占用登记表、上期偏差记录；输出包括本期供需比对表、缺口处理结论和待办事项。季度评审在月度基础上增加参数校准议题，包括可用率、预留比例和估算方法的调整。评审会时长控制在合理范围，会前完成数据准备，会上只讨论结论和分歧。
规则变更与例外审批
口径、阈值、预留比例的变更由研发负责人审批，变更后更新规则文档版本号并通知相关角色。单次例外，例如某月临时抽调人员，由职能主管审批并在比对表中备注，例外不改变规则本身。例外记录累计出现三次以上时，应评估是否调整规则。
| 角色 | 主要职责 | 交付物 | 时间点 |
|---|---|---|---|
| 研发负责人 | 主持评审、审批规则变更 | 评审结论、变更记录 | 每月/每季度评审会 |
| 项目经理 | 占用登记、估算复核、比对表编制 | 供需比对表 | 评审会前 2 个工作日 |
| 职能主管 | 资源协调、严重缺口决策 | 缺口处理结论 | 评审会后 3 个工作日内 |
| 一线成员 | 任务估算、实际工时反馈 | 估算值与实际值 | 任务执行前后 |
一个可套用的示例：三人小组的月度容量表
以下为演示情景，用于说明口径、估算和比对如何串起来，数值不代表任何真实团队。
示例团队与周期设定
某三人研发小组，包含两名后端、一名测试，规划周期为一个月。当月日历工作日 21 天，标准日工时 8 小时，可用率取 75%。
可用容量计算
每人有效工时 = 21 × 8 × 75% = 126 小时，约 15.75 人天。小组总容量约 47.25 人天，按角色拆分为后端 31.5 人天、测试 15.75 人天。当月一名后端请假 2 天，其容量扣减为 14.25 人天，后端合计调整为 30 人天。
需求占用与缺口结果
当月登记项目需求后端 22 人天、测试 11 人天；缺陷按历史均值估算后端 4 人天、测试 3 人天；支持类工作按预留比例 20% 计，后端预留 6 人天、测试预留 3.15 人天。后端总占用 32 人天，占用率约 107%，判定为轻度缺口；测试总占用 17.15 人天，占用率约 109%，同样为轻度缺口。评审结论为复核需求排序，将一项后端需求延后至下月。
示例体现的规则要点
该示例体现了三条规则：请假从个人容量中扣除而非从总容量中粗略扣减；预留比例在比对前计入占用；缺口判定按角色分别计算，不合并成团队总数。实际使用时，把示例中的数值替换为本团队数据即可。
| 角色 | 可用容量（人天） | 项目需求 | 缺陷 | 预留 | 总占用 | 占用率 | 判定 |
|---|---|---|---|---|---|---|---|
| 后端 | 30 | 22 | 4 | 6 | 32 | 107% | 轻度缺口 |
| 测试 | 15.75 | 11 | 3 | 3.15 | 17.15 | 109% | 轻度缺口 |
规则落地后的校准与完成检查
规则运行一到两个周期后，需要用实际数据检验参数是否合理。校准的目标是让估算和实际逐步收敛，而不是追求某一期数字完全吻合。
估算偏差与实际占用的复盘
每期结束后，把实际占用与估算值逐条对比，计算偏差率和偏差方向。偏差集中在某一类需求或某一个环节时，优先修正该类需求的估算方法，例如拆分粒度或依赖等待的计入方式。偏差原因分类应保持稳定，便于跨期比较。
参数的调整节奏
可用率和预留比例建议每季度校准一次，依据是过去三个月的实际非交付时间和支持类工作占比。调整幅度不宜过大，单次调整控制在几个百分点内，避免规则频繁变动导致数据不可比。调整需记录调整前后数值和依据。
规则文档的维护与版本记录
规则文档应有版本号、修订日期、修订人和变更说明。口径、阈值、职责的每次变更都对应一条记录，历史版本保留可查。文档存放位置对相关角色可见，新成员入职时作为了解容量规划流程的材料。
完成检查项与通过标准
判断规则是否可用，可逐项核对以下内容：口径定义表是否完整并已发布；需求占用登记是否覆盖四类工作；供需比对表是否按期产出并归档；缺口是否都有对应处理结论；偏差记录是否连续保留两个周期以上；规则文档是否有版本记录。上述各项均能满足，说明规则已具备持续运行的基础。在数据承载上，容量占用登记、评审结论和偏差记录可以放在同一套工作项与工时数据中管理，ONES 的工作项与工时记录可用于承载这类登记和复盘数据，减少在多张表格之间手工汇总的环节。
常见问题
团队第一次制定容量规划规则，应该先从哪里开始？
建议从口径定义开始，先把容量单位、规划周期、可用率和日历来源四项确定下来，并写成一份口径定义表。这四项确定后，需求估算和供需比对才有共同的计算基础。初次制定时可用率可先取团队近三个月时间记录估算出的区间中位数，例如 70%–80%，运行一个周期后再校准。不建议一开始就细化到技能分组或引入复杂折算系数，先按角色跑通一个完整循环更重要。
跨地区团队或存在大量调休时，工作日历和请假怎么处理？
日历以公司法定工作日历为基准，再叠加团队特殊日历，例如调休、集中培训日、版本封版期。跨地区团队要分别维护本地假日，不能用一个日历覆盖所有成员。请假只按已审批的假期从个人容量中扣除，未审批的假期不计入，避免重复扣减。规则中应指定日历维护人，并规定在每期规划前几个工作日完成日历更新，否则可用容量会算偏。
需求估算经常偏差很大，规则上应该怎么补救？
先看偏差集中在哪一类需求或哪个环节。常见原因包括任务拆分粒度太粗、需求变更未及时登记、依赖等待时间未计入。对应做法是：把任务粒度控制在半天到三天之间，超过三天继续拆分；需求变更时同步更新占用登记；对依赖等待较多的需求单独记录等待时间。每条需求执行完成后记录实际占用，与估算值并列保存，偏差原因分类保持稳定，连续两个周期以上就能看出哪类需求长期被低估，再针对性修正估算方法。
占用率落在 80%–100% 的平衡区间，是否意味着可以继续接新需求？
平衡区间表示当前登记的需求与可用容量大致匹配，是否接新需求还要看两点：一是需求进入的时间分布，如果新需求集中在同一时段，局部仍会形成缺口；二是预留比例是否已被临时工作消耗完。建议在平衡区间内接需求前，先确认预留部分的使用情况，并评估新需求与现有需求的时间重叠程度。规则中可以补充一条：平衡区间内新增需求需经项目经理确认时间分布后再纳入。
规则运行一段时间后，什么情况下应该修改规则本身，而不是按例外处理？
单次特殊情况，例如某月临时抽调人员或短期支援其他团队，按例外审批并在比对表中备注即可，例外不改变规则。当同类例外累计出现三次以上，说明规则与实际情况已经脱节，应评估是否调整规则，例如修改预留比例、调整阈值或补充新的占用类别。规则变更由研发负责人审批，变更后更新版本号并通知相关角色，历史版本保留可查，便于比较调整前后的数据。
