研发资源缺口分析报告模板用于把“人手够不够”从口头判断变成可核对的数据表。模板以缺口口径、影响判断、应对建议三部分为主线，适用于按周、按月或按立项节点统计的研发团队。下文给出四张可直接复制的空白表、逐字段填写口径、必填与选填范围，并用一个完整周期示例演示计算过程。统计范围建议限定为同一部门或同一项目集，工时单位在报告内统一为人天或人时。
要点总览（TL;DR）
- 模板由四张表组成：报告基本信息、资源供需明细、影响判断、应对建议，按“先立口径、再算缺口、后判影响、最后给动作”的顺序填写。
- 缺口工时＝需求工时－可用工时，缺口率＝缺口工时÷需求工时；需求工时为0的行不计算缺口率，填“—”。
- 缺口类型分为数量缺口、技能缺口、时段缺口；影响程度按高、中、低分级，分级标准需写在报告内并跨周期沿用。
- 必填字段包括报告周期、统计范围、工时单位、供需明细各列、缺口类型、影响程度与判断依据、应对方式与责任人；覆盖缺口工时与验证方式在月度复盘和立项评审中建议填写。
- 模板调整需记录版本并评审，历史报告保留原版本口径，不随新版本回溯修改。
可复制空白模板：研发资源缺口分析报告表
模板由四张表组成，按“先立口径、再算缺口、后判影响、最后给动作”的顺序填写。复制到文档或表格工具后，保留表头即可开始填写。
表一：报告基本信息
| 字段 | 填写内容 |
|---|---|
| 报告名称 | |
| 报告周期 | 起止日期，例如 2025-03-01 至 2025-03-31 |
| 统计范围 | 部门/项目集/项目清单 |
| 工时单位 | 人天 或 人时（全表统一） |
| 编制人 | |
| 评审人 | |
| 编制日期 | |
| 版本号 |
表二：资源供需明细
| 序号 | 角色/技能 | 需求工时 | 可用工时 | 缺口工时 | 缺口率 | 缺口类型 | 备注 |
|---|---|---|---|---|---|---|---|
| 1 | 数量/技能/时段 | ||||||
| 2 | |||||||
| 3 | |||||||
| 合计 | — | — | — |
表三：影响判断
| 序号 | 受影响项目或交付节点 | 对应缺口行 | 影响程度 | 是否在关键路径 | 判断依据 |
|---|---|---|---|---|---|
| 1 | 高/中/低 | 是/否 | |||
| 2 |
表四：应对建议
| 序号 | 应对方式 | 对应缺口行 | 覆盖缺口工时 | 责任人 | 完成时点 | 验证方式 |
|---|---|---|---|---|---|---|
| 1 | 补充/调配/外协/范围取舍 | |||||
| 2 |
字段说明：每个字段填什么、怎么算
同一份报告内，字段口径必须一致，否则缺口数字无法跨角色、跨周期比较。下表给出各字段的含义、计算方式与填写要点。
| 字段 | 含义与计算口径 | 填写要点 |
|---|---|---|
| 需求工时 | 统计范围内已承诺或已排期工作所需的工时总量 | 按角色/技能归集；注明是否包含会议、支持、缺陷修复等非交付工作，并在基本信息区声明 |
| 可用工时 | 同一周期内该角色可投入的工时总量 | 按人数×可投入天数×每日工时估算，扣除休假、培训等已知占用；口径与需求工时保持一致 |
| 缺口工时 | 需求工时 − 可用工时 | 结果为负表示富余，填负数并在备注说明；不要直接置零，否则合计失真 |
| 缺口率 | 缺口工时 ÷ 需求工时 | 保留百分比一位小数；需求工时为 0 的行不计算缺口率，填“—” |
| 缺口类型 | 数量缺口：总量不足；技能缺口：特定角色或技能无人可补；时段缺口：缺口集中在某几个迭代或交付节点 | 一行可标注多个类型，用顿号分隔；技能缺口需在备注写明具体技能 |
| 影响程度 | 高：导致交付节点延期或质量风险；中：需要调整排期但节点可保；低：可由现有人员消化 | 分级标准写在报告内，跨周期沿用同一标准 |
| 是否在关键路径 | 该缺口是否落在项目关键路径上 | 依据项目计划判断，关键路径上的高影响缺口优先进入应对建议 |
| 判断依据 | 支撑影响程度判断的事实 | 写具体依据，如“该角色为联调前置条件，缺口 12 人天将推迟提测一周” |
| 应对方式 | 补充人力、内部调配、外协、范围取舍 | 一条建议对应一种方式，避免一条写多个方向 |
| 覆盖缺口工时 | 该建议预计消化的缺口工时 | 与表二缺口行对应；多条建议覆盖同一缺口时，合计不超过该行缺口工时 |
| 验证方式 | 判断建议是否生效的检查动作 | 写可核验的动作，如“下周期供需明细中该角色缺口率降至 5% 以内” |
必填与选填：哪些字段不能空
报告能否成立，取决于最小字段集是否完整。缺口工时、缺口率、影响程度、应对方式与责任人缺失时，报告只能描述现象，无法支撑决策。
| 字段 | 填写要求 | 缺失后果 |
|---|---|---|
| 报告周期、统计范围、工时单位 | 必填 | 数字无法复现，跨报告不可比 |
| 角色/技能、需求工时、可用工时、缺口工时、缺口率 | 必填 | 缺口无法量化，影响判断失去依据 |
| 缺口类型 | 必填 | 无法区分是缺人、缺技能还是缺时间，应对方向容易选错 |
| 影响程度、判断依据 | 必填 | 无法排优先级，评审时难以形成结论 |
| 应对方式、责任人、完成时点 | 必填 | 建议停留在方向层面，无人跟进 |
| 编制人、评审人、版本号 | 必填 | 报告无法追溯，版本变更无记录 |
| 备注、是否在关键路径 | 选填 | 关键路径标记缺失时，影响排序依据变弱 |
| 覆盖缺口工时、验证方式 | 选填，月度复盘与立项评审建议填写 | 无法核对建议是否足以补齐缺口 |
按用途调整必填范围：周报可只填基本信息、供需明细与影响判断，应对建议写责任人即可；月度复盘需完整填写四张表，并补充覆盖缺口工时与验证方式；立项评审需在基本信息区补充需求假设与数据来源说明，影响判断需写明对里程碑的量化影响。
填写示例：一个完整周期的缺口报告
以下为演示情景，用于说明填写方式，数字为示例设定。背景：某研发团队统计 2025 年 3 月整月，范围为一个项目集下的两个项目，工时单位为人天，需求与可用工时均包含会议与支持工作。
基本信息与供需明细
| 角色/技能 | 需求工时 | 可用工时 | 缺口工时 | 缺口率 | 缺口类型 |
|---|---|---|---|---|---|
| 后端开发 | 220 | 180 | 40 | 18.2% | 数量缺口 |
| 测试工程师 | 120 | 100 | 20 | 16.7% | 时段缺口 |
| 前端开发（可视化方向） | 60 | 30 | 30 | 50.0% | 技能缺口 |
| 合计 | 400 | 310 | 90 | 22.5% | — |
计算过程：后端缺口 220−180=40 人天，缺口率 40÷220≈18.2%；测试缺口 120−100=20 人天，缺口率 20÷120≈16.7%；前端可视化缺口 60−30=30 人天，缺口率 30÷60=50.0%。合计缺口 90 人天，合计缺口率 90÷400=22.5%。测试缺口集中在 3 月最后两周的回归阶段，因此标为时段缺口；前端可视化方向现有人员不具备该技能，标为技能缺口。
影响判断与应对建议
| 受影响节点 | 对应缺口行 | 影响程度 | 关键路径 | 判断依据 |
|---|---|---|---|---|
| 3 月 28 日提测 | 后端开发 | 高 | 是 | 后端接口为联调前置条件，缺口 40 人天将推迟提测约一周 |
| 3 月 31 日回归完成 | 测试工程师 | 中 | 是 | 缺口集中在最后两周，可通过提前介入缓解 |
| 4 月 10 日可视化模块上线 | 前端可视化 | 高 | 否 | 团队内无人具备该技能，外部补充需要提前启动 |
| 应对方式 | 对应缺口行 | 覆盖缺口工时 | 责任人 | 完成时点 | 验证方式 |
|---|---|---|---|---|---|
| 内部调配 | 后端开发 | 25 人天 | 研发经理 | 3 月 10 日 | 下周期供需明细中后端缺口率降至 10% 以内 |
| 外协 | 前端可视化 | 30 人天 | 项目负责人 | 3 月 15 日 | 可视化模块按计划进入联调 |
| 范围取舍 | 后端开发 | 15 人天 | 产品负责人 | 3 月 12 日 | 需求清单中低优先级项移出本周期 |
| 补充人力 | 测试工程师 | 20 人天 | 测试负责人 | 3 月 20 日 | 回归阶段每日执行用例数达到计划值 |
示例中三条建议覆盖后端缺口 40 人天，与表二缺口行一致；每条建议都有责任人和可核验的验证方式，下一周期报告可直接对照检查是否生效。
调整与维护方法：让模板跟着团队变化
模板需要随组织与节奏调整，但调整应有记录、有评审，避免同一团队不同周期的报告口径漂移。
角色与技能维度的增删规则
以团队实际岗位和项目所需技能为准设置行。新增角色时，先确认该角色在需求工时与可用工时两侧都有数据来源；合并行时，保留原行的历史数据对应关系，在版本记录中注明合并原因。技能缺口涉及的具体技能写在备注列，不单独拆成大量细行，避免表格难以维护。
统计周期与取数时点
统计周期与工时登记节奏对齐：按周统计时，取数时点设在每周固定日期之后，确保当周工时已登记；按月统计时，在月末最后一个工作日之后取数。需求工时以已排期工作为准，可用工时以人员可投入计划为准，两者取数时点保持一致。
版本记录与变更评审
| 维护动作 | 触发条件 | 记录内容 |
|---|---|---|
| 字段增删 | 团队角色体系或统计口径变化 | 变更字段、原因、生效周期 |
| 分级标准调整 | 影响程度分级不再适用 | 新旧标准对照、历史报告是否回溯 |
| 周期调整 | 团队节奏由月改为双周等 | 生效日期、过渡期处理方式 |
变更由编制人提出、评审人确认，版本号在基本信息区递增。历史报告保留原版本口径，不随新版本回溯修改，保证跨周期比较时有据可查。
与资源分配、排期环节的衔接边界
本模板输出的是缺口结论与应对方向，具体人员排期与任务分派在资源分配与排期环节完成；多个项目之间的承接取舍在项目组合资源容量规划中处理。模板中的应对建议可作为这两个环节的输入，验证结果再回流到下一周期报告。
缺口数据来自工时与资源记录，取数口径是否稳定直接影响报告可信度。ONES 资源管理提供资源规划视图，可按业务优先级安排团队资源，并通过工作数量与工时规模查看成员排期、筛选分组掌握成员在不同项目的投入比重；成员每日投入饱和明细可用于识别规划风险，资源利用率与负荷度可辅助核对可用工时口径。将工时登记与资源视图作为取数来源，再按本模板归集到角色与技能行，可以减少手工汇总的偏差。
常见问题
统计范围跨多个部门时，需求工时和可用工时怎么归集？
建议按“部门—角色/技能”两级归集，先分别统计各部门的供需数据，再在合计行汇总。跨部门共享的角色（如测试、运维）需在备注中注明分摊依据，避免同一批工时在多个部门重复计入。若统计范围包含外部协作人员，需在基本信息区声明其工时是否计入可用工时，并保持各周期口径一致。
缺口工时为负数（富余）时，报告还需要写应对建议吗？
需要。富余行同样要进入影响判断，说明该角色在后续周期是否可承接新增需求或支援其他缺口行。应对建议可写“内部调配输出”，并填写预计输出工时、接收方与完成时点。若富余为短期现象（如某迭代结束后释放），在备注中注明时段，避免下一周期误判为持续富余。
周报和月度复盘使用同一模板时，如何避免数据对不上？
关键是取数时点一致。周报在每周固定日期之后取数，月度复盘在月末最后一个工作日之后取数，两者都以已登记的工时和已排期工作为准。周报中未填写的覆盖缺口工时与验证方式，在月度复盘时补齐，并对照周报中的应对建议逐条检查是否生效。若周报与月度复盘的口径发生调整，需在版本记录中注明生效周期。
影响程度分级标准各团队不一样，评审时怎么统一？
分级标准由评审人确认后写入报告基本信息区或附注，至少明确“高”对应的后果类型（如交付节点延期、质量风险）和判断依据的写法。跨团队评审时，以发起评审的团队标准为准，其他团队在报告中注明差异。标准调整时保留新旧对照，历史报告不回溯修改，保证跨周期比较有据可查。
缺口数据从工时和资源记录中汇总时，怎样减少手工偏差？
先固定取数口径：需求工时以已排期工作为准，可用工时以人员可投入计划为准，两者取数时点一致。ONES 资源管理提供资源规划视图，可按业务优先级安排团队资源，并通过工作数量与工时规模查看成员排期、筛选分组掌握成员在不同项目的投入比重；成员每日投入饱和明细可用于识别规划风险，资源利用率与负荷度可辅助核对可用工时口径。将上述视图作为取数来源，再按模板归集到角色与技能行，可减少手工汇总的偏差。
