研发资源容量描述研发团队在一段确定时间内能够稳定交付的有效工作量，是判断需求能否被承接的供给基准。它通常以人天、人时或可承载的工作项数量表达，需要与同期需求总量对照才有决策意义。本文解释容量的定义、构成与计算口径，并区分容量、负载和利用率三个相邻概念。
要点总览（TL;DR）
- 研发资源容量是团队在确定周期内、既定人员与工时约束下能稳定交付的有效工作量，常用人天、人时或可承载工作项数量表达。
- 有效容量要在名义人力基础上扣减假期、会议、培训、运维支持等占用，并按角色分别统计，才能反映可承接的工作类型。
- 计算口径为：有效容量＝人数×周期可用工时×可投入比例；容量回答能投入多少，负载回答已安排多少，利用率是两者之比。
- 测算时需避免把在岗人数当容量、把容量当个人排期、忽略技能结构或用峰值产能代替稳定容量。
- 容量数据需固定输入来源与更新节奏，在规划前更新、复盘中校正，并与需求总量在同一视图中对照。
研发资源容量的直接定义
研发资源容量指研发团队在特定时间范围内，在既定人员、技能、工时制度和其他投入约束下，能够稳定投入的有效工作量。这个定义包含三个限定：时间范围确定，例如一个迭代、一个季度或一个财年；投入约束明确，包括在岗人数、可用工时和技能结构；产出限定为“稳定可交付”，即按正常工作节奏可以持续维持的水平，而非短期冲刺的峰值。
容量的常用计量单位有三种。人天和人时适合按工时口径汇总，便于与需求估算的工作量直接相减；可承载的工作项数量适合需求颗粒度较均匀的团队，用“本迭代大约能承接多少个需求”来表达。三种单位可以换算，但同一份容量数据应保持口径一致，避免一部分需求按人天估算、另一部分按工作项计数。
容量是供给侧概念，单独看一个数字没有判断价值。8人团队一个迭代有80人天容量，这个信息只有在对照同期需求总量约110人天时，才能得出“存在约30人天缺口”的结论。因此容量测算的完整动作是“算供给、汇总需求、对照缺口”，三者缺一不可。
容量包括什么、不包括什么
容量统计的对象是有效可投入时间，起点是名义人力，终点是扣除各类非项目占用后的剩余部分。名义人数指在岗人数，名义工时指按制度应出勤的工时；有效容量则要在名义基础上扣减休假、法定节假日、会议、培训、运维支持、招聘面试、临时支援等占用。两者之间的差额往往不小，一个名义上满编的团队，实际可投入比例常在70%至85%之间，具体取决于团队承担的支撑性事务多少。
容量构成可以按以下清单逐项核对：
- 基础人力：周期内平均在岗人数，需考虑入职、离职、借调带来的月中变化。
- 制度工时：按工作日和每日标准工时计算的名义总工时。
- 假期折损：年假、调休、法定节假日及团队统一休假安排。
- 事务折损：例会、评审、培训、值班运维、面试等非直接交付投入。
- 技能与角色结构：不同角色可承接的工作类型不同，容量需按角色分别统计。
本文的范围限定在可用人力的供需测算。具体到某个人哪天做哪个任务的人员排期，属于排期与任务分配方法讨论的内容；多个项目之间如何取舍、哪个项目优先占用有限容量，属于项目组合资源容量规划的范畴；工时如何折算成本、如何结算，属于工时核算与成本结算主题。容量测算给出的是“有多少可用供给”这一层结论，后续的分配与取舍在相邻主题中展开。
容量是怎么算出来的：组成与计算机制
从团队人数推导到有效容量，需要经过基础人力、工时折算、折损扣减和角色拆分四个环节。每个环节对应若干可记录的字段，把这些字段固定下来，容量测算才能在不同周期之间比较，也才能在复盘时校正假设。
| 字段 | 含义 | 示例取值 |
|---|---|---|
| 在岗人数 | 周期内平均可参与研发的人数 | 8人 |
| 周期工作日 | 扣除法定节假日后的工作日数 | 10天 |
| 每日标准工时 | 制度规定的每日工作时长 | 8小时 |
| 可投入比例 | 扣除假期、会议、培训、支持性事务后的可交付占比 | 75% |
| 角色结构 | 各角色人数及可承接的工作类型 | 后端3人、前端2人、测试2人、设计1人 |
| 有效容量 | 周期内可稳定投入的有效工作量 | 480人时，约60人天 |
计算公式为：有效容量＝人数×周期可用工时×可投入比例。以8人团队、10个工作日、每日8小时、可投入比例75%为例，名义工时为8×10×8＝640人时，有效容量为640×75%＝480人时，折合60人天。若团队按角色分别统计，则后端3人对应180人时、前端2人对应120人时，依此类推。
技能与角色结构会改变容量的可用性。总容量60人天并不意味着任何类型的工作都能承接60人天：测试角色只有2人，若同期需求集中在前端开发，前端容量会先被耗尽，而测试容量出现闲置。因此容量表按角色分行记录，比只给一个总数更能支撑后续的需求对照。
容量、负载与利用率：容易混淆的三个概念
三个概念回答不同问题，混用会导致判断失真。容量回答“能投入多少”，是供给上限；负载回答“已经安排了多少”，是需求侧已承诺的部分；利用率是负载与容量之比，反映供给被占用的程度。三者对照使用，才能看出团队是空闲、饱和还是超载。
| 概念 | 回答的问题 | 计算口径 | 典型用途 |
|---|---|---|---|
| 容量 | 这段时间能投入多少有效工作量 | 人数×可用工时×可投入比例 | 设定承接上限，评估需求是否可接 |
| 负载 | 已经安排了多少工作量 | 已承诺需求的工作量汇总 | 查看当前排期是否已排满 |
| 利用率 | 供给被占用的程度 | 负载÷容量 | 识别空闲、饱和与超载状态 |
利用率高不等于产出高。利用率接近100%时，团队没有余量应对需求变更、缺陷修复和临时支持，任何插入事项都会挤压原计划，交付周期反而拉长。保留10%至20%的缓冲是常见做法，具体比例取决于需求波动程度和支撑性事务的多少。利用率长期偏低则说明容量被高估或需求储备不足，需要回到容量假设和需求池两端检查。
把需求侧总量与容量对照，得到的是供需缺口：需求总量减去容量为正，说明需要削减范围、延后需求或补充人力；为负则说明还有承接空间。缺口判断应分角色进行，总数平衡但关键角色超载的情况同样需要处理。
一个具体例子与常见误解
以下为演示情景，用于说明测算路径，不代表任何真实团队数据。某8人研发团队准备规划一个为期两周的迭代，含10个工作日。团队先统计在岗情况：1人计划休年假3天，折损24人时；全员参加迭代计划会、评审会和周会合计约6小时，折损48人时；1人每周有半天值班运维，两周折损8人时。名义工时640人时，扣除上述折损80人时，剩余560人时；再按历史数据预留约15%的变更与支持缓冲，有效容量约为476人时，取整为60人天。按角色拆分后，后端约22人天、前端约15人天、测试约15人天、设计约8人天。
需求侧同期汇总的待办需求估算为72人天，其中前端相关需求约20人天。对照后可见总量缺口约12人天，前端角色缺口约5人天，团队据此决定把一个前端需求延后到下一迭代，并拆分一个跨角色需求以平衡负载。
测算过程中有几类误解需要纠正：
- 把在岗人数直接当作容量。8人乘以10天得到80人天，忽略了假期、会议和支持性事务，实际可用往往只有60人天左右，按80人天承接需求必然延期。
- 把容量等同于个人排期表。容量是团队层面的供给汇总，排期是把具体任务落到人和日期上的动作，前者是后者的输入约束，两者不是同一份数据。
- 忽略技能结构。总数60人天看似充足，但测试只有15人天，需求若集中在测试环节，容量会在局部耗尽，出现“总量够、局部堵”的情况。
- 用峰值产能代替稳定容量。短期加班可以拉高产出，但不可持续，按峰值测算会让每个迭代都依赖加班来兑现承诺。
把容量数据落到协作流程中
容量测算结果只有进入日常协作流程，才会持续影响承接决策。基本做法是固定输入来源、明确维护角色、把容量与需求放在同一视图中对照，并在迭代评审和复盘中校正假设。
输入来源方面，在岗人数和假期安排来自人事与团队负责人的排班信息，会议与培训占用来自团队日历，支持性事务来自值班和运维记录。更新节奏通常与规划周期对齐：迭代规划前更新一次，周期内出现人员变动或长假时补充调整，季度层面再做一次汇总复核。
角色分工方面，团队负责人维护容量数据并对假设负责，包括可投入比例的取值依据；需求方在提报需求时对照容量提报，避免把明显超出供给的需求直接排入。容量数据与需求总量在同一视图中呈现，承接决策才有共同依据。
ONES 资源和工时管理解决方案提供资源规划视图，管理者可以查看成员的工作量、可用性和饱和情况，按业务优先级安排团队资源，使可用资源与需求之间保持平衡；同时支持查看项目和团队的资源利用率及负荷度。ONES Resource 通过甘特视图支持项目资源规划与进度跟踪，可按工作数量和工时规模了解成员排期，并通过筛选与分组查看成员在不同项目的投入比重，还能实时查看成员每日投入饱和明细以识别规划风险。这些视图承载的是容量记录与需求对照的管理动作，容量假设本身的取值仍需团队根据自身数据确定。
评审与复盘环节，团队在迭代结束后对照实际投入与测算容量，记录偏差来源：是休假估计不足、支持性事务超出预期，还是需求估算偏小。把偏差写回下一周期的可投入比例和缓冲设置，容量数据才会逐步贴近实际，成为可复用的规划基准。
常见问题
研发资源容量应该按团队总数统计，还是按角色分别统计？
两种口径可以并存，但用途不同。团队总数适合判断整体供需缺口，例如总量60人天对需求72人天，缺口约12人天。按角色统计则用于判断缺口落在哪个环节：测试只有15人天容量，需求若集中在测试，总量平衡也会出现局部堵塞。建议容量表按角色分行记录，再汇总出总数，承接决策时先看总数、再看关键角色。
可投入比例取多少比较合理？
可投入比例取决于团队承担的支撑性事务多少，常见区间在70%至85%。取值方法是用历史数据反推：统计过去几个周期实际用于交付的工时占名义工时的比例，再结合本周期已知的假期、培训、值班安排做调整。比例确定后应在复盘中持续校正，偏差较大时记录原因，例如支持性事务超出预期或需求估算偏小，而不是每期凭感觉重设。
容量测算和人员排期是什么关系？
容量是团队层面的供给汇总，回答“这个周期能投入多少有效工作量”；排期是把具体任务落到人和日期上的动作。容量是排期的输入约束：先有容量上限，再在范围内安排任务，排期结果不应超过容量。把两者混为一谈，容易把某几个人的日程表当成团队容量，忽略角色结构和整体供需缺口。
利用率是不是越高越好？
利用率反映供给被占用的程度，接近100%时团队没有余量应对需求变更、缺陷修复和临时支持，任何插入事项都会挤压原计划，交付周期反而拉长。保留10%至20%的缓冲是常见做法，具体比例取决于需求波动程度和支撑性事务多少。利用率长期偏低则说明容量被高估或需求储备不足，需要回到容量假设和需求池两端检查。
容量数据多久更新一次，由谁维护？
更新节奏通常与规划周期对齐：迭代规划前更新一次，周期内出现人员变动或长假时补充调整，季度层面再做汇总复核。团队负责人维护容量数据并对假设负责，包括可投入比例的取值依据；需求方在提报需求时对照容量提报。迭代结束后对照实际投入与测算容量记录偏差来源，把结果写回下一周期的比例和缓冲设置。
