研发容量规划规则示例要交付的是一张能复算的表：把可用人力和需求人力放在同一口径下，算出每个周期的缺口或余量，并给出对应的调整动作。本文给出一份季度容量规划的填写范例，覆盖容量口径、需求口径、供需对比和调整规则四组字段，示例为演示情景，非真实团队数据。测算结果需要持续跟踪时，可以在ONES中把需求条目落到工作项、用工时记录回填实际投入，让下一轮规划有据可依。
要点总览（TL;DR）
- 示例把容量规划拆成四张表：可用容量、需求人力、供需对比、缺口调整动作，四张表共用同一套人天口径，缺口可以直接相减得出。
- 可用容量按“人数×有效工作日×投入比例”折算，有效工作日扣除假期与培训，投入比例扣除会议、评审、答疑等支持性工作，避免容量虚高。
- 缺口同时用绝对人天和百分比表达：绝对人天用于决定砍哪条需求、借调几人，百分比用于跨角色比较紧张程度。
- 缺口调整按“先减需求、再调范围、最后调人力”的顺序执行，依据是决策确定性和协调成本由低到高。
- 换团队或换周期时，固定口径一致、供需同表、缺口配动作三条不变，周期长度、投入比例和估算粒度随场景调整。
示例要解决什么问题：容量规则要能算出缺口
这份示例的目标，是把“这个季度人手够不够”从口头判断变成一张可复算的表。任何人拿到同样的输入，按同样的口径填一遍，应该得到同一个缺口数字；换一个季度、换一个团队，只要替换输入值，表的结构和算法保持不变。
示例覆盖的范围限定在一个研发团队、一个季度周期内的可用人力供需测算。角色范围包括后端、前端、测试三类直接交付角色，以及团队负责人这一管理角色。产品经理、设计师等协作角色是否计入，取决于他们是否由该团队直接排期，示例中按“不计入可用容量、其需求单列”的方式处理。
判断一份容量规划表是否合格，可以用三条标准核对：
- 口径一致：可用人力和需求人力都以人天为单位，且都扣除了非投入时间，两边可以直接相减。
- 缺口可算：每个周期、每个角色都能算出一个具体数字，而不是“比较紧张”“大致够用”这类描述。
- 调整有据：缺口出现后，调整动作有明确的优先顺序，且每条动作能对应到具体的需求条目或角色。
三条标准缺一条，表就会退化成一份人力清单：数字对不上，或者对上了却不知道下一步做什么。
完整示例：一个季度研发容量规划表
以下为演示情景，团队规模、人员构成与需求数据均为虚构，用于展示填写方式，不代表任何真实团队的情况。
示例背景设定
某研发团队共10人：后端4人、前端3人、测试2人、团队负责人1人。规划周期为2025年第二季度（4月至6月，共13周）。该季度有法定节假日1天，团队安排了2天集中培训，负责人约有30%的时间用于管理和跨团队协调。季度内待交付需求共8条，按优先级分为P0、P1、P2三档。
表一：可用容量计算表
| 角色 | 人数 | 周期工作日 | 扣除假期与培训 | 有效工作日 | 投入比例 | 折算人天 |
|---|---|---|---|---|---|---|
| 后端 | 4 | 65 | 3 | 62 | 80% | 198.4 |
| 前端 | 3 | 65 | 3 | 62 | 80% | 148.8 |
| 测试 | 2 | 65 | 3 | 62 | 75% | 93.0 |
| 团队负责人 | 1 | 65 | 3 | 62 | 30% | 18.6 |
| 合计 | 10 | — | — | — | — | 458.8 |
折算人天的算法为：人数 × 有效工作日 × 投入比例。投入比例扣除的是会议、答疑、线上问题处理、代码评审等支持性工作占用的时间，不同角色取值不同，理由在下一节解释。
表二：需求人力估算表
| 需求条目 | 优先级 | 后端人天 | 前端人天 | 测试人天 | 合计人天 |
|---|---|---|---|---|---|
| 订单导出功能改造 | P0 | 40 | 24 | 16 | 80 |
| 支付渠道接入 | P0 | 56 | 16 | 24 | 96 |
| 用户权限模型重构 | P1 | 48 | 8 | 12 | 68 |
| 报表页面性能优化 | P1 | 24 | 32 | 8 | 64 |
| 消息中心改版 | P1 | 16 | 40 | 12 | 68 |
| 移动端适配 | P2 | 8 | 32 | 12 | 52 |
| 日志检索优化 | P2 | 24 | 0 | 8 | 32 |
| 内部工具升级 | P2 | 16 | 8 | 4 | 28 |
| 合计 | — | 232 | 160 | 96 | 488 |
表三：供需对比与缺口结论
| 角色 | 可用人天 | 需求人天 | 缺口（负数为缺口） | 缺口占比 |
|---|---|---|---|---|
| 后端 | 198.4 | 232 | -33.6 | -16.9% |
| 前端 | 148.8 | 160 | -11.2 | -7.5% |
| 测试 | 93.0 | 96 | -3.0 | -3.2% |
| 团队负责人 | 18.6 | — | +18.6 | — |
| 合计 | 458.8 | 488 | -29.2 | -6.0% |
结论：整体缺口29.2人天，约6.0%；分角色看，后端缺口最集中，为33.6人天，前端和测试缺口较小。负责人的18.6人天为管理投入，不参与交付需求匹配，单列展示。
表四：缺口调整动作示例
| 顺序 | 调整动作 | 作用对象 | 预计释放人天 |
|---|---|---|---|
| 1 | P2需求“内部工具升级”延至下季度 | 后端、前端、测试 | 28 |
| 2 | P1需求“消息中心改版”拆分，本期只做核心链路 | 前端 | 16 |
| 3 | 后端从协作团队借调1人，投入半个季度 | 后端 | 约20 |
执行前两项后，整体缺口由29.2人天降至约-1.2人天，后端缺口由33.6降至约-5.6人天，再叠加借调即可覆盖。调整动作按“先减需求、再调范围、最后调人力”的顺序执行，理由在下一节说明。
逐项解释：每个字段为什么这样填
可用天数为什么要扣除假期、会议与支持性工作
周期工作日是名义值，直接拿来当容量会系统性高估。法定节假日和团队统一安排的培训属于确定不投入的时间，必须扣除；会议、答疑、代码评审、线上问题处理属于日常必然发生但难以逐条排期的支持性工作，用投入比例统一折算。示例中后端和前端取80%，是因为这两个角色的评审和联调占用较多；测试取75%，因为测试环境维护和问题复现占用更集中。常见填错方式是只扣假期、不扣支持性工作，导致容量虚高，缺口被掩盖到执行中期才暴露。
投入比例按角色设定还是按人设定
按角色设定适合人员职责相对统一的团队，填写快、口径稳定，示例采用这种方式。按人设定更精确，适合团队内同一角色承担差异很大的工作，比如一名后端同时承担一半运维职责。取舍标准是：如果同一角色内个体差异超过10个百分点，就按人设定；否则按角色设定，避免表格过度复杂而难以维护。两种方式不能混用在同一张表里，否则合计口径会失真。
需求估算用人天直填还是相对估算
人天直填适合需求已经过技术评审、拆分到可执行粒度的情况，示例中的8条需求都处于这个状态。相对估算（如故事点）适合需求粒度不均、团队刚建立估算习惯的阶段，但用于容量对比时需要先换算成人天，换算系数要固定并写明依据。常见错误是同一张表里部分需求用人天、部分用故事点，导致合计无法与容量相减。
缺口用绝对人天还是百分比表达
两者都保留，用途不同。绝对人天用于决定具体砍哪条需求、借调几个人；百分比用于跨角色、跨周期比较紧张程度。示例中后端缺口33.6人天、占比16.9%，说明它既在总量上最大，在相对比例上也最紧张，应优先处理。只写百分比会让调整动作失去计量基础，只写绝对数则难以判断哪个角色更吃紧。
调整动作为什么按“减需求、调范围、调人力”排序
排序依据是确定性和成本。削减或延后低优先级需求，决策在团队内部即可完成，对交付承诺影响可控；拆分需求缩小范围需要与需求方确认，协调成本上升；借调或加班涉及其他团队和人员状态，成本最高且不确定性最大。先做前两步，往往已经能覆盖大部分缺口，避免一发现缺口就诉诸加人。示例中前两步释放44人天，已覆盖整体缺口的绝大部分。
可迁移规律：换团队、换周期怎么改
这套示例中有三部分应当固定下来，换任何场景都不变：一是口径一致，可用人力和需求人力都以人天计、都扣除非投入时间；二是供需同表，容量、需求、缺口、调整动作放在同一份表里，避免各算各的；三是缺口必须有对应动作，每个负数后面都要跟一条可执行的处理方式。
需要随场景调整的部分包括：
- 周期长度：季度适合需求相对稳定的团队；需求变化快的团队可改为月度滚动，每月重算一次，季度表只做汇总。
- 投入比例：新团队会议和协作占比通常更高，比例可先取低值，运行一两个周期后用实际工时记录校准。
- 估算粒度：周期越短，需求越要拆细，否则单条需求的估算误差会主导整张表的结果。
从季度扩展到半年时，不建议简单把季度数字乘以二。半年周期内人员变动、需求插入的概率更高，应按月或按季度分段测算再汇总，并在每段之间留出缓冲。规则复用时可以按以下检查点核对：口径是否仍然统一、投入比例是否有实际数据支撑、缺口是否都配了动作、调整动作是否按确定性排序、上一周期的估算偏差是否已回填修正。
要让这些检查点持续有效，测算结果需要和实际投入对上。在ONES中，可以把需求条目建为工作项并标注优先级和估算人天，执行过程中通过工时记录沉淀实际投入，周期结束时对比估算与实际，用偏差修正下一轮的投入比例和估算习惯。这样容量表就从一次性文档变成可迭代的管理依据。
适用边界：这套规则管什么、不管什么
这套规则只解决一件事：在给定周期内，一个团队的可用人力与已识别需求之间是否平衡，缺口有多大。它输出的是人天层面的供需结论和调整方向，不替代后续的管理决策。
以下事项不在本文规则的处理范围内：
- 项目组合层面的承接取舍：多个项目之间如何分配资源、哪个项目优先获得人力，属于组合管理决策，容量表只提供输入数据。
- 具体到人的排期与任务分配：谁在哪一周做哪条需求，属于排期范畴，需要在容量结论确定后另行安排。
- 工具产品的功能对比与选型：本文不涉及。
示例数据本身也有假设限制：人员在整个季度内保持稳定、需求在期初已基本识别、投入比例在期内不变。如果团队存在较大比例的人员流动、需求以插入式为主，或投入比例波动明显，直接套用示例数字会失真，应缩短测算周期并提高重算频率。示例中的人数和人天仅用于演示填写方法，不能作为任何团队的基准值直接引用。
常见问题
团队刚组建、还没有历史工时数据，投入比例怎么定？
可以先取一个偏保守的初始值，例如直接交付角色取70%–80%，运行一两个周期后用实际工时记录校准。校准方法是把周期内实际投入需求的人天除以有效工作日，得到真实投入比例，再与表内取值对比。新团队会议和协作占比通常更高，初始值取低一些，缺口会提前暴露，比取高值后执行到中期才发现容量不够更可控。
需求在季度中途插入，已经算好的容量表怎么处理？
插入需求时，把它按同样的估算口径补进需求人力表，重新计算供需对比，并同步更新调整动作。如果插入频繁，说明季度周期对当前团队偏长，可以改为月度滚动测算，季度表只做汇总。无论哪种方式，插入的需求都要标注优先级，否则缺口出现时无法判断先动哪一条。
估算人天和实际投入偏差很大，规则要怎么修正？
先区分偏差来源：如果多条需求同向偏高或偏低，通常是估算习惯问题，可以调整估算基准或换算系数；如果集中在某类需求上，说明该类需求的拆分粒度不够，需要拆细后再估。修正后的口径要写进下一轮表格，并保持一段时间不变，频繁改口径会让跨周期对比失去意义。
这套容量表算出的缺口，能直接作为项目是否承接的依据吗？
容量表提供的是人天层面的供需结论，可以作为输入，项目是否承接还涉及多个项目之间的资源分配和优先级判断，属于组合层面的决策。本文规则只负责把缺口算清楚、给出调整方向，承接取舍需要在组合层面另行讨论。
容量测算结果怎么持续跟踪，避免每季度重新手工统计？
可以把需求条目建为工作项，标注优先级和估算人天，执行过程中通过工时记录回填实际投入。周期结束时对比估算与实际，用偏差修正下一轮的投入比例和估算习惯。在ONES中，需求、工时与投入分析可以在同一套数据上衔接，减少手工汇总的重复工作。
