评估研发资源缺口，本质是把同一时间窗、同一技能口径下的“需求侧所需工时”与“供给侧可用工时”相减，并用可追溯的原始记录支撑两端数据。需要准备需求清单与估算工时、人员名册与可用工时扣减项，再统一单位、时间窗和角色粒度，最后用历史交付偏差和抽样核对验证结论。ONES可在工作项与工时记录中承载部分供需数据，本文按通用方法说明字段、公式与核验要求。
要点总览（TL;DR）
- 评估研发资源缺口，核心是在同一时间窗、同一角色或技能粒度下，用需求侧所需工时减去供给侧可用工时，两端数据都要有可追溯的原始记录。
- 需求侧需要需求或项目清单、按角色拆分的估算工时及置信度区间、优先级、交付时间窗、依赖关系和变更记录。
- 供给侧从人员名册出发，按“工作日×投入比例−请假培训−支持类占用−已承诺其他项目工时”的顺序计算可用工时。
- 缺口率以所需工时为分母，分母为零或数据缺失的分组标注为不可计算；团队汇总时加权缺口率与绝对缺口工时分开报告。
- 结论要用历史交付偏差校准估算、抽样核对工时记录，并注明数据截止日期，缺口指标不宜直接等同于绩效评价。
评估目标：缺口要回答哪个决策问题
缺口评估先要明确它服务于哪一类决策，否则容易算成泛泛的人力盘点。常见用途有四类：判断是否需要补充人力、判断是否调整需求优先级、判断是否引入外协、判断交付时间是否需要顺延。四类决策对数据精度的要求不同，补人决策更关注技能匹配和到岗周期，调优先级更关注需求之间的可替代性，外协决策需要区分可外包的工作内容，延期决策则要看清关键路径上的资源约束。
评估目标说明至少写清三项内容。第一是决策问题，用一句话描述本次评估要支持的具体选择，例如“下季度后端开发是否需要增加两名工程师”。第二是时间窗与组织范围，明确统计哪几周或哪几个月、覆盖哪些团队和角色，跨团队借调人员归属哪一方。第三是边界，供需缺口回答的是“数量差多少”，排期冲突回答的是“同一时间谁先做哪件事”，两者可以同时使用，但计算口径不同，不宜混在一张表里下结论。
目标说明建议形成一页文档，包含决策问题、时间窗、组织范围、技能范围、数据截止日期和责任人。数据截止日期尤其重要，缺口结论只对截止日期之前录入的数据有效，后续需求变更或人员变动都需要重新计算。
需求侧数据：所需工时从哪里来
需求侧所需工时来自对工作内容的估算，而不是来自人员现有排期。采集时应以需求或项目为最小单元，逐条记录估算值，并保留估算依据，便于后续校准。下表列出常用字段及其来源。
| 字段 | 说明 | 典型来源 | 责任人 | 更新频率 |
|---|---|---|---|---|
| 需求/项目编号与名称 | 唯一标识，便于与工作项对应 | 需求管理或项目管理系统 | 产品经理/项目经理 | 随需求创建 |
| 优先级 | 用于区分必须交付与可调整部分 | 需求评审记录 | 产品负责人 | 评审后更新 |
| 估算工时 | 按角色或技能拆分的工时值 | 估算会议、历史类比 | 技术负责人 | 估算确认时 |
| 估算方式与置信度 | 标明是专家判断、类比还是三点估算，给出区间 | 估算记录 | 技术负责人 | 估算确认时 |
| 交付时间窗 | 需求计划完成的周或月 | 版本计划、路线图 | 项目经理 | 计划变更时 |
| 依赖关系 | 前置需求、外部接口、环境准备等 | 需求文档、架构评审 | 技术负责人 | 评审后更新 |
| 变更记录 | 范围增减及对应工时调整 | 变更单、评审纪要 | 项目经理 | 每次变更 |
估算工时应按角色拆分，例如后端开发、前端开发、测试分别给出工时，避免只记一个总数导致后续无法与供给侧技能口径对齐。估算置信度用区间表达更实用，例如“80小时，区间70至100小时”，区间宽度本身反映不确定性。需求变更记录要保留变更前后的工时差，否则缺口计算会把已取消的工作仍算作需求。
供给侧数据：可用工时怎么算
可用工时从人员名册出发，先算理论工作日，再逐项扣减非项目占用，最后扣除已承诺的其他项目投入。计算顺序影响结果，建议固定为：日历工作日×投入比例−请假与培训−支持类占用−已承诺的其他项目工时。
| 字段 | 说明 | 典型来源 | 责任人 | 更新频率 |
|---|---|---|---|---|
| 人员名册 | 姓名、团队、角色、在职状态 | 人力资源系统 | 团队负责人 | 入离职时 |
| 技能标签 | 可承担的技术栈或职能 | 技能矩阵、负责人确认 | 技术负责人 | 季度更新 |
| 可用工作日 | 扣除法定节假日后的工作日 | 公司日历 | 项目经理 | 年初或调休时 |
| 投入比例 | 该成员投入本团队项目的比例 | 团队约定 | 团队负责人 | 季度更新 |
| 请假与培训 | 已批准的休假、培训、出差 | 考勤与培训记录 | 成员本人/负责人 | 审批后 |
| 支持类占用 | 线上值班、答疑、招聘面试等固定占用 | 值班表、工作记录 | 团队负责人 | 月度更新 |
| 已承诺占用 | 其他项目已分配的工时 | 项目计划、工时记录 | 项目经理 | 每周更新 |
扣减清单要写清每一项的扣除依据和是否可调整。请假与培训属于刚性扣减；支持类占用中有一部分可以压缩，应单独标注为“可协调占用”，便于在缺口结论中区分刚性缺口和弹性缺口。多项目分摊时，同一成员在各项目的投入比例之和不应超过其投入比例上限，超出部分说明数据存在冲突，需要先核对再计算。
口径统一：让供需两端可比
供需两端数据来源不同，直接相减容易得出错误结论。口径统一要处理四类问题：工时单位、时间窗、技能粒度、缺失与特殊用工状态。
| 口径项 | 需求侧常见表达 | 供给侧常见表达 | 统一后口径 |
|---|---|---|---|
| 工时单位 | 人天或故事点 | 小时 | 统一换算为小时，人天按团队约定的小时数换算并记录换算规则 |
| 时间窗 | 按版本或需求批次 | 按周或按月 | 统一到周或月，跨窗口需求按比例拆分并注明拆分依据 |
| 技能粒度 | 按需求角色 | 按人员技能标签 | 建立角色与技能标签的对照表，无法对应的归入“其他”并单独说明 |
| 特殊状态 | 通常不体现 | 兼职、借调、实习 | 按实际投入比例折算，借调人员只计入借入方，避免重复计算 |
缺失值处理要提前约定规则。估算工时缺失的需求不按平均值填补，应标注为“未估算”并单独列出数量；人员投入比例缺失时按团队默认值处理并注明。分母为零的情况，例如某角色在统计窗口内没有可用工时，缺口率不计算，只报告绝对缺口工时并标注原因。口径对照表应随评估结果一同留存，便于他人复算。
计算步骤与公式：缺口怎么算出来
缺口计算按角色和时间窗分组进行，步骤固定，便于逐期对比。核心公式为：缺口工时=所需工时−可用工时；缺口率=缺口工时÷所需工时×100%。缺口率为正表示供给不足，为负表示供给有余，两种结果都需要结合需求优先级解读。
- 确定统计窗口，例如按周或按月，列出窗口内每个角色的需求清单。
- 汇总每个角色在每个窗口的所需工时，只计入优先级为必须交付的需求，可调整需求单独列出。
- 按扣减清单计算每个角色在每个窗口的可用工时。
- 逐组相减得到缺口工时，按公式计算缺口率。
- 对分母为零或数据缺失的分组标注“不可计算”，不参与团队汇总。
- 汇总到团队层级时，以所需工时为权重对缺口率加权，或直接汇总绝对缺口工时，两种方式分开报告。
汇总方式影响结论表达。加权缺口率反映整体供需紧张程度，绝对缺口工时反映需要补充的工作量，两者回答的问题不同。若团队内角色之间不可替代，团队级缺口率只能作为概览，决策仍应回到角色粒度。缺口为负值时，说明该角色在窗口内有余量，可考虑承接其他需求，但需确认余量是否来自估算偏保守。
算例：一个季度两个角色的缺口
以下为演示情景，数字仅用于说明计算过程。某团队评估一个季度（按13周计）后端开发与测试两个角色的缺口。后端开发所需工时为520小时，可用工时为460小时；测试所需工时为300小时，可用工时为330小时。
后端开发：缺口工时=520−460=60小时，缺口率=60÷520×100%≈11.5%，表示供给不足。测试：缺口工时=300−330=−30小时，缺口率=−30÷300×100%=−10%，表示供给有余。若该季度测试角色中有2周因借调无法投入，应在可用工时中扣除后再计算，扣除后若可用工时降至290小时，则缺口变为10小时，结论从有余转为不足。
结果呈现建议用表格按角色和月份列出所需工时、可用工时、缺口工时、缺口率和数据状态。数据状态列标注“完整”“部分缺失”“不可计算”，便于阅读者判断哪些数字可以直接使用。异常标注包括：某角色缺口率显著高于其他角色、某月可用工时因集中休假大幅下降、某需求估算区间过宽导致缺口范围扩大。
证据核验与解读限制
缺口结论的可信度取决于两端数据的质量，核验应覆盖估算与记录两个环节。用历史交付偏差校准估算工时是常用做法：取过去若干已完成需求，比较估算工时与实际工时，计算偏差中位数或偏差区间，再对当前估算做相应调整。若历史偏差普遍偏低估，当前缺口可能被低估，应在结论中说明调整幅度。
抽样核对工时记录用于验证供给侧数据。随机抽取若干成员若干周的工时登记，与项目计划、会议记录、代码提交等旁证比对，检查是否存在漏登、重复登记或跨项目分摊错误。抽样比例和核对结果应记录在核验清单中，作为结论附件。
解读缺口指标时需注意三点限制。第一，缺口反映供需数量关系，不能直接等同于个人绩效或团队能力评价。第二，估算误差和数据滞后会传导到缺口结果，估算区间越宽、数据更新越慢，结论的时效性越弱，建议注明数据截止日期和下次复核时间。第三，缺口为负不等于可以无限承接新需求，余量可能被未登记的支持类工作占用，需结合支持类占用记录判断。
当团队在ONES中管理需求与工时，需求清单、估算工时、成员投入与工时日志可以在工作项和工时记录中沉淀，资源规划视图可按项目查看成员投入比重，工时日志支持查询与导出，便于按上述口径汇总供需数据并留存核验依据。具体字段配置和报表口径以团队实际使用版本为准。
常见问题
需求估算只有故事点、没有工时，还能算研发资源缺口吗？
可以算，但需要先建立换算关系。常见做法是用团队历史数据求出“每个故事点对应的实际工时”，按角色分别统计，再把故事点估算折算为工时。换算系数应写明来源和统计区间，例如取过去若干个已完成迭代的中位数。若团队刚引入故事点、历史样本不足，建议对关键需求补充专家工时估算，并在结论中标注哪些需求使用了折算、哪些使用了直接估算，避免两类数据混在一起比较。
统计窗口内有人中途入职或离职，可用工时怎么处理？
按实际在职天数折算，不按整月或整季度计入。具体做法是先确定该成员在窗口内的在职工作日，再乘以投入比例，然后扣减请假与培训。离职成员的已承诺工作要同步从需求侧确认由谁承接，否则需求工时仍留在原角色，可用工时却已减少，缺口会被放大。入职成员在熟悉期内的产出效率通常低于成熟成员，可在可用工时上做过渡期折扣并注明折扣依据，便于阅读者理解结论的保守程度。
缺口算出来是负值，是否说明团队可以放心接新需求？
负值只说明在该统计窗口和该角色上，可用工时大于已计入的需求工时。接新需求前还要确认三件事：余量是否来自估算偏保守，可用工时中是否还有未登记的支持类占用，新需求所需的技能是否与该角色余量匹配。若余量集中在某几周而新需求跨越整个季度，时间分布不匹配同样会形成局部缺口。建议把负值按周展开查看分布，再结合支持类占用记录判断可动用的真实余量。
用历史交付偏差校准估算工时，具体怎么操作？
取过去一段时间的已完成需求，逐条比较估算工时与实际工时，计算偏差率（实际减估算再除以估算），取中位数或分位数作为调整系数。若中位数为正，说明历史普遍低估，可对当前估算按同比例上调后再算缺口。样本要覆盖同类工作内容，跨团队或跨技术栈的偏差不宜直接套用。调整后的结果建议与未调整结果并列呈现，让阅读者看到校准对缺口结论的影响幅度。
缺口评估结果多久需要复核一次？
复核频率取决于需求变更和人员变动的速度。需求侧变更频繁、人员借调较多的团队，建议按周或按迭代复核；需求相对稳定的团队可按月复核。每次复核要更新数据截止日期，并记录上次结论与本次结论的差异及原因，例如新增需求、估算调整或人员变动。若两次复核之间缺口方向发生反转，应优先检查数据录入是否完整，再判断是否属于真实的供需变化。
