研发资源需求表把“哪个项目、哪个角色、需要多少人、从什么时候到什么时候、投入比例多少”记录成可汇总的供需台账。本文提供可直接复制的空白表头、角色×月份汇总表、字段口径说明和一条完整填写示例，并按角色月度对比可用人力，算出缺口或富余。范围限于需求记录与供需汇总，项目组合取舍和具体人员排期另作处理。
要点总览（TL;DR）
- 研发资源需求表用一行记录一条需求，核心字段是需求编号、项目/需求来源、角色、需求人数、起止日期、投入比例、优先级和状态；按角色×月份汇总人天，与可用人力对比即可看出缺口或富余。
- 需求人数、预计人天与投入比例必须口径一致：人天≈需求人数×投入比例×需求窗口内工作日数，跨月需求按月份拆分后再汇总。
- 必填字段是汇总的前提：编号、来源、角色、人数、起止日期、投入比例、优先级、状态缺一不可；技能要求、提出人、确认人、备注可按团队规模选填。
- 表格要持续可用，需固定每周更新、每月锁定存档，明确状态流转与关闭规则，新增字段时追加列并保留历史数据。
- 需求表只回答需要多少人力、什么时候需要；具体人员排期和资源不足时的组合取舍分别由排期与组合决策处理，不塞进同一张表。
可复制空白模板：研发资源需求表
模板由主表和汇总附表两部分组成。主表一行记录一条资源需求，附表按角色和月份汇总人天，用于与可用人力对比。将下面两张表的结构复制到表格工具中，保留表头文字和列顺序，即可开始填写。
主表：研发资源需求明细
| 需求编号 | 项目/需求来源 | 角色 | 技能要求 | 需求人数 | 预计人天 | 开始日期 | 结束日期 | 投入比例 | 优先级 | 状态 | 提出人 | 确认人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REQ-001 | YYYY-MM-DD | YYYY-MM-DD | % | ||||||||||
| REQ-002 | YYYY-MM-DD | YYYY-MM-DD | % | ||||||||||
| REQ-003 | YYYY-MM-DD | YYYY-MM-DD | % |
附表：角色×月份需求人天汇总
| 角色 | 2025-01 | 2025-02 | 2025-03 | 2025-04 | 合计 |
|---|---|---|---|---|---|
| 后端开发 | |||||
| 前端开发 | |||||
| 测试 | |||||
| 产品 | |||||
| 合计 |
填写约定
- 日期统一用“YYYY-MM-DD”，例如 2025-03-01，避免“3月1日”“3/1”混用导致排序和跨月拆分出错。
- 投入比例按 0–100% 填写，表示该角色在需求窗口内平均占用的工时比例；50% 即半个人力投入。
- 需求编号按“REQ-序号”连续编号，不复用已关闭需求的编号，便于追溯。
- 一行只对应一个角色。同一需求需要后端和测试时拆成两行，汇总时才能按角色分别统计。
- 跨月需求在汇总时按月份拆分人天，主表仍保留一条完整记录。
字段说明：每个字段填什么、按什么口径算
字段失真的常见原因是同名不同义，例如有人把“需求人数”填成人数，有人填成人天。下面逐项约定含义和计算方式，团队按同一口径填写，汇总结果才可信。
| 字段 | 填写内容 | 口径与计算 |
|---|---|---|
| 需求编号 | 唯一标识，如 REQ-012 | 按提出顺序编号，关闭后不复用 |
| 项目/需求来源 | 项目名称或需求单号 | 写清来源，便于按项目汇总和追溯优先级依据 |
| 角色 | 后端开发、前端开发、测试、产品等 | 用团队统一的角色字典，不写具体人名 |
| 技能要求 | 如“熟悉支付对账”“能独立做性能测试” | 只写影响人力匹配的关键技能，不写通用素质 |
| 需求人数 | 需要投入的人数，如 2 | 表示并行投入的人力数量，与投入比例配合使用 |
| 预计人天 | 该需求消耗的总人天，如 40 | 人天 ≈ 需求人数 × 投入比例 × 需求窗口内工作日数；也可由任务估算自下而上汇总 |
| 开始日期 | 需求开始投入的日期 | 以实际可开始工作的日期为准，不含等待排期的时间 |
| 结束日期 | 需求计划完成的日期 | 与开始日期共同构成需求窗口，跨月时用于拆分人天 |
| 投入比例 | 0–100% | 该角色在窗口内的平均占用比例；多人投入时按人均比例填写 |
| 优先级 | P0/P1/P2 或 高/中/低 | 取值在团队内固定一套，用于缺口出现时的取舍排序 |
| 状态 | 待确认、已确认、进行中、已完成、已取消 | 状态变化记录在备注或变更日志中 |
| 提出人 | 需求提出者 | 对需求内容和时间窗口负责 |
| 确认人 | 资源负责人或技术负责人 | 确认人力可供给后才将状态改为“已确认” |
| 备注 | 依赖、假设、变更说明 | 记录影响供需判断的关键信息 |
人数、人天与投入比例的关系
需求人数回答“要几个人”，预计人天回答“总共消耗多少工作量”，投入比例回答“每个人被占用多少”。三者需要一致：2 人、投入比例 50%、窗口 20 个工作日，对应人天约为 2×50%×20＝20 人天。若只填人数不填比例，汇总时无法判断这 2 人是全职还是兼职，缺口会被高估或低估。
需求窗口的界定
开始日期到结束日期构成需求窗口。窗口内包含节假日时，按团队工作日历折算工作日数，再乘以人数和比例得到人天。需求窗口跨越两个月时，按各月工作日占比拆分，例如窗口 3 月 15 日至 4 月 15 日，3 月部分计入 3 月，4 月部分计入 4 月，避免整条需求压在单月造成假缺口。
必填与选填：哪些字段不填就无法汇总
必填字段的判断标准是：缺少它，按角色和月份汇总或供需对比就无法完成。其余字段按管理精细度选填，小团队可以先用最小字段集跑起来，再逐步补充。
| 字段 | 级别 | 缺失后果 |
|---|---|---|
| 需求编号 | 必填 | 无法唯一识别需求，变更和关闭记录对不上 |
| 项目/需求来源 | 必填 | 无法按项目汇总，缺口出现时找不到归属 |
| 角色 | 必填 | 无法按角色汇总，供需对比失去维度 |
| 需求人数 | 必填 | 无法计算人天和占用规模 |
| 开始日期、结束日期 | 必填 | 无法拆分到月份，月度缺口算不出来 |
| 投入比例 | 必填 | 人数与实际占用脱节，汇总偏差大 |
| 优先级 | 必填 | 缺口出现时无法排序取舍 |
| 状态 | 必填 | 已取消需求仍计入汇总，虚增需求 |
| 预计人天 | 建议必填 | 可由人数×比例×工作日推算，但自下而上估算更准 |
| 技能要求 | 选填 | 影响人力匹配精度，不影响总量汇总 |
| 提出人、确认人 | 选填 | 影响责任追溯，不影响供需计算 |
| 备注 | 选填 | 用于记录依赖和变更，按需填写 |
按团队规模取舍
- 10 人以内团队：保留必填字段加预计人天，技能要求可并入备注，汇总表按月维护即可。
- 10–50 人团队：补齐技能要求、提出人和确认人，明确“已确认”才计入需求，减少口头需求干扰汇总。
- 50 人以上或多项目并行：增加需求来源单号、变更记录，按项目和角色双维度汇总，并指定专人维护。
填写示例：一条完整需求记录
以下示例演示一条需求从填写到进入汇总的完整过程。示例为演示情景，数值仅用于说明字段对应关系。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-012 |
| 项目/需求来源 | 订单中心改版 / PRD-208 |
| 角色 | 后端开发 |
| 技能要求 | 熟悉订单履约链路，能独立完成接口改造 |
| 需求人数 | 2 |
| 预计人天 | 30 |
| 开始日期 | 2025-03-10 |
| 结束日期 | 2025-04-11 |
| 投入比例 | 75% |
| 优先级 | P1 |
| 状态 | 已确认 |
| 提出人 | 产品经理 A |
| 确认人 | 后端负责人 B |
| 备注 | 依赖支付网关升级，4 月第一周需联调 |
该行在汇总表中的体现
需求窗口 3 月 10 日至 4 月 11 日，按工作日拆分：3 月约 16 个工作日，4 月约 9 个工作日，合计 25 个工作日。按 2 人×75% 计算，每日占用 1.5 人天，3 月约 24 人天，4 月约 13.5 人天，与预计人天 30 存在差异，说明预计人天需要按实际工作日复核。汇总表中该需求分别计入“后端开发”行的 2025-03 和 2025-04 两列，而不是全部压在 3 月。
常见填写错误与修正
- 把“需求人数”填成“人天”：2 人投入两个月被写成 2，汇总后需求被严重低估。修正为人数与人天分列填写。
- 投入比例填 100% 但实际兼职：缺口被放大。按真实占用填写，并在备注说明兼职安排。
- 跨月需求只填开始月份：4 月缺口被隐藏。按月份拆分人天后再汇总。
- 已取消需求未改状态：需求总量虚高。状态改为“已取消”，汇总时排除。
- 同一需求多角色写在一行：无法按角色统计。拆成多行，共用同一需求编号加后缀区分。
调整与维护方法：让需求表持续可用
需求表的价值来自持续更新。一次性填完就搁置的表格，第二个月就会与实际情况脱节。维护的重点是固定更新节奏、明确状态流转、控制字段变更，并与排期和组合决策划清边界。
更新频率与责任人
- 每周更新一次：需求提出人补充新增需求，确认人更新确认结果，资源负责人核对汇总表。
- 每月初锁定上月数据：将上月汇总结果存档，作为容量复盘依据，避免历史数据被反复修改。
- 指定一名表格维护人，负责字段口径解释、编号发放和汇总表生成，减少多人各填一套。
状态流转与关闭规则
状态按“待确认→已确认→进行中→已完成”流转，取消的需求标记“已取消”并写明原因。只有“已确认”“进行中”的需求计入供需汇总，“已完成”保留用于复盘，“已取消”从当期汇总中排除。需求结束日期过后两周仍未关闭的，由维护人提醒确认人核实，防止僵尸需求占用汇总额度。
字段新增与历史数据兼容
新增字段时在表头追加列，历史行留空并在备注注明“字段上线前数据”，不回溯改写旧记录。删除字段前先确认没有汇总公式依赖它。字段口径变化时，在表头下方增加一行口径说明并记录生效日期，保证新旧数据可区分。
与排期、组合决策的边界
需求表回答“需要多少人力、什么时候需要”，排期回答“具体谁在什么时候做”，组合决策回答“资源不够时先做哪个”。三者衔接但不混用：需求表提供按角色和月份的需求人天，排期据此分配具体人员，组合决策依据优先级字段做取舍。把人员姓名和任务拆解直接塞进需求表，会让表格迅速膨胀并失去汇总功能。
从表格落到系统
当需求行数增多、多人同时维护时，可以把需求行对应为系统中的工作项，用资源视图查看成员投入比重和每日饱和度，减少手工汇总的误差。ONES 资源管理通过甘特视图支持项目资源规划与进度跟踪，可按工作数量和工时规模了解成员排期，并通过筛选与分组掌握成员在不同项目的投入比重；其资源报表可实时反馈项目投入情况，并支持导出工时日志。ONES 资源和工时管理解决方案提供资源规划视图，便于按业务优先级安排团队资源，查看项目和团队的资源利用率及负荷度。落地时，需求编号、角色、起止时间和投入比例可作为工作项字段承载，按角色和月份的缺口对比仍需结合团队实际可用人天核验后再用于决策。
常见问题
需求人数填了 2 人，投入比例也填了 50%，还需要再填预计人天吗？
建议填写。预计人天可以由人数、比例和工作日数推算，但推算结果依赖工作日历和窗口界定，遇到节假日、联调等待或需求范围变化时容易偏差。自下而上按任务估算人天，再与推算值对照，差异较大时说明窗口或比例需要复核。示例中 2 人×75%×25 个工作日约 37.5 人天，与填写的 30 人天不一致，就是需要复核的信号。
需求还在讨论阶段、人力尚未确认，应该先录入需求表吗？
可以录入，状态填“待确认”，并在确认人一栏留空或标注待定。汇总时只统计“已确认”和“进行中”的需求，待确认需求单独列出作为潜在需求参考，不计入当期缺口。这样既保留早期信息，又避免未定需求虚增人力压力。确认人核实可供给后，再将状态改为“已确认”。
同一个需求需要后端和测试共同参与，应该写一行还是拆成两行？
拆成两行，共用同一需求编号并加角色后缀区分，例如 REQ-012-BE 和 REQ-012-QA。一行只对应一个角色，汇总表才能按角色分别统计人天。如果写在一行，角色列无法同时承载两个值，按角色汇总时这条需求会丢失或被重复计入。
表格行数变多、多人同时维护后，手工汇总容易出错，有什么改进方式？
可以把需求行对应为系统中的工作项，用资源视图查看成员投入比重和每日饱和度，减少手工汇总。ONES 资源管理支持通过甘特视图进行项目资源规划与进度跟踪，可按工作数量和工时规模了解成员排期，并通过筛选与分组掌握成员在不同项目的投入比重；资源报表可反馈项目投入情况并支持导出工时日志。落地时把需求编号、角色、起止时间和投入比例作为工作项字段承载，按角色和月份的缺口仍需结合团队实际可用人天核验。
需求表需要和项目组合的资源取舍决策打通吗？
需要衔接，但不必合并。需求表提供按角色和月份的需求人天与优先级，组合决策依据这些数据判断资源不足时先做哪个项目。把组合取舍的结论回写到需求表的状态或备注中即可，具体的承接取舍过程在组合资源容量规划中处理，避免需求表承担决策记录职能而变得臃肿。
