研发资源缺口分析报告模板:空白表与填写规范
研发资源缺口分析报告模板围绕“缺口口径—影响判断—应对建议”组织内容,包含报告基本信息、人力供需测算、缺口明细、影响评估、应对建议与责任人五张表。它适合按季度或月度评估研发团队可用人力与需求人力的差距,角色口径可按职能或技能组划分。报告中的工时与投入数据可以在ONES中取数,模板本身保持通用。
Table of Contents
要点总览(TL;DR)
- 模板由五张表组成:报告基本信息、人力供需测算、缺口明细、影响评估、应对建议与责任人,按“缺口口径—影响判断—应对建议”顺序填写。
- 缺口数量=需求人力−可用人力,缺口率=缺口数量÷需求人力×100%;统计周期、角色口径和工时单位需在填写前统一。
- 统计周期、角色口径、供需数据、影响等级、应对方式与责任人为必填;覆盖团队、缺口出现时间、判断依据等可按用途选填。
- 填写示例演示了后端持续性短缺、测试短期峰值和前端阶段性富余三类缺口如何联动影响评估与应对动作。
- 模板可按团队规模裁剪角色粒度,按季度或月度滚动更新,并通过版本号与变更记录保留历史口径。
可复制空白模板:五张表组成一份缺口报告
下面五张表构成一份完整的缺口分析报告。使用时按顺序填写:先登记报告范围,再测算供需,接着拆出缺口明细,然后判断影响,最后落到应对动作和责任人。表格中的空白行可按角色数量增减。
表1 报告基本信息
| 字段 | 填写内容 |
|---|---|
| 报告名称 | |
| 统计周期 | |
| 覆盖团队/项目 | |
| 角色口径说明 | |
| 工时单位 | |
| 编制人 | |
| 复核人 | |
| 编制日期 | |
| 版本号 |
表2 人力供需测算
| 角色/技能组 | 在岗人数 | 人均可用工时 | 可用人力(FTE) | 需求人力(FTE) | 缺口数量(FTE) | 缺口率 |
|---|---|---|---|---|---|---|
| 合计 |
表3 缺口明细
| 序号 | 角色/技能组 | 缺口数量(FTE) | 涉及项目/需求 | 缺口出现时间 | 持续时长 | 缺口类型 |
|---|---|---|---|---|---|---|
表4 影响评估
| 序号 | 对应缺口 | 影响对象 | 影响描述 | 影响等级 | 判断依据 |
|---|---|---|---|---|---|
表5 应对建议与责任人
| 序号 | 对应缺口 | 应对方式 | 具体动作 | 责任人 | 计划完成时间 | 复核时间 | 状态 |
|---|---|---|---|---|---|---|---|
字段说明:每个字段填什么、怎么算
同一份报告由不同人填写时,差异通常出在统计周期、角色划分和工时口径上。下表逐字段说明含义、取数来源和计算方式,填写前先统一这几项口径。
| 字段 | 含义 | 取数来源 | 计算方式/填写规则 |
|---|---|---|---|
| 统计周期 | 报告覆盖的时间范围 | 团队规划周期 | 写明起止日期,如“2025年第三季度”;一个报告只用一个周期 |
| 角色口径说明 | 角色如何划分 | 团队组织与技能分工 | 写明按职能(后端、前端、测试)还是按技能组划分,并列出包含的岗位 |
| 在岗人数 | 周期内可投入该角色的实际人数 | 人员名册 | 按周期内平均在岗人数统计,含兼职折算,不含长期空缺岗位 |
| 人均可用工时 | 每人周期内可投入目标工作的工时 | 工作日历、假期安排 | 周期工作日×每日标准工时,扣除法定假期、培训与已批准休假 |
| 可用人力(FTE) | 该角色实际可投入的等效全职人力 | 在岗人数、人均可用工时 | 在岗人数×人均可用工时÷周期标准工时;按人天统计时直接用总可用人天 |
| 需求人力(FTE) | 完成周期内已承诺工作所需的人力 | 项目计划、需求估算 | 各项目该角色预估工作量之和÷周期标准工时 |
| 缺口数量(FTE) | 供需差额 | 表2前两列结果 | 需求人力−可用人力;结果为负表示富余,正数表示缺口 |
| 缺口率 | 缺口相对需求的占比 | 缺口数量、需求人力 | 缺口数量÷需求人力×100%;需求人力为0时不计算,标注“无需求” |
| 缺口类型 | 缺口的性质 | 缺口明细分析 | 取值:短期峰值、持续性短缺、技能型短缺、阶段性富余 |
| 影响等级 | 缺口对交付的影响程度 | 影响评估 | 取值:高(影响关键里程碑或对外承诺)、中(影响部分需求排期)、低(可通过内部调节消化) |
| 应对方式 | 处理缺口的策略 | 应对建议 | 取值:内部调配、加班消化、外部招聘、外包协作、范围调整、接受并监控 |
| 复核时间 | 下次检查该应对动作的时间 | 责任人约定 | 填写具体日期,通常不晚于下一个统计周期结束 |
缺口率的分母使用需求人力,便于横向比较不同规模角色的紧张程度。若团队习惯以人天为单位,表2中可用人力与需求人力统一换算为人天,缺口率算法不变。所有数值保留一位小数,并在基本信息表中注明单位。
必填与选填:哪些字段缺失会导致报告不可用
必填字段决定报告能否支撑决策。缺少统计周期、角色口径或供需数据,缺口结论就无法复核;影响等级和应对责任人缺失,报告只能说明问题,无法推动处理。选填字段用于补充背景,可按报告用途取舍。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 统计周期 | 必填 | 没有周期,供需数据无法比较,也无法确定更新节奏 |
| 角色口径说明 | 必填 | 角色划分不同,缺口结果不可比 |
| 工时单位 | 必填 | FTE与人天混用会导致计算错误 |
| 在岗人数、人均可用工时 | 必填 | 可用人力的计算基础 |
| 可用人力、需求人力、缺口数量、缺口率 | 必填 | 报告的核心结论 |
| 影响等级 | 必填 | 决定应对优先级 |
| 应对方式、责任人、复核时间 | 必填 | 缺口需要落到具体动作和跟进人 |
| 覆盖团队/项目 | 选填 | 单团队报告可省略;跨团队汇总时建议填写 |
| 缺口出现时间、持续时长 | 选填 | 短期峰值类缺口建议填写,用于判断是否需要临时调配 |
| 涉及项目/需求 | 选填 | 缺口与具体项目挂钩时填写,便于追溯 |
| 判断依据 | 选填 | 影响等级存在争议时补充说明 |
| 版本号、编制人、复核人 | 选填 | 需要归档或跨期对比时填写 |
字段暂时无法取得时,在单元格标注“待补”并写明补录责任人和补录时间,不用0或空白代替,避免被误读为真实数据。影响等级无法判断时先标“待评估”,在复核时间前完成定级。报告提交前由复核人检查必填字段是否齐全。
填写示例:一个季度缺口报告的完整样例
以下为演示情景,数值仅用于说明字段之间的联动关系,不代表真实团队数据。
示例背景:某研发团队按季度编制缺口报告,统计周期为2025年第三季度,覆盖两个产品项目,角色按后端、前端、测试三个职能划分,工时单位采用FTE,季度标准工时为520小时。
| 角色 | 在岗人数 | 人均可用工时 | 可用人力(FTE) | 需求人力(FTE) | 缺口数量(FTE) | 缺口率 |
|---|---|---|---|---|---|---|
| 后端 | 8 | 480 | 7.4 | 9.0 | 1.6 | 17.8% |
| 前端 | 5 | 480 | 4.6 | 4.5 | −0.1 | −2.2% |
| 测试 | 3 | 480 | 2.8 | 4.0 | 1.2 | 30.0% |
| 合计 | 16 | — | 14.8 | 17.5 | 2.7 | 15.4% |
缺口明细中,后端缺口1.6 FTE集中在项目A的接口改造阶段,属于持续性短缺;测试缺口1.2 FTE出现在项目B上线前的两周,属于短期峰值;前端−0.1 FTE为阶段性富余,可通过支援测试环节消化。
| 对应缺口 | 影响对象 | 影响描述 | 影响等级 | 应对方式 | 责任人 | 复核时间 |
|---|---|---|---|---|---|---|
| 后端1.6 FTE | 项目A里程碑 | 接口改造延期将影响联调开始时间 | 高 | 内部调配+外部招聘 | 研发负责人 | 2025-09-15 |
| 测试1.2 FTE | 项目B上线 | 回归测试覆盖不足,上线风险上升 | 中 | 前端富余人力支援+加班消化 | 测试负责人 | 2025-09-05 |
| 前端−0.1 FTE | 测试环节 | 可短期支援测试用例执行 | 低 | 内部调配 | 前端负责人 | 2025-08-25 |
这份样例展示了字段联动:供需测算得出缺口数量和缺口率,缺口明细说明缺口出现的时间和性质,影响评估据此定级,应对建议再按等级配置动作和复核时间。高等级缺口优先安排招聘和调配,低等级富余直接用于补位。
当报告需要按月滚动时,工时与投入数据可以从ONES Resource的资源报表和工时日志中导出,减少手工汇总;成员每日投入饱和明细也能帮助判断缺口是短期峰值还是持续短缺。
调整与维护方法:按团队规模改表、按周期更新
模板需要随团队规模和规划节奏调整。调整的原则是保持缺口口径一致,让不同周期的报告可以对比。
按角色粒度与团队规模裁剪
- 10人以下团队:角色合并为“研发”“测试”两行,缺口明细只保留序号、缺口数量、涉及项目、缺口类型四列。
- 10至50人团队:按职能划分角色,保留完整五张表,影响评估可简化为等级加一句话说明。
- 50人以上或多项目并行:在角色下增加技能组维度,缺口明细增加“缺口出现时间”和“持续时长”,便于区分峰值与结构性短缺。
- 跨团队汇总时,各团队使用相同的角色口径和工时单位,汇总表只保留供需测算与应对建议两张表。
统计周期切换与历史数据留存
季度报告切换为月度报告时,缩短统计周期并同步调整人均可用工时,缺口率算法保持不变。每期报告单独存档,文件名包含周期和版本号,例如“资源缺口报告_2025Q3_v1.0”。历史报告保留原始数值,修订时新增版本,不覆盖旧版本,便于对比缺口变化趋势。
模板版本与字段变更记录
| 版本号 | 变更日期 | 变更内容 | 变更人 | 影响范围 |
|---|---|---|---|---|
新增或删除字段时,在变更记录中写明原因和影响的历史报告范围。字段口径发生变化时,在新版本中注明“与旧版不可直接对比”,避免跨期误读。模板本身建议每半年检查一次,确认角色划分和工时口径仍与团队实际一致。
常见问题
缺口率算出来是负数,报告里应该怎么处理?
负数表示该角色在统计周期内可用人力大于需求人力,属于富余。填写时保留负号,并在缺口明细中把缺口类型标为“阶段性富余”,在应对建议中写明富余人力可以支援的角色或环节。若团队不习惯负数表述,也可以在备注中写“富余0.1 FTE”,但供需测算表的数值口径应保持一致,避免同一份报告混用两种表达。
统计周期内有人中途入职或离职,在岗人数怎么填?
按周期内平均在岗人数统计,把入职和离职月份折算进去,例如某角色季度内前两个月5人、第三个月6人,平均在岗人数约为5.3人。折算后的人均可用工时也要相应调整,避免用满周期工时乘以平均人数导致可用人力虚高。折算规则应写入角色口径说明,跨期对比时沿用同一规则。
影响等级评不出来,可以先空着提交吗?
影响等级是必填字段,决定应对动作的优先级,不建议空着提交。暂时无法定级时,在单元格标注“待评估”,写明定级责任人和完成时间,并在复核时间前补上。若缺口涉及关键里程碑或对外承诺,可以先按“高”处理并安排应对动作,待评估后再调整,避免因等待定级延误处理。
报告里的工时和投入数据从哪里取比较可靠?
工时与投入数据优先取自团队日常使用的项目管理或工时记录工具,保持与项目计划同源。使用ONES的团队可以从资源报表和工时日志中导出数据,成员每日投入饱和明细也能辅助判断缺口属于短期峰值还是持续短缺。无论使用哪种工具,取数后应在基本信息表注明数据来源和导出日期,便于复核人追溯。
团队从季度报告改为月度报告,历史数据还能对比吗?
可以对比,但需要先统一口径。月度报告的统计周期缩短,人均可用工时随之调整,缺口率算法保持不变;对比时使用缺口率而非缺口绝对数量,减少周期长度带来的差异。历史季度报告保留原始数值,月度报告单独存档,并在版本记录中注明周期变更时间,跨周期对比时说明口径差异。



