研发资源缺口分析报告的核心是一张供需对照表：按角色或技能列出可用人力、需求人力、缺口数量与缺口工时，再补充缺口时间窗、影响判断、应对建议和责任人。围绕这张表，报告通常包含报告范围与口径、供需汇总、分角色缺口明细、影响评估、应对措施与优先级、结论与跟踪计划六个部分。下面给出一套可直接复制的空白模板、逐字段口径说明、必填选填规则和一份完整填写示例，便于团队按自身情况调整后长期使用。
要点总览（TL;DR）
- 报告核心是一张供需对照表：按角色或技能列出可用人力、需求人力、缺口数量与缺口工时，再补缺口时间窗、影响判断、应对建议和责任人。
- 报告建议包含六部分：报告范围与口径、供需汇总、分角色缺口明细、影响评估、应对措施与优先级、结论与跟踪计划。
- 口径统一是报告可比的前提：单位在人天、人时或FTE中选一种，注明是否扣除休假与支持性工作，缺口数量与缺口工时绑定同一统计周期。
- 必填字段决定报告能否成立：统计周期、角色/技能、可用人力、需求人力、缺口数量、缺口工时、缺口时间窗，以及受影响交付物与影响程度。
- 模板可按角色或技能粒度、迭代或月度周期调整，每期保留版本号并回顾上期应对落实情况，形成闭环。
可复制空白模板：研发资源缺口分析报告表
模板由四张表组成：报告基本信息、供需汇总、分角色缺口明细、影响评估与应对。填写顺序建议先定统计周期和口径，再填供需汇总，最后展开明细与应对，保证汇总数字与明细能对上。
表一：报告基本信息
| 字段 | 填写内容 |
|---|---|
| 报告名称 | |
| 统计周期 | |
| 编制人 | |
| 审核人 | |
| 版本 | |
| 数据来源 | |
| 编制日期 |
表二：供需汇总
| 角色/技能 | 可用人力 | 需求人力 | 缺口数量 | 缺口工时 | 缺口时间窗 |
|---|---|---|---|---|---|
| 合计 | — |
表三：分角色缺口明细
| 项目或需求 | 角色 | 需求工时 | 已分配工时 | 缺口工时 | 缺口起止时间 |
|---|---|---|---|---|---|
表四：影响评估与应对
| 受影响交付物 | 影响程度 | 应对措施 | 责任人 | 完成时间 |
|---|---|---|---|---|
字段说明：每个字段填什么、怎么算
同一份报告在不同角色手里填写，结果能否比较，取决于口径是否统一。下表逐字段说明含义、计算方式和取数来源，填写前应先确认单位与扣除项。
| 字段名 | 含义 | 计算口径 | 取数来源 | 示例值 |
|---|---|---|---|---|
| 统计周期 | 报告覆盖的时间范围 | 按迭代、月度或季度划定，全表统一 | 项目计划或部门日历 | 2025年3月 |
| 可用人力 | 周期内可投入目标工作的实际人力 | 在岗人数×周期工作日×每日有效工时，扣除休假、培训与支持性工作后折算；单位统一为人天、人时或FTE | 人员名册、考勤与排期记录 | 6人天 |
| 需求人力 | 周期内已承诺或已排期工作所需人力 | 各项目需求工时按角色汇总后折算为同一单位 | 需求清单、项目计划中的估算工时 | 9人天 |
| 缺口数量 | 人力层面的差额 | 需求人力−可用人力，正值为缺口，负值为富余 | 由前两列计算 | 3人天 |
| 缺口工时 | 缺口折算成工时后的规模 | 缺口数量×单位换算系数，或直接以明细表缺口工时汇总 | 明细表汇总 | 24人时 |
| 缺口时间窗 | 缺口集中出现的时间段 | 按月、按迭代或按里程碑划分，标注起止 | 项目里程碑计划 | 3月10日—3月28日 |
| 需求工时 | 单个项目或需求在某角色上的工作量 | 按估算方法得出，注明估算依据 | 需求评审记录 | 40人时 |
| 已分配工时 | 已明确分配到该项目的人力 | 排期表中已占用工时之和 | 排期表 | 16人时 |
| 影响程度 | 缺口对交付的后果等级 | 按是否影响里程碑、是否影响对外承诺、是否有替代方案分级，建议分高、中、低三档并写明判定依据 | 项目负责人判断 | 中 |
| 数据来源 | 关键数字的出处 | 写明系统、报表或文档名称及导出日期 | — | 排期表2025-03-01导出 |
口径上有三点需要提前约定：一是单位统一，人天、人时与FTE不能混用；二是可用人力是否扣除休假和支持性工作，需在报告基本信息中注明；三是缺口数量与缺口工时必须绑定同一统计周期，跨周期比较时注明周期差异。
必填与选填：哪些字段决定报告能否成立
报告能否成立，取决于读者能否从表中读出“哪个角色、在什么时间、缺多少、影响什么”。满足这四点的字段为必填，其余按用途补充。
| 字段 | 必填/选填 | 缺失后果或适用场景 |
|---|---|---|
| 统计周期、角色/技能、可用人力、需求人力、缺口数量、缺口工时、缺口时间窗 | 必填 | 缺失任一字段，缺口结论无法定位到角色和时间，报告失去决策价值 |
| 报告名称、编制人、版本、数据来源 | 必填 | 缺失则无法追溯数据出处，历史对比失效 |
| 受影响交付物、影响程度 | 必填 | 缺失则无法判断缺口是否需要立即处理 |
| 应对措施、责任人、完成时间 | 必填（专项评估与立项前评估） | 月度例行报告可先给措施方向，责任人与时间在下期补齐 |
| 审核人 | 选填 | 需要跨部门确认口径时填写 |
| 缺口起止时间（明细级） | 选填 | 缺口跨多个里程碑时建议填写，便于排期协调 |
| 估算依据 | 选填 | 需求工时争议较大时补充，说明估算方法 |
不同用途的取舍：月度例行报告以供需汇总和趋势为主，明细可只列缺口项；专项评估需要完整明细与影响分级；立项前评估应补齐应对措施、责任人与完成时间，作为资源申请依据。字段暂时无法取得时，填“待补”并注明预计补齐时间，避免留空被误读为零。
填写示例：一份完整的研发资源缺口分析报告
以下为演示情景，数据仅用于说明填写方式，不代表任何真实团队。背景：某研发团队统计2025年3月资源情况，周期内可用人力按扣除休假后折算。
基本信息与供需汇总
| 角色/技能 | 可用人力 | 需求人力 | 缺口数量 | 缺口工时 | 缺口时间窗 |
|---|---|---|---|---|---|
| 后端开发 | 6人天 | 9人天 | 3人天 | 24人时 | 3月10日—3月28日 |
| 测试 | 4人天 | 4人天 | 0 | 0 | — |
| 前端开发 | 5人天 | 4人天 | −1人天 | −8人时 | — |
缺口明细
| 项目或需求 | 角色 | 需求工时 | 已分配工时 | 缺口工时 | 缺口起止时间 |
|---|---|---|---|---|---|
| 订单模块重构 | 后端开发 | 40人时 | 16人时 | 24人时 | 3月10日—3月28日 |
| 报表导出优化 | 前端开发 | 16人时 | 24人时 | −8人时 | — |
影响评估与应对
| 受影响交付物 | 影响程度 | 应对措施 | 责任人 | 完成时间 |
|---|---|---|---|---|
| 订单模块重构里程碑 | 高：影响对外承诺的上线时间 | 前端富余人力支援后端接口联调；同步评估范围裁剪 | 张工 | 3月12日 |
| 报表导出优化 | 低：可顺延一个迭代 | 保持现有排期，观察下期缺口 | 李工 | 3月31日 |
关键数字来源：可用人力来自3月1日导出的排期表，已扣除2人天休假；需求工时来自需求评审记录中的估算值；缺口工时为需求工时减已分配工时。影响程度按是否影响对外承诺判定，订单模块涉及客户上线时间，定为高。
当这类数据分散在排期表、需求清单和工时记录中时，汇总口径容易不一致。ONES 资源管理提供资源规划视图，可按业务优先级安排团队资源；通过工作数量和工时规模查看成员排期，并支持筛选与分组，掌握成员在不同项目的投入比重；资源报表可实时反馈项目投入情况并支持导出工时日志。把排期与工时数据沉淀在同一套工作项体系中，缺口表的取数来源更清晰，也便于下期对比。
调整与维护：让模板适配团队并持续可用
模板需要随团队规模和研发模式调整，调整的原则是保持汇总与明细可对账、周期口径可比较。
- 粒度调整：团队人数较少时按角色汇总即可；跨职能协作多、技能差异大的团队，可在角色下增加技能维度，明细表相应增加一行，汇总表按技能小计。
- 周期调整：迭代制团队按迭代统计，缺口时间窗与迭代起止对齐；项目制团队按月度或里程碑统计，季度报告可在月度数据上汇总，并注明汇总方式。
- 字段增删：新增字段需能对应到已有取数来源，否则先以“待补”标注；删除字段前确认不影响缺口数量与缺口工时的计算链条。
- 版本管理：每期报告保留版本号与编制日期，历史报告归档在同一目录，便于按角色对比缺口变化趋势。
- 衔接边界：本报告输出缺口事实与应对建议，项目组合层面的承接取舍、具体人员排期由相应决策流程处理，报告只提供输入。
维护上建议固定每期编制人和审核人，统计周期结束后三个工作日内完成初稿，并在下期报告开头回顾上期应对措施的落实情况，形成闭环。
常见问题
统计周期内可用人力要不要扣除休假、培训和临时支持工作？
建议扣除，并在报告基本信息中写明扣除范围。可用人力反映的是周期内真正能投入目标工作的人力，若按在岗人数直接计算，缺口会被低估。常见做法是：在岗人数乘以周期工作日和每日有效工时，再减去休假、培训、面试、线上支持等非目标工作占用。扣除项一旦确定，同一团队各期报告保持一致，跨期比较才有意义。
缺口数量为负值时，报告里应该怎么处理？
负值表示该角色在统计周期内存在富余，属于有效信息，不应直接删掉或记为零。建议在供需汇总表中保留负值，并在影响评估与应对表中说明富余人力是否可以支援其他缺口角色。若富余来自需求尚未排满，需注明是暂时性富余还是结构性富余，避免下期误判为可长期调配的资源。
影响程度分级有没有可操作的判定标准？
建议用可观察的条件代替主观打分，例如按三条判定：是否影响对外承诺的上线时间、是否影响关键里程碑、是否存在可替代方案。三条中命中对外承诺的定为高，仅影响内部里程碑且有替代方案的定为中，可顺延一个迭代且无外部影响的定为低。分级标准写在报告口径部分，各期沿用同一套标准，便于对比。
月度例行报告和立项前评估，字段取舍有什么不同？
月度例行报告以供需汇总和趋势为主，明细可只列存在缺口的角色，应对措施可先给方向，责任人与完成时间在下期补齐。立项前评估需要完整明细、影响分级，并补齐应对措施、责任人与完成时间，作为资源申请依据。专项评估介于两者之间，重点是完整明细与影响判断。用途不同，必填范围相应调整，但统计周期、角色、可用人力、需求人力、缺口数量、缺口工时、缺口时间窗这组核心字段在任何用途下都应保留。
缺口数据分散在排期表、需求清单和工时记录里，怎么保证取数一致？
关键是让三类数据有共同的统计周期和角色口径。可以在报告基本信息中固定数据来源及导出日期，明细表的已分配工时直接取自排期记录，需求工时取自需求评审后的估算值，缺口工时由两者相减得出，汇总表再由明细表汇总。数据沉淀在同一套工作项体系中时，取数来源更清晰。ONES 资源管理提供资源规划视图，可按业务优先级安排团队资源；通过工作数量和工时规模查看成员排期，支持筛选与分组掌握成员在不同项目的投入比重；资源报表可实时反馈项目投入情况并支持导出工时日志。
