研发资源需求表要解决的是需求侧“要多少人、什么角色、什么时间窗”和供给侧“实际能投入多少”在同一张表里对齐。设计前先定计量单位、时间粒度和统计边界，再固定字段与状态取值，配套填报、确认、缺口处置的流程，最后用缺口率和按期满足率检验它是否真的在用。
要点总览（TL;DR）
- 先定口径再画字段：明确计量单位（人天或人月）、时间粒度（按周滚动或月度快照）和供需两侧统计边界，是表能汇总、能比较的前提。
- 字段按需求侧、供给侧、缺口三组组织，用需求编号串联；缺口人天设为公式字段，优先级、确认状态、处置方式使用固定枚举值。
- 流程按填报、供给确认、缺口处置、滚动更新四步推进，顺序不能颠倒；每步都有明确输入和完成标志。
- 需求提出人、资源负责人、项目负责人、资源管理归口人四类角色各管一段，避免表变成单方台账。
- 用缺口率和按期满足率验证表是否在用，检查发现的问题回到模板、口径或流程环节修正。
先定口径：这张表回答哪几个供需问题
动手画字段之前，先用一页纸把这张表的回答范围写清楚。它只解决可用人力在时间窗内的供需对齐：某个事项在某个时间段需要哪些角色、多少工作量，团队实际能提供多少，差多少、怎么补。项目是否承接、事项之间如何取舍，属于项目组合层面的决策；具体派谁做、哪天做什么，属于排期与任务分派。这两类问题不放进这张表，否则表会迅速膨胀成项目台账。
计量单位需要二选一或明确主辅关系。按人天计量适合两周到一个月的时间窗，颗粒度细，便于和滚动节奏对齐；按人月计量适合季度级规划，填报成本低但精度粗。同一张表内保持一种主单位，辅助单位只做换算展示，避免出现“3人月”和“45人天”混填导致无法汇总。
统计维度同样要提前定。按角色汇总（如后端3人、测试2人）适合资源池统一调配的组织；按人明细适合人员相对固定、跨项目借调频繁的团队。多数研发团队可以主表按角色汇总，附表按人展开，两张表用同一需求编号关联。
时间粒度决定更新成本。按周滚动更新适合迭代节奏快、需求变化频繁的团队，每周固定时间刷新未来4到8周的窗口；按月度快照适合版本节奏稳定、以月为规划周期的团队。粒度一旦确定，供需两侧必须一致，不能需求侧按周、供给侧按月，否则缺口计算失去意义。
供需两侧的统计边界要写成明文规则。需求侧的工作量是否包含评审、联调、缺陷修复等非编码工作；供给侧的可用人力是否扣除请假、培训、例会、兼职支持其他项目的时间。常见做法是供给侧按“名义人力×可用系数”折算，例如一名成员一周按5人天名义工时，扣除固定会议与例行支持后按4人天计入可用。系数由团队根据实际情况确定并写入口径说明，不追求行业统一值。
这一页口径说明的完成标志是：任何一位填报人看完后，能独立判断自己的一行需求该填什么单位、落在哪个时间窗、供给数字从哪里取。
核心答案：研发资源需求表的字段设计
字段按需求侧、供给侧、缺口三组组织，每组承担不同职责。需求侧描述“要什么”，供给侧描述“能给什么”，缺口组记录“差多少、怎么办”。三组字段通过需求编号串联，一行需求对应一行或多行供给确认。
| 字段名 | 含义 | 类型 | 必填/选填 | 取值规则 |
|---|---|---|---|---|
| 需求编号 | 唯一标识一行需求 | 文本 | 必填 | 建议“项目缩写-年份-序号”，如 PRJ-2025-018 |
| 项目/事项 | 需求归属的项目或具体事项 | 文本 | 必填 | 与项目清单中的名称一致 |
| 角色与技能 | 所需角色及关键技能要求 | 枚举+文本 | 必填 | 角色从固定枚举选择，技能补充说明，如“后端-熟悉支付链路” |
| 需求人天 | 该角色在该时间窗内的工作量 | 数值 | 必填 | 按口径说明的主单位填写，保留一位小数 |
| 起止时间 | 需求生效的时间窗 | 日期区间 | 必填 | 与表的时间粒度对齐，如按周则填周一至周日 |
| 优先级 | 需求相对重要程度 | 枚举 | 必填 | 固定为 P0/P1/P2/P3 四档，含义在口径说明中定义 |
| 提出人 | 需求填报责任人 | 人员 | 必填 | 一般为项目经理或技术负责人 |
| 可用人力 | 供给侧确认可投入的人天 | 数值 | 必填 | 按口径说明扣除请假、兼职等后的净值 |
| 供给来源 | 人力从哪里来 | 枚举 | 必填 | 内部调配/外部补充/加班/其他，可多选 |
| 确认人 | 对供给数字负责的人 | 人员 | 必填 | 资源负责人或团队负责人 |
| 确认状态 | 供给是否已核实 | 枚举 | 必填 | 待确认/已确认/部分确认/无法满足 |
| 缺口人天 | 需求与供给的差额 | 数值 | 自动计算 | 需求人天减可用人力，小于零记为零 |
| 处置方式 | 缺口的解决路径 | 枚举 | 缺口大于零时必填 | 调整范围/延后时间/内部调配/外部补充/接受风险 |
| 处置责任人 | 跟进缺口关闭的人 | 人员 | 缺口大于零时必填 | 一般为项目负责人 |
| 关闭时间 | 缺口处置结论落定的日期 | 日期 | 缺口关闭时必填 | 填写实际关闭日期，用于统计按期满足率 |
| 备注 | 补充说明 | 文本 | 选填 | 记录依赖关系、特殊约束等 |
必填与选填的划分原则是：影响缺口计算的字段必填，解释性信息选填。优先级和确认状态必须使用固定枚举值，不允许自由填写“高”“紧急”“差不多定了”这类表述，否则无法排序和统计。枚举值一旦发布就保持稳定，新增取值需要同步更新口径说明，并对历史数据做一次回填。
缺口人天建议设为公式字段，由需求人天减可用人力自动得出，减少手工计算出错。当一行需求由多个来源共同满足时，可用人力按来源拆成多行供给记录，缺口在需求行汇总，避免一行里塞多个数字导致无法追溯。
从填报到缺口关闭的操作步骤
表要真正运转，需要四个动作按固定顺序发生，每个动作都有明确的输入和完成标志。
步骤一：需求提出人填报。输入是项目计划和工作量估算结果。提出人按模板逐行填写需求侧字段，需求编号按规则生成，角色从枚举中选择，需求人天依据估算方法得出并在备注中注明估算依据。完成标志是：该时间窗内所有已知需求都已成行，需求侧字段无空缺，优先级已标注。
步骤二：资源负责人确认供给。输入是填报完成的需求行和团队可用人力数据。资源负责人逐行核对，结合成员排期、请假记录、在其他项目的投入比重，给出可用人力和供给来源，填写确认人与确认状态。无法满足的行标记为“无法满足”并说明原因。完成标志是：每一行需求的确认状态不再是“待确认”，供给数字有明确来源。
步骤三：项目负责人处置缺口。输入是缺口大于零的需求行。项目负责人按优先级排序，对每个缺口选择处置方式：压缩范围、调整时间窗、申请内部调配、提出外部补充需求，或明确接受风险。每项处置指定责任人和目标关闭时间。完成标志是：所有缺口行都有处置方式和责任人，处置结论记录在表中而非口头约定。
步骤四：按固定节奏滚动更新。输入是上一版表和本周实际变化。资源管理归口人在固定时间（如每周一上午）组织刷新：关闭已解决的需求，更新供给变化，新增下周进入窗口的需求，输出本周缺口清单。完成标志是：本周缺口清单发出，表内无过期状态，历史版本可查。
四步流程的关键在于顺序不能颠倒。先填报后确认，保证供给数字针对具体需求；先确认后处置，保证缺口基于真实差额而非估算偏差。滚动更新则让表保持“活”的状态，避免成为一次性文档。
角色分工与各自交付物
这张表涉及四类角色，各自的动作和交付物需要写清楚，否则容易出现需求方填了没人确认、确认了没人处置的情况。
| 角色 | 主要动作 | 交付物 | 完成时点 |
|---|---|---|---|
| 需求提出人 | 依据项目计划拆分需求，完成工作量估算，按模板填报 | 完整的需求行 | 每周填报截止前 |
| 资源负责人 | 核对可用人力口径，确认供给来源与数量 | 确认状态与可用人力数字 | 填报截止后两个工作日内 |
| 项目负责人 | 对未满足需求排序并选择处置方式，指定责任人 | 处置结论与关闭时间 | 确认完成后三个工作日内 |
| 资源管理归口人 | 维护模板与枚举值，组织滚动更新，汇总缺口 | 周度缺口视图与历史版本 | 每周固定节奏 |
需求提出人对估算质量负责，估算偏差较大的行需要在下次更新时说明原因。资源负责人对供给数字的真实性负责，确认后的数字若与实际投入明显不符，应在下一轮更新中修正并记录。项目负责人对缺口的处置结论负责，处置方式选定后跟进到关闭。资源管理归口人不替其他角色做判断，只保证流程按时发生、数据口径一致、缺口视图可读。
当团队规模较小、角色由同一人兼任时，仍建议在表中区分动作而非合并字段，保证每个数字都有明确的确认来源。供需对齐和缺口跟踪如果放在项目管理工具里承载，可以由工作项记录需求行、由工时与排期数据支撑供给确认。ONES 资源管理提供资源规划视图，可按业务优先级安排团队资源，并通过工作数量与工时规模查看成员排期和在不同项目的投入比重；成员每日投入饱和明细可用于识别规划风险。这些能力适合承接确认与跟踪环节，字段口径和流程规则仍由团队自行定义。
示例：一个两周窗口的资源需求表怎么填
以下为演示情景，用于说明字段如何协同表达供需与缺口，不代表真实项目数据。
背景：某研发团队未来两周有两个并行事项。事项A为支付模块改造，事项B为报表性能优化。涉及后端、前端、测试三个角色，时间窗为第10周至第11周，按人天计量。
| 需求编号 | 项目/事项 | 角色与技能 | 需求人天 | 起止时间 | 优先级 | 可用人力 | 供给来源 | 确认状态 | 缺口人天 | 处置方式 | 处置责任人 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PAY-2025-006 | 支付模块改造 | 后端-支付链路 | 16 | 第10-11周 | P0 | 12 | 内部调配 | 部分确认 | 4 | 外部补充 | 张（项目负责人） |
| PAY-2025-007 | 支付模块改造 | 前端 | 8 | 第10-11周 | P0 | 8 | 内部调配 | 已确认 | 0 | — | — |
| RPT-2025-011 | 报表性能优化 | 后端-数据查询 | 10 | 第10-11周 | P1 | 6 | 内部调配 | 部分确认 | 4 | 调整范围 | 李（项目负责人） |
| RPT-2025-012 | 报表性能优化 | 测试 | 6 | 第11周 | P1 | 3 | 加班 | 已确认 | 3 | 延后时间 | 李（项目负责人） |
逐项解释：PAY-2025-006 需求16人天，资源负责人确认两周内可投入12人天，缺口4人天，因优先级为P0，项目负责人选择外部补充并指定自己跟进，关闭时间待补充人力到位后填写。PAY-2025-007 供需相等，缺口为零，处置字段留空。RPT-2025-011 缺口4人天，优先级P1，项目负责人选择压缩优化范围，将部分非核心查询的优化延至下一版本。RPT-2025-012 测试需求集中在第11周，可用人力仅3人天，缺口3人天，处置为延后部分测试用例执行时间。
这个示例体现了几个填写要点：缺口由公式自动算出而非手填；处置方式必须与缺口行一一对应；同一事项的不同角色分行填写，便于按角色汇总；优先级取值来自固定枚举，保证排序一致。示例中的供给数字均按扣除例会和例行支持后的净值填写，与口径说明保持一致。
完成检查：这张表是否真的可用
表建起来不等于能用。以下检查项可在首次上线后两周和之后每月各做一次，逐项判断。
字段完整性检查。随机抽取20行需求，检查必填字段是否全部有值，需求编号是否唯一，角色是否来自枚举列表。通过标准：必填字段空缺率低于5%，无重复编号。
枚举值一致性检查。检查优先级、确认状态、处置方式三组枚举是否存在自由填写的变体，如“P0”与“p0”、“已确认”与“确认”。通过标准：枚举字段取值全部落在定义列表内，无变体。
供需口径一致性检查。对比需求侧与供给侧的时间粒度是否一致，供给数字是否按口径说明扣除了请假和兼职投入。通过标准：两侧时间窗完全对齐，抽查5行供给数字与排期数据吻合。
缺口闭环检查。检查所有缺口大于零的行是否都有处置责任人和目标关闭时间，已关闭的行是否填写了实际关闭时间。通过标准：缺口行责任人覆盖率100%，关闭时间填写率不低于90%。
更新节奏检查。查看历史版本记录，确认是否按约定节奏更新，是否存在连续两周以上未刷新的情况。通过标准：更新间隔符合口径说明，历史版本可追溯每次变化。
效果验证。用两个指标判断表是否在发挥作用。缺口率等于缺口人天合计除以需求人天合计，反映供需紧张程度；按期满足率等于按期关闭的缺口行数除以缺口行总数，反映处置是否落地。两个指标按周或按月统计并观察趋势，缺口率持续偏高说明规划需要前置调整，按期满足率偏低说明处置环节缺少跟进。指标本身不设统一阈值，团队可结合自身节奏确定观察基线。
检查发现的问题应回到对应环节修正：字段问题改模板，口径问题改说明，流程问题改节奏或责任分工。表的设计在运行中逐步收敛，比一次追求完美更实际。
常见问题
需求人天应该由谁估算，估算偏差大怎么办？
需求人天一般由需求提出人依据项目计划和工作量估算方法得出，并在备注中注明估算依据。资源负责人确认供给时若发现估算明显偏离，应在确认状态中标注并反馈给提出人复核。
估算偏差较大的行，建议在下一轮滚动更新时说明原因，例如需求范围变化、技术方案调整或遗漏了联调与缺陷修复工作。连续多行偏差偏大，说明估算方法或口径说明需要修订，而不是逐行手工修正数字。
一行需求由多个来源共同满足时，表里怎么填？
建议把可用人力按供给来源拆成多行供给记录，每行填写来源、数量、确认人和确认状态，需求行只保留需求侧字段和汇总后的缺口。这样缺口计算仍然成立，同时每个数字都能追溯到具体来源和确认人。
如果团队规模小、来源单一，也可以在一行内填写，但供给来源字段要如实标注，避免后续统计时无法区分内部调配与外部补充。
按周滚动更新时，历史需求行要不要保留？
要保留。已关闭的需求行建议标记关闭状态并保留在原表中，或归档到历史版本，用于统计按期满足率和回溯缺口处置过程。直接删除会让缺口率、按期满足率失去分母，也无法回答“上个月哪些缺口没解决”。
滚动更新时新增的是进入时间窗的新需求，更新的是供给数字和确认状态，关闭的是已有处置结论的行，三类动作分开记录。
团队没有专职资源负责人，这张表还能运转吗？
可以，但需要明确由谁承担供给确认这个动作。常见做法是由技术负责人或团队负责人兼任资源负责人，在固定节奏内完成确认。角色可以合并，动作不建议省略：没有确认环节，供给数字就只是需求方的单方估计，缺口计算失去意义。
兼任时仍建议在表中保留确认人字段，让每个供给数字都有明确来源，便于后续追溯和口径校准。
缺口率和按期满足率应该多久统计一次？
统计频率与表的更新节奏保持一致即可。按周滚动更新的团队按周统计，按月度快照的团队按月统计。频率过高会增加维护成本，频率过低则难以及时发现供需失衡。
两个指标建议观察趋势而非单点数值，团队可结合自身节奏确定观察基线。缺口率持续偏高说明规划需要前置调整，按期满足率偏低说明处置环节缺少跟进，两种情况都应回到对应流程环节处理。
