研发资源需求澄清清单：检查项与通过标准

研发资源需求澄清清单用于需求进入资源评估之前，把来源、交付约束、技能要求和可用人力逐项核对清楚。清单覆盖四类检查项，每项写明通过标准、证据和负责人，并标出未通过就不能进入排期的阻断项。记录可以放在 ONES 的工作项与文档中，便于后续复核。

要点总览（TL;DR）

• 澄清清单在需求进入资源评估前使用，由需求提出人、研发负责人、资源协调人三方在同一份记录上确认，澄清完成后再交给排期流程。
• 检查项分四类：需求来源与依据、交付约束、技能与角色要求、可用人力供需；每项写明通过标准、证据和负责人。
• 范围与验收口径、依赖方确认、关键角色人选是最容易含糊的三处，需要写到可逐条判断、对方已确认、有人选或候选范围的程度。
• 供需核对采用通过、不通过、待补充三档判定，待补充项要写明补齐时限，到期未补齐按不通过处理。
• 来源或目标缺失、范围与验收不清、关键依赖未确认、关键角色无人选、供需判定不通过且未调整，通常列为阻断项，补齐前不进入排期。

谁在什么时点使用这份澄清清单

这份清单由需求提出人填写，研发负责人核对技能与交付可行性，资源协调人核对可用人力。三方在同一份记录上确认，避免澄清结论只停留在口头沟通。使用时点是需求进入资源评估之前、排期之前，澄清完成后再交给排期流程处理。

澄清与排期、组合取舍是前后衔接的三件事。澄清回答“这个需求是否说清楚了、有没有条件承接”；排期回答“什么时候做、谁来做”；组合取舍回答“多个需求争抢同一批人时先做哪个”。本清单只处理第一件事，不展开具体人员排期和组合层面的承接决策。

角色	主要动作	使用时点	输出
需求提出人	填写来源、目标、范围、验收口径、期望时间	提交需求时	来源与依据、交付约束两部分初稿
研发负责人	核对技能要求、依赖条件、质量与合规约束	资源评估前	技能与角色要求、约束确认意见
资源协调人	对照现有可用人力，给出供需判定	排期前	供需核对结论与缺口说明
复核人	检查阻断项是否补齐，确认清单可归档	进入排期前	通过结论与归档记录

需求来源与依据检查项

这一部分确认需求从哪里来、依据是否成立。来源不清或依据缺失的需求，即使技术可行，也不应占用人力，因为后续无法判断投入是否值得、范围变化时也没有对照基准。

检查项	通过标准	证据	负责人
需求提出方与业务目标	写明提出方、对接人，以及该需求支撑的业务目标，目标可对应到具体指标或业务结果	需求单中的提出方字段与目标描述	需求提出人
需求来源类型	标注为客户需求、内部改进、合规要求或其他类型，并说明来源对象或依据文件	客户反馈记录、合规条款、内部改进提案	需求提出人
优先级依据	给出优先级判断的理由，如客户影响范围、合规时限、业务收益，并有决策记录	优先级评审记录或决策纪要	需求提出人、业务负责人
需求范围与验收口径	范围边界清楚，列出包含与不包含的内容；验收标准可逐条判断是否达成	需求说明文档、验收条件列表	需求提出人、研发负责人

范围与验收口径是最容易含糊的一项。可核验的写法是把“提升体验”这类表述换成具体场景和判断条件，例如“某类操作在指定步骤内完成”“某类数据可按指定维度导出”。范围中明确不包含的内容同样要写，避免评估时按大范围估算人力、交付时又按小范围验收。

在 ONES 中，需求可以作为工作项记录来源、提出方和优先级，澄清结论与决策记录放在对应文档里，与工作项关联，后续复核时能直接追溯到依据。

交付约束检查项

交付约束决定人力投入的前提条件。时间、依赖、质量与合规要求没有写清，资源评估就只能给出模糊结论，排期后也容易因外部条件变化反复调整。

检查项	通过标准	证据	负责人
期望交付时间与关键里程碑	写明期望上线时间及关键节点，说明时间是硬约束还是可协商	需求单中的时间字段、里程碑说明	需求提出人
上下游依赖与外部配合方	列出依赖的系统、团队或供应商，注明对方已确认的配合时间	依赖清单、对方确认记录	研发负责人
质量与合规要求	写明需满足的质量标准、评审环节和合规条款，明确由谁验证	质量标准文档、合规要求清单	研发负责人、质量负责人
变更与延期处理约定	约定范围变更、时间延期的触发条件和确认方式，明确变更由谁审批	变更约定条款或会议纪要	需求提出人、研发负责人

依赖项要写到“对方已确认”的程度。仅写“依赖某系统接口”不足以支撑评估，需要注明接口提供方、可用时间和联调安排。合规要求则要区分必须满足与建议满足，前者通常构成阻断条件。

技能与角色要求检查项

这一部分把需求拆到技能和角色层面，判断现有人员能否承接。只写“需要后端开发两名”往往不够，技能等级和关键角色缺位会直接改变人力结论。

检查项	通过标准	证据	负责人
所需技能与经验等级	列出关键技术栈、业务领域经验及等级要求，区分必备与加分项	技能需求清单	研发负责人
关键角色与职责分工	明确技术负责人、核心开发、测试等角色及各自职责，关键角色有指定人选或候选范围	角色分工说明	研发负责人
人数与投入比例	给出各角色人数和投入比例，说明投入是全程还是阶段性	人力需求估算表	研发负责人
稀缺技能的可替代方案	对稀缺技能给出替代路径，如内部培养、跨团队支持或调整技术方案，并说明对时间的影响	替代方案说明	研发负责人、资源协调人

投入比例要按阶段写。一个需求在开发期和联调期对测试人力的需求差别很大，只写总量会让供需核对失真。稀缺技能的替代方案需要同时说明代价，例如跨团队支持会拉长沟通周期，调整技术方案可能影响部分验收条件。

可用人力供需核对与通过标准

供需核对把需求侧的人力要求与现有可用人力放在同一口径下对照，每项给出通过、不通过或待补充的判定。判定依据要能指向具体记录，避免结论停留在印象层面。

核对项	通过标准	判定档位	证据与负责人
现有可用人力与缺口	按角色和技能列出可用人数、可用时间窗口，与需求人数对照，缺口数量明确	无缺口为通过；缺口可通过调配补齐为待补充；缺口无法在期望时间内补齐为不通过	资源视图或人力台账；资源协调人
关键角色到位情况	关键角色有明确人选或已确认的外部支持	已到位为通过；有候选待确认为待补充；无人选为不通过	人员安排记录；研发负责人
时间窗口匹配	可用人力的时间窗口覆盖需求的关键阶段	完全覆盖为通过；部分覆盖且可调整为待补充；无法覆盖为不通过	排期视图或可用性记录；资源协调人
稀缺技能供给	稀缺技能有确定来源，替代方案的代价已被接受	有确定来源为通过；替代方案待确认为待补充；无来源为不通过	技能供给说明；研发负责人

三档判定的用法要统一：通过表示可以进入排期；待补充表示条件可在约定时限内补齐，补齐前不承诺交付时间；不通过表示当前条件下无法承接，需要调整范围、时间或另作安排。每项判定都要留下证据，例如资源视图截图、人力台账记录或确认邮件，并注明复核时点，通常设在进入排期前的评审会上。

ONES 资源管理可以展示工作和资源情况，支持查看成员工作量、可用性与饱和情况，并按项目查看投入比重，适合作为供需核对的依据来源；工时登记日志可查询和导出，便于留存核对记录。具体计算口径以团队实际配置为准。

阻断项与完成条件

阻断项是未通过就不能进入排期的条目。把阻断项单独列出，可以避免清单填了很多项、关键条件却没人跟进的情况。以下条目通常列为阻断项：需求来源与业务目标缺失；范围与验收口径无法判断；关键依赖方未确认配合时间；合规要求未明确；关键角色无人选；供需核对判定为不通过且未调整范围或时间。

阻断项	补齐责任人	时限	完成条件与复核方式
来源或业务目标缺失	需求提出人	资源评估会前	需求单补齐提出方与目标，复核人确认可对应到业务结果
范围与验收口径不清	需求提出人、研发负责人	资源评估会前	范围包含与不包含内容列明，验收条件可逐条判断
关键依赖未确认	研发负责人	排期评审前	依赖方书面确认配合时间，记录附在需求下
关键角色无人选	研发负责人、资源协调人	排期评审前	指定人选或确认外部支持，更新人力安排记录
供需判定不通过	资源协调人、需求提出人	下一次评估前	调整范围或时间后重新核对，判定改为通过或待补充

补齐后由复核人按完成条件逐项确认，确认通过的清单随需求一起归档，作为后续变更和复盘的对照依据。交接时把清单、证据和判定结论一并转给排期环节，排期只处理已澄清通过的需求。待补充项要写明补齐时限，到期未补齐的按不通过处理，重新进入澄清流程。

常见问题

澄清清单和排期、组合取舍是什么关系，会不会重复劳动？

三者是前后衔接的关系，各自回答不同问题。澄清清单回答“这个需求是否说清楚了、有没有条件承接”；排期回答“什么时候做、谁来做”；组合取舍回答“多个需求争抢同一批人时先做哪个”。

实际操作中，澄清完成并通过复核的需求才转给排期环节，排期只处理已澄清的需求，不会重复核对来源和验收口径。组合层面的承接决策由对应流程处理，澄清清单只提供每项需求的人力要求和供需判定作为输入。

需求提出人自己填清单，如何避免自评过宽？

关键在于把填写和核对分开。需求提出人负责来源、目标、范围、验收口径和期望时间；研发负责人核对技能要求、依赖条件、质量与合规约束；资源协调人对照可用人力给出供需判定；复核人在进入排期前检查阻断项是否补齐。

范围与验收口径这类容易写宽的条目，可以要求写成可逐条判断的条件，例如具体场景和判断标准，并同时列出不包含的内容。研发负责人在核对环节对范围提出意见，形成相互校验。

待补充项到期没补齐，应该怎么处理？

按不通过处理，重新进入澄清流程。待补充表示条件可在约定时限内补齐，补齐前不承诺交付时间；时限到期仍未补齐，说明当前条件下无法承接，需要调整范围、时间或另作安排。

为避免到期才发现，可以在清单上写明补齐责任人和时限，并在复核时点逐项确认状态。重新进入澄清流程时，保留原有记录和证据，便于对照变化。

小团队人手少，四类检查项都要完整填吗？

检查项可以按需求风险裁剪，但阻断项不建议省略。来源与目标、范围与验收口径、关键依赖确认、关键角色人选这几项直接决定能否承诺交付，即使团队小也应保留。

交付约束中的质量与合规要求、变更与延期约定，可以按需求类型简化表述，例如内部改进类需求合规条款较少时注明“不涉及”即可，但要留下判断记录。裁剪的原则是：影响人力承诺的条目保留，其余条目可以合并填写。

供需核对用资源视图还是人力台账，证据怎么留？

两者都可以，关键是同一口径、可追溯。资源视图适合看成员工作量、可用性与饱和情况，以及在不同项目的投入比重；人力台账适合记录按角色和技能汇总的可用人数与时间窗口。

证据留存方式包括资源视图记录、人力台账条目或确认邮件，并注明复核时点，通常设在进入排期前的评审会上。ONES 资源管理可以展示工作和资源情况，支持查看成员工作量、可用性与饱和情况，工时登记日志可查询和导出，可作为核对依据来源；具体计算口径以团队实际配置为准。