研发资源缺口用“需求工时减去可用工时”来衡量，并按角色、时间窗和技能维度分别计算。先确定评估范围与时间窗，再把需求侧折算为可投入工时，把供给侧按工作日历、请假、会议与支持占用折算为可用工时，最后用缺口工时和缺口率两个指标表达，并结合技能匹配、需求波动和交付影响解读结果。
要点总览（TL;DR）
- 研发资源缺口用缺口工时（需求工时减可用工时）和缺口率（缺口工时除以需求工时）两个指标表达，按角色、时间窗和技能维度分别计算。
- 需求工时来自任务估算或历史同类任务折算，可用工时按人数×工作日×每日有效工时计算，再扣除请假、培训、支持与会议占用。
- 计算按锁定范围、汇总需求、折算可用、算缺口、技能交叉验证、复核异常六步推进，每步保留可复核的中间结果。
- 缺口率的分母固定为需求工时，需求工时为0时只报告缺口工时并注明缺口率不适用；样本过小时同时给出绝对值。
- 缺口率反映供需差额，不直接等于交付风险，解读时要结合估算精度、需求波动和技能结构缺口。
评估目标：缺口要回答哪个决策问题
研发资源缺口评估的价值在于支撑一个具体的资源判断，而不是做一次泛泛的人力盘点。开始计算之前，先写清楚这次评估要回答的决策问题，后续的口径选择才有依据。常见的决策问题有三类：是否承接一批新需求、是否调整已承诺的交付时间、是否需要提前补充某个角色的人力。三类问题对时间窗和精度的要求不同，承接新需求通常看未来一个季度，调整交付承诺往往聚焦单个项目周期，补充人力则要覆盖招聘和上手所需的前置期。
评估对象按角色或技能组划分，例如后端开发、前端开发、测试、数据工程，而不是笼统的“研发人数”。同一个团队里，后端缺口和测试缺口可能同时存在且方向相反，合并成一个总数会掩盖结构问题。时间窗建议固定为月度、季度或项目周期中的一种，并在整份评估中保持一致；跨时间窗比较时，要说明各期工作日天数的差异。
需要明确的是，本文的方法只回答“供需差多少”，不覆盖多项目之间的组合取舍，也不涉及具体人员的排期与任务分配。这两类问题分别属于项目组合容量规划和资源分配排期的范畴，缺口评估的输出是它们的输入之一。评估目标说明建议包含四项内容：决策问题、评估对象（角色或技能组清单）、时间窗、以及本次不覆盖的边界。
指标与范围：需求工时、可用工时与缺口率
缺口评估用两个核心指标表达：缺口工时和缺口率。缺口工时回答“差多少”，单位是人时（人×小时）；缺口率回答“差的比例有多大”，单位是百分比。两个指标配合使用，可以避免只看绝对量时对小团队缺口的低估，也避免只看比例时对大团队缺口规模的忽视。
| 指标名称 | 公式 | 单位 | 分母 | 时间窗 |
|---|---|---|---|---|
| 需求工时 | Σ（任务估算工时 × 数量），或按历史同类任务均值折算 | 人时 | 无 | 与评估时间窗一致 |
| 可用工时 | 人数 × 工作日天数 × 每日有效工时 | 人时 | 无 | 与评估时间窗一致 |
| 缺口工时 | 需求工时 − 可用工时 | 人时 | 无 | 与评估时间窗一致 |
| 缺口率 | 缺口工时 ÷ 需求工时 × 100% | 百分比 | 需求工时 | 与评估时间窗一致 |
缺口率的分母固定为需求工时，含义是“需求中有多大比例没有可用人力承接”。当需求工时为 0 时，缺口率没有定义，此时只报告缺口工时（结果为负值或零），并在结论中注明“本期无新增需求，缺口率不适用”，不要用 0% 或 100% 代替。当需求工时很小、样本只有一两个任务时，缺口率的波动会很大，建议同时给出需求工时的绝对值，让读者判断比例的参考价值。
拆分口径需要提前约定：按角色拆分时，每个角色单独计算需求工时、可用工时和缺口率，各角色缺口率不能简单平均成团队缺口率；团队层面的缺口率应以团队总需求工时为分母重新计算。按技能拆分时，同一角色内可再细分，例如后端中的特定中间件经验。按时间窗拆分时，月度数据适合观察波动，季度数据适合支撑人力决策，两种口径的结果不应混用比较。
数据口径与证据：需求侧和供给侧各取什么数
需求侧的数据来源主要有三类：已确认的需求清单及其任务拆解、任务估算记录、历史同类任务的实际工时。优先使用估算记录，因为它与当前任务的颗粒度一致；缺少估算时，用历史同类任务的工时均值乘以调整系数折算，并在口径说明中记录调整理由。需求清单要注明纳入标准，例如只统计已评审通过的需求，避免把意向性需求计入造成缺口虚高。
供给侧的数据来源包括人员名单、工作日历、请假与培训占用、支持与会议占用。人员名单以评估时间窗内实际可投入该项目或团队的人为准，兼职投入按投入比例折算。工作日历扣除法定节假日和公司统一假期。请假与培训按已批准的记录扣除，未批准的假期计划不计入。支持与会议占用包括线上值班、跨团队支持、固定例会等，可按历史统计的人均每周小时数折算。
有效工时系数是供给侧折算的关键参数，指每日名义工时中真正可用于任务交付的比例。设定依据应来自团队自身的记录，例如连续几周的工时日志或任务实际耗时统计；没有记录时，可以先按经验值试算，并在口径说明中标注“待验证”，下一周期用实际数据校准。系数一旦确定，同一时间窗内所有角色应使用同一口径，除非有证据表明不同角色的会议与支持占用差异显著。
缺失值与异常值需要预设处理规则：单个任务缺少估算时，用同类任务中位数填补并标记；估算工时超过同类任务均值三倍以上的，逐条复核是否包含非研发工作；人员名单中投入比例不明确的，按 100% 计入并在复核环节确认。当需求侧和供给侧的数据不可比时，例如需求按自然月统计而人员按项目周期投入，应统一换算到同一时间窗后再计算，换算过程写入口径清单。数据口径清单建议按“字段、来源、折算规则、缺失处理”四列记录，便于他人复算。
计算与评估步骤：从原始数据到缺口结论
计算按六个步骤推进，每一步都留下可复核的中间结果。
- 锁定范围与时间窗。确认评估对象（角色或技能组清单）、时间窗起止日期、纳入的需求范围。产出：评估范围说明。
- 汇总需求工时并按角色拆分。逐条汇总任务估算工时，按角色归集，得到各角色需求工时和团队总需求工时。产出：需求工时汇总表。
- 计算可用工时并扣除占用。按“人数 × 工作日 × 每日有效工时”计算名义可用工时，再扣除请假、培训、支持与会议占用。产出：各角色可用工时表。
- 计算缺口工时与缺口率。逐角色用需求工时减可用工时得到缺口工时，再除以该角色需求工时得到缺口率；团队层面用总需求工时作分母重新计算。产出：缺口结果表。
- 按技能维度交叉验证。在缺口最大的角色内，按关键技能再拆一层，检查总量缺口是否由某一技能集中造成。产出：技能维度缺口分布。
- 复核异常值与口径一致性。检查需求工时为 0 的角色、缺口率绝对值超过 100% 的角色、以及两侧时间窗是否一致。产出：复核记录与修订后的结论。
复核检查点建议至少包括四项：各角色需求工时之和是否等于团队总数；可用工时是否已扣除全部已批准占用；缺口率的分子分母是否来自同一时间窗；分母为零的情形是否已单独说明。完成复核后，缺口结论才能进入解读环节。
当需求工时分散在多个需求条目、人员可用性又受请假和支持任务影响时，手工汇总容易在口径上出错。ONES 的工作项工时记录可以按需求和任务沉淀估算与实际工时，成员与团队的工作日历、迭代容量数据则为可用工时提供来源，使需求侧和供给侧的数据在同一套工作项与成员记录中汇总，减少跨表核对的工作量。评估范围、时间窗和角色划分确定后，这些记录可以直接支撑上述六步计算中的汇总与复核动作。
算例：一个季度两个角色组的缺口计算
以下为演示情景，数值为假设，用于说明公式代入过程。某研发团队评估 2025 年第三季度（7 月至 9 月）的资源缺口，评估对象为后端开发和测试两个角色组。季度内工作日共 65 天，每日名义工时 8 小时，经团队工时记录校准，有效工时系数取 0.75，即每日有效工时 6 小时。
需求侧：后端开发承接需求 12 项，任务估算合计 1560 人时；测试承接需求 12 项，任务估算合计 980 人时。供给侧：后端开发 5 人，其中 1 人投入比例 50%，折算 4.5 人；测试 3 人，折算 3 人。请假与培训占用：后端合计 120 人时，测试合计 80 人时；支持与会议占用按人均每周 4 小时折算，季度约 13 周，后端 4.5 人 × 4 小时 × 13 周 ≈ 234 人时，测试 3 人 × 4 小时 × 13 周 = 156 人时。
| 角色组 | 需求工时（人时） | 名义可用工时（人时） | 请假培训占用（人时） | 支持会议占用（人时） | 可用工时（人时） | 缺口工时（人时） | 缺口率 |
|---|---|---|---|---|---|---|---|
| 后端开发 | 1560 | 4.5 × 65 × 6 = 1755 | 120 | 234 | 1401 | 159 | 159 ÷ 1560 ≈ 10.2% |
| 测试 | 980 | 3 × 65 × 6 = 1170 | 80 | 156 | 934 | 46 | 46 ÷ 980 ≈ 4.7% |
| 团队合计 | 2540 | 2925 | 200 | 390 | 2335 | 205 | 205 ÷ 2540 ≈ 8.1% |
按技能拆分后，后端开发内部的缺口并不均匀：消息中间件相关任务需求 420 人时，具备该技能的人力折算后可用约 300 人时，该技能缺口约 120 人时，占后端总缺口 159 人时的四分之三；其余后端任务缺口较小。测试侧的缺口集中在自动化测试脚本编写，手工测试任务基本可以覆盖。
结果解读：团队整体缺口率约 8.1%，绝对量 205 人时，规模上相当于约 0.5 人一个季度的有效产出。后端缺口大于测试，且主要由特定技能造成，行动指向可以是优先安排该技能的内部培训或外部支持，而不是简单地按总量补充人力；测试侧则可以通过提升自动化覆盖来缓解脚本编写压力。若下一季度需求继续增长，需要重新评估时间窗和有效工时系数后再计算。
解读与限制：缺口数字能说明什么、不能说明什么
缺口率反映的是需求工时与可用工时之间的差额比例，它本身不直接等于交付风险。缺口率为正说明按当前口径人力不足以覆盖全部需求，但实际影响取决于需求优先级、可延期空间和团队加班弹性。把缺口率直接当作项目延期概率或团队绩效结论，会超出这个指标的适用范围。
估算精度对结果影响明显。需求工时来自任务估算时，估算偏差会等比例传导到缺口工时和缺口率；历史类比折算虽然能补足缺失，但同类任务的界定本身带有主观判断。建议在结论中注明需求工时的来源构成，例如“80% 来自任务估算，20% 来自历史类比”，让读者判断结果的可信度。
需求波动与季节性因素会让单期缺口率失真。季度末集中交付、财年规划期需求集中下达，都可能使某一时间窗的缺口明显偏高。持续跟踪建议按同一口径逐期计算，观察趋势而非单点数值；口径本身也应定期迭代，例如有效工时系数每季度用实际工时记录校准一次，校准后的历史数据如需比较，应注明口径变化。
技能结构缺口与总量缺口的区别需要单独说明。总量缺口可以通过补充任意合格人力缓解，技能结构缺口则需要特定技能的人力或能力建设，两者的行动方案不同。分母为零和样本过小的情形已在指标定义中处理，解读时同样适用：需求工时为 0 时只报告缺口工时，样本过小时同时给出绝对值。缺口评估的输出是一组带口径说明的供需差额数据，它支撑资源决策，替代不了对需求优先级和交付承诺的综合判断。
常见问题
需求工时为0时，缺口率怎么处理？
需求工时为0时，缺口率没有定义，此时只报告缺口工时（结果为负值或零），并在结论中注明“本期无新增需求，缺口率不适用”。不要用0%或100%代替，否则会让人误以为供需完全匹配或需求全部未承接。如果同一份评估中部分角色需求工时为0，这些角色单独说明，其余角色照常计算缺口率。
各角色的缺口率能不能直接平均成团队缺口率？
不能直接平均。各角色缺口率的分母不同，简单平均会让需求工时小的角色获得与需求工时大的角色相同的权重。团队层面的缺口率应以团队总需求工时为分母重新计算，即团队缺口工时合计除以团队需求工时合计。角色缺口率用于识别结构问题，团队缺口率用于判断总量规模，两个层次的结果分开呈现。
有效工时系数没有历史记录时怎么设定？
可以先按经验值试算，并在口径说明中标注“待验证”，下一周期用团队实际的工时日志或任务耗时统计校准。系数一旦确定，同一时间窗内所有角色使用同一口径；如果有证据表明不同角色的会议与支持占用差异显著，可以分角色设定并记录依据。校准后如需与历史数据比较，应注明口径变化。
缺口评估的结果能不能直接用来决定招人数量？
缺口工时可以作为招人决策的输入之一，但需要先换算：缺口工时除以单个新人在时间窗内的有效产出，才是大致的人数需求，同时要考虑招聘周期和上手期。技能结构缺口还需要判断是补充特定技能人力还是内部培养。缺口评估回答的是供需差多少，招人决策还要结合需求优先级、交付承诺和预算综合判断。
需求侧和供给侧的时间窗不一致时怎么办？
先把两侧统一换算到同一时间窗再计算。例如需求按自然月统计、人员按项目周期投入时，将人员投入比例折算到自然月，或将需求工时按项目周期归集。换算过程写入口径清单，注明换算方法和假设。两侧时间窗不一致直接相减，得到的缺口工时没有意义。
