研发资源需求澄清清单用于在排期和人员分配之前，把一项研发需求对可用人力的真实占用讲清楚。清单覆盖五类信息：需求来源与业务背景、交付范围与时间约束、技能与角色要求、工作量与投入估算、依赖与风险条件。每一项都配有通过标准、证据和负责人，无法确认的关键项标为阻断项，澄清通过后再进入容量评估与排期。
要点总览（TL;DR）
- 澄清清单在需求进入容量评估之前使用，由需求提出方填写、研发负责人审核技术可行性、资源或项目管理人员确认人力口径，三方确认后才进入供需匹配与排期。
- 清单覆盖五类信息：需求来源与业务背景、交付范围与时间约束、技能与角色要求、工作量与投入估算、依赖与风险条件，每项都写明通过标准、证据和负责人。
- 通过标准要可观察、可核对，证据指向具体记录；未通过项按标注原因、退回补充、重新审核的固定动作流转，直到通过或转为阻断项。
- 交付范围、关键技能、最晚交付时间、重大外部依赖四类设为阻断项，未确认就不进入容量评估；非阻断项记录跟踪人和截止时间即可放行。
- 澄清完成的条件是全部阻断项通过、非阻断项已指定跟踪人、三方确认结论，结论记录随需求交接给容量评估环节。
谁在什么时点使用这份澄清清单
这份清单解决的是“需求信息还没讲清楚就开始排期”的问题。它由需求提出方填写，研发负责人审核技术可行性，资源或项目管理人员确认人力口径，三方在需求进入容量评估之前完成一次集中澄清。澄清结果作为容量评估的输入，澄清未通过的需求不进入供需匹配与人员分配。
使用时点可以按下面的角色—时点对照表执行：
| 角色 | 在什么时点做什么 | 产出 |
|---|---|---|
| 需求提出方 | 需求提交后、进入容量评估前，填写来源背景、交付范围、时间要求 | 已填写的清单主体与背景证据 |
| 研发负责人 | 收到清单后审核范围可行性、技能要求与估算依据 | 技术审核意见与估算复核记录 |
| 资源或项目管理人员 | 澄清会上确认人力口径、依赖条件与阻断项 | 澄清结论与是否放行的判定 |
清单与后续环节的衔接要写清楚：澄清通过的需求才进入容量评估，评估结果再进入排期与人员分配。组合层面的项目承接取舍和具体人员排期属于相邻环节，不在本清单范围内。
需求来源与业务背景检查项
这一组检查项回答“需求从哪里来、为什么现在做”。背景不清的需求往往在排期后反复变更，先确认来源和业务目标，后续判断优先级和投入规模才有依据。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求提出方与业务归属 | 写明提出人、所属业务线、对接人，能直接联系确认 | 需求单或邮件记录 | 需求提出方 |
| 需求来源类型 | 明确标注为客户需求、内部改进、合规要求或技术债等类别 | 来源说明或工单链接 | 需求提出方 |
| 业务目标与预期结果 | 用可观察的结果描述目标，如上线后支持的业务场景或指标变化 | 业务说明文档 | 需求提出方 |
| 不做的后果与时间敏感性 | 说明延迟交付的影响，以及是否存在硬性时间点 | 业务方确认记录 | 需求提出方与业务负责人 |
这组检查项的判定重点是“能否被第三方核对”。例如“提升用户体验”无法核对，改为“支持某类客户在移动端完成下单”就可以核对。来源类型影响优先级判断，时间敏感性影响资源投入的紧迫程度，两项都需要在清单中留下明确记录。
交付范围与时间约束检查项
范围含糊是资源误估的常见原因。这一组检查项把交付边界和时间要求写成可核验的条目，让研发负责人能判断工作量边界，让资源管理人员能判断时间窗口是否可行。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 交付物清单 | 逐项列出要交付的功能、文档、配置或数据产物 | 需求说明或原型 | 需求提出方 |
| 明确不做的范围 | 列出本期不包含的功能和场景，避免默认扩展 | 范围确认记录 | 需求提出方与研发负责人 |
| 关键里程碑与最晚交付时间 | 给出可核对的日期节点，并说明时间要求的来源 | 项目计划或业务承诺 | 需求提出方 |
| 验收方式与验收人 | 写明验收标准、验收环境和最终确认人 | 验收方案 | 需求提出方与测试负责人 |
| 范围变更的确认方式 | 约定变更由谁提出、谁确认、如何记录 | 变更流程说明 | 项目管理人员 |
“明确不做的范围”容易被省略，但它是控制资源占用的关键条目。没有这一项，后续讨论中容易把相邻功能一并纳入，导致估算失效。最晚交付时间要区分业务硬约束和内部期望，两者对资源投入的紧迫程度不同。
技能、角色与工作量估算检查项
这一组检查项把需求对人员能力和投入量的要求拆成可确认的条目，用于和现有团队容量做比对。估算要留下依据和复核人，避免只给一个总数。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 所需角色与技能项 | 列出前端、后端、测试、设计等角色及关键技能，稀缺技能单独标注 | 技能需求说明 | 研发负责人 |
| 各角色预计投入 | 按人天或人周给出投入量，并说明估算依据，如类比需求或拆解后的任务量 | 估算记录 | 研发负责人 |
| 可拆分与并行情况 | 说明能否拆分、并行或分阶段交付，以及拆分后的依赖关系 | 任务拆解说明 | 研发负责人 |
| 估算不确定区间与复核人 | 给出估算区间和主要不确定因素，指定复核人 | 复核记录 | 研发负责人与复核人 |
稀缺技能标注直接影响容量比对的结论：同样的人天投入，如果技能在团队内只有一人具备，实际可用容量会明显受限。估算依据要能被复核人追溯，例如引用类似需求的实际工时或任务拆解结果。估算区间用于提示风险，区间过宽的需求应在澄清阶段补充拆解。
依赖、风险与外部条件检查项
这一组检查项识别会影响资源可用性的前置条件。依赖未就绪时，人力即使排上也无法有效投入，因此需要在澄清阶段就登记并约定处理方式。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 外部依赖 | 列出接口方、供应商、第三方系统，写明对接人和就绪时间 | 对接确认记录 | 需求提出方 |
| 内部依赖 | 列出其他团队的交付物、环境与测试资源，写明提供时间 | 协作确认记录 | 研发负责人 |
| 风险项及影响 | 逐项说明风险对工期和人力占用的影响，并标注风险等级 | 风险登记记录 | 项目管理人员 |
| 依赖未就绪时的处理约定 | 约定等待、替代方案或调整排期的触发条件与决策人 | 处理约定记录 | 研发负责人与项目管理人员 |
依赖项要写到“谁在什么时间提供什么”，只写“需要其他团队配合”无法核对。风险等级可以用高、中、低标注，并对应到具体的应对责任人。处理约定要明确触发条件，例如接口在约定日期未就绪时由谁决定是否调整排期。
通过标准、证据与负责人如何判定
清单能否逐项判断通过，取决于每项的写法。通过标准要可观察、可核对，证据要能指向具体记录，负责人要明确到角色或具体人员，确认时点要与流程节点对应。
通过标准的写法可以遵循三个要求：描述一个可观察的结果，例如“列出本期不包含的功能”；指明核对方式，例如“由研发负责人对照需求说明确认”；给出完成标志，例如“范围确认记录已归档”。证据形式包括需求文档、估算记录、对接确认记录、会议纪要或系统内的确认记录。负责人要区分填写人和审核人，避免同一人既填又审导致口径失真。
未通过项的处理流程建议写成固定动作：审核人标注未通过原因，退回填写人补充，补充后重新提交审核，直到该项通过或转为阻断项。确认时点与流程节点绑定，例如范围与时间约束在澄清会前完成审核，技能与估算在澄清会上确认。这样清单不只是一张表，而是有明确流转规则的检查工具。
澄清结果需要被承载和跟踪时，可以放入工作项与文档中管理。ONES 的需求与工作项管理可以承载需求条目、澄清记录和状态流转，资源管理支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重，便于把澄清后的投入口径与容量视图对应起来。具体字段配置和模板能力以实际产品版本为准，选型时可作为核验点。
阻断项与澄清完成条件
阻断项是未确认就不能进入容量评估的检查项。建议将以下四类设为阻断项：交付范围未明确、关键技能要求未确认、最晚交付时间未确定、重大外部依赖未登记。这四类信息缺失时，容量评估的结论没有可靠基础，排期后返工的概率明显上升。
| 类别 | 阻断条件 | 解除方式 |
|---|---|---|
| 交付范围 | 交付物清单或不做范围缺失 | 需求提出方补充并经研发负责人确认 |
| 关键技能 | 稀缺技能需求未标注或未确认可获得性 | 研发负责人确认技能来源与投入方式 |
| 最晚交付时间 | 无明确时间节点或时间来源不明 | 业务方书面确认时间要求 |
| 重大依赖 | 关键外部依赖无对接人和就绪时间 | 补充对接确认记录并约定处理方式 |
非阻断项包括背景描述的细化、验收方式的补充说明等，可以记录为待跟踪事项，由负责人在约定时点前补齐，不阻塞澄清通过。跟踪方式要写明责任人和截止时间，避免遗漏。
澄清完成的整体判定条件可以归纳为：全部阻断项已通过，非阻断项已记录并指定跟踪人，需求提出方、研发负责人和资源或项目管理人员三方确认结论。确认后形成澄清结论记录，随需求一并交接给容量评估环节，作为供需匹配的输入。ONES 的资源规划视图支持按业务优先级安排和计划团队资源，资源利用率与负荷度可以查看，澄清后的投入口径可以在这一环节继续核对；具体流转方式以实际配置为准。
常见问题
需求提出方和研发负责人对工作量的估算差距很大，清单里应该怎么处理？
把两个估算值都写进清单，并各自注明依据：需求提出方通常按业务期望倒推，研发负责人按任务拆解或类似需求的实际工时估算。清单中保留估算区间和主要不确定因素，指定复核人，在澄清会上逐项对齐差异来源。差异集中在某个模块时，先补充该模块的拆解再重新估算，避免用平均值掩盖分歧。估算区间过宽的需求，应在澄清阶段继续拆解，而不是直接带入容量评估。
需求已经排期，澄清时才发现关键依赖未就绪，清单还能起什么作用？
清单此时的作用是登记依赖现状并触发处理约定，而不是补做形式审核。把依赖项写到“谁在什么时间提供什么”，标注风险等级和应对责任人，再按清单中约定的触发条件决定等待、启用替代方案还是调整排期。这类情况也说明澄清时点需要前移：后续需求应在进入容量评估前完成依赖登记，把重大外部依赖列为阻断项，未登记不放行。
小团队或需求量不大的情况下，这份清单可以简化吗？
可以按风险调整，但阻断项建议保留。需求来源与业务背景、验收方式等条目在小团队中可以合并成简短说明，交付范围、关键技能、最晚交付时间和重大依赖这四类仍应逐项确认，因为它们直接决定人力占用是否估得准。简化方式可以是减少填写字段、缩短澄清会时长，而不是取消阻断判定。团队规模、需求紧急程度不同，简化的程度也应不同，由研发负责人和资源管理人员共同约定。
澄清结论如何交接给容量评估，后续需求变更时怎么追溯？
澄清结论应形成一份记录，包含各检查项的通过状态、阻断项解除情况、估算区间和确认人，随需求一并交接给容量评估环节，作为供需匹配的输入。需求发生范围或时间变更时，按清单中约定的变更确认方式重新走一遍受影响的检查项，并在原记录上留下变更痕迹，便于追溯估算口径为何调整。把澄清记录与需求条目放在同一处管理，可以减少交接时的信息丢失；ONES 的需求与工作项管理可以承载需求条目、澄清记录和状态流转，具体字段配置以实际产品版本为准。
清单里的技能要求写到什么颗粒度才够用？
写到能判断团队是否具备、缺口如何补的程度即可。角色层面列出前端、后端、测试、设计等，技能层面标出影响排期的关键项，例如特定框架经验、特定系统对接经验或稀缺技能，并注明团队内可投入的人数。颗粒度过细会拉长填写时间，过粗则无法支撑容量比对。判断标准是：资源管理人员看完这一项，能回答“现有团队能否覆盖、需要外部补充还是调整排期”。
