研发资源需求表把项目或业务方提出的人力需求，转成可核对的角色、人数、投入比例、起止时间和技能要求，再与团队可用工时对比，得出缺口。它通常由项目经理或需求提出人填写需求侧，由团队负责人或资源管理员维护容量侧，填完后用于判断某个周期内人力是否够用、缺口落在哪些角色上。本文提供可直接复制的空白表、字段口径、必填选填划分、完整填写示例和维护方法；需求行与容量核对也可以在ONES的工作项与工时数据中承载，便于后续跟踪。
要点总览（TL;DR）
- 模板由两张表组成：需求行级主表记录角色、人数、投入比例和起止日期，容量核对表按团队或角色汇总可用工时与缺口。
- 角色、人数、投入比例、起止日期、优先级、来源项目为必填字段；技能要求、需求提出人、备注可按团队习惯选填。
- 缺口按角色分别计算：需求工时合计减去可用工时合计，正值表示缺口，负值表示余量，不能只看团队总人数。
- 需求侧随立项或范围变更更新，容量侧按周或双周更新，字段结构变更时保留旧版本并标注生效日期。
- 这张表只做可用人力供需测算，项目组合取舍和具体人员排期在资源规划视图或排期会议中另行处理。
可复制空白模板：研发资源需求表
模板由两张表组成：需求行级主表记录“谁在什么时间需要什么角色投入多少”，容量核对表按团队或角色汇总“实际能提供多少工时”。使用时先填主表，再把主表按角色汇总到容量核对表，两张表通过“角色”和“统计周期”对齐。表头放在表格第一行，填写说明可以放在表格下方或单独一页，保证填写人拿到表就能看懂口径。
表一：研发资源需求表（需求行级）
| 需求编号 | 来源项目/业务方 | 角色 | 技能要求 | 人数 | 投入比例 | 开始日期 | 结束日期 | 优先级 | 需求提出人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
表二：容量核对表（团队/角色级）
| 统计周期 | 团队/角色 | 可用人数 | 名义可用工时 | 请假与培训占用 | 其他项目占用 | 可用工时合计 | 需求工时合计 | 缺口 | 结论与处理 |
|---|---|---|---|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么算
字段口径统一，才能让不同项目提报的需求放在一起比较。需求侧字段回答“要什么、要多少、什么时候要”，容量侧字段回答“能给多少、差多少”。投入比例与工时之间需要一个固定换算公式，否则人数和比例无法直接相加。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 需求编号 | 需求行的唯一标识 | 按“项目缩写-年份-序号”编制，同一周期内不重复 | CRM-2025-003 |
| 来源项目/业务方 | 提出需求的来源 | 写项目名称或业务部门，便于回溯和优先级讨论 | 客户管理平台二期 |
| 角色 | 需要的人力类型 | 使用团队统一的角色名称，如后端开发、前端开发、测试、产品经理 | 后端开发 |
| 技能要求 | 该角色需要具备的具体能力 | 写与任务直接相关的技术栈或经验要求，避免写“能力强”这类无法核对的描述 | 熟悉Java与消息队列 |
| 人数 | 需要投入的人数 | 填整数；同一角色分阶段投入时拆成多行 | 2 |
| 投入比例 | 每人投入该需求的时间占比 | 按0–100%填写，与人数相乘得到等效人力（FTE） | 50% |
| 开始日期 | 需求投入的起始日 | 精确到日，与项目计划保持一致 | 2025-03-03 |
| 结束日期 | 需求投入的截止日 | 精确到日，包含结束当天 | 2025-04-11 |
| 优先级 | 需求相对重要程度 | 用高/中/低或P0/P1/P2统一分级，全表使用同一套 | 高 |
| 需求提出人 | 对该需求负责的人 | 写姓名，便于核对和变更确认 | 张明 |
| 可用人数 | 该角色在周期内可投入的人数 | 按实际在岗人数填写，不含已确定离职或长期外借人员 | 3 |
| 名义可用工时 | 未扣除任何占用前的工时 | 可用人数 × 周期内工作日 × 每日标准工时 | 3人 × 20天 × 8小时 = 480小时 |
| 请假与培训占用 | 已确定的非工作占用 | 按已审批的请假、培训、法定假日折算工时填写 | 40小时 |
| 其他项目占用 | 该角色已被其他项目占用的工时 | 从已确认的项目投入中汇总，避免重复计算 | 120小时 |
| 可用工时合计 | 真正可分配给新需求的工时 | 名义可用工时 − 请假与培训占用 − 其他项目占用 | 480 − 40 − 120 = 320小时 |
| 需求工时合计 | 主表中该角色在周期内的需求工时 | Σ（人数 × 投入比例 × 重叠工作日 × 每日标准工时） | 2人 × 50% × 20天 × 8小时 = 160小时 |
| 缺口 | 需求与可用之间的差额 | 需求工时合计 − 可用工时合计；正值表示缺口，负值表示余量 | 160 − 320 = −160小时（余量） |
投入比例与工时的换算需要固定一个基准：每日标准工时（常见为8小时）和周期内工作日天数。需求行跨越的日期若与统计周期不完全重合，只计算重叠部分的工作日。等效人力（FTE）= 人数 × 投入比例，用于快速判断“这个需求相当于几个全职人力”，再乘以工作日和每日工时得到需求工时。
必填与选填：哪些字段不能空
必填字段决定了这张表能否完成缺口计算和优先级判断。缺少角色、人数、投入比例或起止日期中的任何一项，需求工时都无法算出；缺少来源项目和优先级，缺口出现时无法判断该保哪个需求。选填字段用于补充说明，空缺不影响计算，但会影响沟通效率。
| 字段 | 必填/选填 | 原因或适用场景 |
|---|---|---|
| 需求编号 | 必填 | 用于跨表引用、变更追踪和去重 |
| 来源项目/业务方 | 必填 | 缺口出现时需要回到来源方确认取舍 |
| 角色 | 必填 | 容量核对按角色汇总，缺失则无法归集 |
| 人数 | 必填 | 需求工时的乘数项 |
| 投入比例 | 必填 | 区分全职投入与部分投入，影响工时计算 |
| 开始日期、结束日期 | 必填 | 确定统计周期内的重叠工作日 |
| 优先级 | 必填 | 缺口处理时用于排序，缺失会导致无法取舍 |
| 技能要求 | 选填 | 需求涉及特定技术栈或认证时填写，通用角色可不填 |
| 需求提出人 | 选填 | 建议填写，便于核对；小团队可由项目负责人统一提报 |
| 备注 | 选填 | 记录前置依赖、外部约束等补充信息 |
字段暂时无法确定时，不要留空后直接提交。可以填入暂定值并在备注中标注“待确认”，同时写明确认人和确认时间；对于影响缺口计算的关键字段（人数、投入比例、起止日期），暂定值需要在下一次容量核对前更新。选填字段空缺时保持空白即可，不需要填“无”或“/”，避免统计时产生歧义。
填写示例：一条完整需求与一次容量核对
以下为演示情景，数据仅用于说明填写方法，不代表真实项目或行业基准。假设统计周期为2025年3月3日至3月28日，共20个工作日，每日标准工时8小时。
需求行示例
| 需求编号 | 来源项目/业务方 | 角色 | 技能要求 | 人数 | 投入比例 | 开始日期 | 结束日期 | 优先级 | 需求提出人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| CRM-2025-003 | 客户管理平台二期 | 后端开发 | 熟悉Java与消息队列 | 2 | 50% | 2025-03-03 | 2025-03-28 | 高 | 张明 | 依赖接口联调完成 |
这条需求的含义是：客户管理平台二期需要2名后端开发，每人投入50%的时间，从3月3日到3月28日。等效人力为2 × 50% = 1个全职人力；需求工时 = 1 × 20个工作日 × 8小时 = 160小时。技能要求对应字段说明中的“与任务直接相关的技术栈”，备注记录了前置依赖，便于在缺口讨论时判断能否压缩。
容量核对示例
| 统计周期 | 团队/角色 | 可用人数 | 名义可用工时 | 请假与培训占用 | 其他项目占用 | 可用工时合计 | 需求工时合计 | 缺口 | 结论与处理 |
|---|---|---|---|---|---|---|---|---|---|
| 2025-03-03至2025-03-28 | 后端开发 | 3 | 480小时 | 40小时 | 120小时 | 320小时 | 160小时 | −160小时 | 有余量，可承接 |
| 2025-03-03至2025-03-28 | 测试 | 2 | 320小时 | 16小时 | 240小时 | 64小时 | 120小时 | +56小时 | 存在缺口，需协调或调整范围 |
后端开发一行：3人 × 20天 × 8小时 = 480小时名义工时，扣除请假培训40小时和其他项目占用120小时，可用320小时；需求160小时，缺口为160 − 320 = −160小时，负值表示余量。测试一行：2人 × 20天 × 8小时 = 320小时，扣除16小时和240小时后可用64小时；需求120小时，缺口为120 − 64 = +56小时，正值表示缺口。两个角色结论不同，说明缺口要按角色分别看，不能只看团队总人数。
把这张表放进日常协作时，需求行可以作为工作项录入，人数、投入比例、起止日期对应工作项字段，容量侧则依赖成员工时登记和已排期数据汇总。ONES的资源管理支持通过工作数量和工时规模了解成员排期，支持筛选与分组查看成员在不同项目中的投入比重，也可以实时查看成员每日投入饱和明细，用于识别规划风险；资源和工时管理方案提供资源规划视图，便于按业务优先级安排团队资源，并支持查询和导出工时登记日志明细。这样需求表不再是一次性表格，而是随工时数据更新的核对依据。
调整与维护方法：按团队规模改字段、按周期更新
模板需要随团队规模和项目类型调整，但调整应遵循“先保证缺口可算，再增加管理字段”的原则。小团队可以合并角色、减少审批类字段；多项目并行的团队需要保留来源项目、优先级和其他项目占用，否则缺口会被低估。项目类型差异体现在技能要求和备注上，不必为每类项目单独建表。
- 增删字段原则：角色、人数、投入比例、起止日期、优先级、可用工时合计、缺口这几项保留；技能要求、需求提出人、备注可按团队习惯增删；新增字段若参与计算，需同步更新字段说明和示例。
- 更新频率：需求侧在项目立项或范围变更时更新，容量侧按周或按双周更新；每个统计周期结束前完成一次缺口确认，避免需求已开始执行才发现人力不足。
- 责任人：需求提出人负责需求行的准确性和变更同步，团队负责人或资源管理员负责容量侧数据，项目经理负责在缺口出现时组织确认处理方式。
- 版本与历史记录：每次调整字段结构时保留旧版本，标注生效日期；需求行变更保留变更前后的值和变更原因，容量核对结果按周期存档，便于回溯缺口判断依据。
- 边界提示：这张表用于可用人力供需测算，项目组合层面的承接取舍、优先级排序以及具体人员的排期与任务分配，需要在资源规划视图或排期会议中另行处理，不在这张表的填写范围内。
维护一段时间后，可以用历史数据检查口径是否合理：如果多个周期都出现同一角色缺口，说明容量侧数据需要重新核对或该角色需要补充；如果缺口长期为负而项目仍延期，则要检查其他项目占用是否漏记。模板的价值在于让每次判断有共同依据，字段和口径保持稳定比字段数量更重要。
常见问题
需求提出人填了暂定人数和日期，什么时候必须改成确定值？
影响缺口计算的关键字段，包括人数、投入比例、开始日期和结束日期，暂定值应在下一次容量核对前更新为确定值。如果项目已经进入执行阶段而关键字段仍是暂定值，缺口结论只能作为参考，不能据此做承接承诺。建议在备注中写明确认人和确认时间，容量核对时优先检查标注“待确认”的需求行。
一个需求跨越两个统计周期，需求工时应该怎么拆？
按统计周期拆分需求行，每个周期只计算与该周期重叠的工作日。例如需求从3月20日持续到4月10日，3月周期只算3月20日至3月28日的工作日，4月周期另起一行计算剩余工作日。拆分后需求编号可以加周期后缀，保持可追溯，避免同一需求在两个周期里重复计入。
团队里有人同时参与多个项目，其他项目占用怎么统计才不重复？
其他项目占用应从已确认的项目投入中汇总，按角色和统计周期归集，同一人在同一周期的投入比例合计不超过100%。如果多个项目分别提报同一批人力，需要先合并去重再填入容量核对表。ONES 资源管理支持筛选与分组查看成员在不同项目中的投入比重，可作为核对参考。
缺口算出来是正值，表里应该怎么处理？
缺口为正值时，在“结论与处理”列写明处理方式，常见选项包括调整需求范围、推迟开始日期、由其他角色分担部分工作，或提交到资源规划环节申请补充人力。处理方式需要和需求提出人确认后记录，不能只在表里标一个数字。如果缺口涉及多个项目争抢同一角色，取舍判断应放到项目组合层面处理。
小团队只有几个人，还需要维护两张表吗？
小团队可以合并角色、减少审批类字段，但需求行和容量核对两部分建议保留。人数少的时候可以把容量核对表简化为每人一行，直接看每个人在各项目上的投入比例合计是否超过100%。字段可以精简，缺口计算的口径保持一致，后续团队扩大时不需要重新设计表格。
