研发资源需求澄清清单：需求来源与交付约束检查项

2026年11月11日

研发资源需求澄清清单的价值，在于把“这个需求能不能接”从口头判断变成可逐项核对的记录。它要覆盖五类需求来源：项目立项与里程碑承诺、产品路线图与版本计划、线上问题与运维支持、技术债与平台改造、临时插入与外部依赖；同时逐条锁定时间窗口、交付范围与验收口径、技能与人数、依赖方与外部交付、质量与合规门槛。每一项都写明通过标准、证据和负责人，任一项未确认即视为阻断，不进入容量测算。清单条目可以在ONES中作为工作项登记并跟踪澄清状态，具体字段与流程按团队实际配置。

Table of Contents

要点总览（TL;DR）

清单按“来源—约束—技能匹配—阻断判定—落地跟踪”组织，先确认需求是否成立，再判断能否承接。
需求来源至少覆盖五类：项目立项与里程碑承诺、产品路线图与版本计划、线上问题与运维支持、技术债与平台改造、临时插入与外部依赖，并指定唯一主来源避免重复计数。
交付约束至少覆盖时间窗口、交付范围与验收口径、技能与人数、依赖方与外部交付、质量与合规门槛，每项写明通过标准、证据和负责人。
技能与可用人力对照按技能族归并需求，统一在岗人数、可用工时、共享比例口径，缺口只标注不移交排期。
任一项影响承接判断的未确认项即阻断，清单完成以阻断清零或剩余阻断项有责任人和补全期限为判定条件。

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

这份清单服务于立项评审、版本规划和季度容量测算三个决策点，使用对象包括研发负责人、项目经理、资源管理岗和技术负责人。它解决的是“需求还没说清楚就进入排期”的问题，因此必须在排期动作之前完成核对。

使用前需要准备三类前置输入：需求池中的候选条目、里程碑草案、在研项目清单。三者缺一，清单就无法判断新需求与既有承诺是否冲突。清单的产出物是两份记录：已澄清需求条目（含来源、约束、技能要求）和阻断项记录（含缺失项、责任人和补全期限）。

使用对象	使用时点	主要动作	产出
项目经理	立项评审前	核对需求来源与里程碑承诺	来源确认记录
技术负责人	版本规划前	确认技能要求、技术依赖与质量门槛	约束确认记录
资源管理岗	季度容量测算前	汇总已澄清条目，做技能供需对照	供需对照表
研发负责人	评审会与阻断项裁决	判定阻断、决定是否进入测算	阻断项清单与结论

时点判断有一个简单规则：只要该需求尚未出现在任何已承诺的里程碑或版本计划中，就应在立项评审前完成澄清；已进入计划但范围或时间发生变更的，在变更评审前重新核对相关条目。

需求来源检查项：五类来源逐项核对

来源核对的目标是“不遗漏、不重复计数”。同一需求可能同时出现在立项承诺和版本计划中，此时必须指定唯一主来源，其他来源只作关联记录，避免在容量测算中被算两次。每类来源的检查项、通过标准、证据和负责人如下表。

来源类别	检查项	通过标准	证据	负责人
项目立项与里程碑承诺	需求是否对应已批准立项或对外承诺的里程碑	能指向立项编号或里程碑条目，承诺对象与交付日期明确	立项批复、里程碑计划、合同或承诺函	项目经理
产品路线图与版本计划	需求是否在已发布或已评审的路线图、版本范围内	版本号、目标发布窗口、范围说明齐全	路线图文档、版本规划评审记录	产品负责人
线上问题与运维支持	问题等级、影响范围与期望修复时限是否明确	有故障单或工单编号，等级判定符合团队分级标准	故障单、工单、影响面统计	运维负责人或值班负责人
技术债与平台改造	改造对象、触发原因与不做的后果是否说明	能指出具体系统或模块，说明风险或成本依据	技术方案、架构评审记录、故障复盘	技术负责人
临时插入与外部依赖	插入原因、提出方与可协商空间是否记录	提出方明确，能说明与既有承诺的冲突关系	需求变更单、外部对接纪要	项目经理

核对时建议按类别逐行过，而不是按需求逐条问“它属于哪类”。按类别过的好处是能发现某类来源整体缺失，例如技术债长期没有进入需求池，或线上问题只靠口头传递。发现某类来源为空时，先确认是真的没有，还是记录渠道缺失，再决定是否放行。

去重操作放在来源核对之后、约束核对之前。做法是给每条需求标注唯一主来源，关联来源写入备注；两条记录指向同一交付物时合并为一条，保留信息更完整的那条。

交付约束检查项：时间、范围、技能与依赖

来源确认只回答“需求是否成立”，交付约束回答“能否按承诺交付”。约束项未确认时，需求即使来源清晰也不能进入容量测算。下表给出五类约束的检查口径。

约束类别	检查项	通过标准	证据	负责人
时间窗口与关键里程碑	期望交付日期、最晚可接受日期、关键节点是否明确	两个日期均有记录，关键节点可对应到里程碑	里程碑计划、承诺邮件或纪要	项目经理
交付范围与验收口径	本期做什么、不做什么、验收由谁判定是否写清	范围清单可逐项勾选，验收人与验收标准明确	需求说明、验收标准文档	产品负责人与技术负责人
技能要求与人数配置	所需技能栈、人数与投入比例是否给出	技能项可对应到岗位或人员能力标签，人数与投入比例有数值	技能需求说明、人力申请记录	技术负责人
依赖方与外部交付节点	上下游团队、外部供应商的交付物与时间是否确认	每个依赖方有对接人和承诺日期，延迟时的应对方式已记录	接口文档、联调计划、外部合同节点	项目经理
质量与合规门槛	性能、安全、数据合规等门槛是否明确且可验证	门槛有量化指标或评审结论，验证方式已确定	质量门禁清单、安全评审记录、合规评估结论	技术负责人与质量负责人

时间约束要区分“期望日期”和“最晚可接受日期”。只记录期望日期时，一旦资源紧张就没有协商空间；两个日期都记录，才能在容量不足时判断是压缩范围还是调整时间。范围约束的关键是写出“不做什么”，否则验收阶段容易因理解差异返工。

技能与人数约束在这一步只记录需求侧的要求，不判断是否有人可用。是否具备承接条件放到下一步的供需对照中判断，避免把“要什么人”和“有没有人”混在一次讨论里。

技能与可用人力匹配的核对方法

供需对照的做法是先把已澄清需求按技能维度归并，再用统一的可用人力口径去比。归并时按技能族聚合，例如后端服务、前端、数据、测试、运维，同一技能族内的需求合并计算人天或工时，避免逐条需求单独找人导致碎片化。

可用人力口径要写清三件事：在岗人数、可用工时、共享比例。在岗人数指实际可投入该项目群的人数；可用工时扣除休假、培训、支持性工作后的净投入；共享比例指同一人同时服务多个项目时的分配比例。三者不统一，供需对照的结论就不可比。

技能族	需求侧（人天或工时）	可用人力（净投入）	缺口	标注方式
后端服务	按已澄清条目汇总	在岗人数×可用工时×共享比例	需求减可用	缺口为正标“不足”，为负标“有余量”
前端	同上	同上	同上	同上
测试	同上	同上	同上	同上

缺口标注只回答“够不够”，不回答“怎么调”。缺口为正的条目连同技能族、缺口量和时间窗口一起移交容量规划环节，由该环节决定是调整优先级、外部补充还是压缩范围。这样分工可以避免澄清会议变成排期会议，也能让容量测算拿到口径一致的输入。

阻断项与完成条件

阻断原则只有一条：影响“能否承接”判断的未确认项，一律阻断。具体分为三类，每类都有可核验的判定方式。

来源缺失或重复计数。需求无法归入五类来源中的任何一类，或同一交付物在两条记录中分别计数，均阻断。判定方式：来源字段为空，或去重后条目数与原始条目数不一致且无合并说明。
交付约束未确认。时间窗口、范围与验收口径、技能与人数、依赖方、质量与合规门槛中任一项缺少通过标准或证据，阻断。判定方式：对应行的证据栏为空，或负责人未签署确认。
技能与人数未落实。需求侧技能要求未写明，或供需对照中缺口为正且未标注处理去向，阻断。判定方式：技能族字段为空，或缺口行没有移交记录。

清单整体完成的判定条件建议设为：所有条目均有唯一主来源；五类约束每项都有通过标准和证据；每条需求的技能要求已归入技能族并完成供需对照；阻断项为零，或剩余阻断项已明确责任人和补全期限且经研发负责人确认可延后处理。满足这些条件后，清单才能作为容量测算的输入交付。

清单落地：用工作项承载澄清状态

清单如果停留在表格里，状态更新和交接容易脱节。更稳妥的做法是把每条需求登记为一个工作项，用字段承载澄清信息，用状态反映推进阶段。ONES 支持通过工作数量和工时规模了解成员排期，并可按筛选与分组查看成员在不同项目的投入比重，适合承接这类逐条跟踪的需求条目。

落地流程可以按以下顺序组织：

登记。每条候选需求建为一个工作项，填写来源类别、唯一主来源、期望日期与最晚可接受日期、技能族、人数与投入比例等字段。
澄清。负责人按来源检查和约束检查逐项补充证据，证据以附件或关联文档形式挂在条目上；未补齐的条目保持“待澄清”状态。
评审与交接。评审会上逐条过阻断项，通过后状态改为“已澄清”，并记录评审结论与交接对象；未通过的保留阻断标记和补全期限。
回写。已澄清条目按技能族汇总，形成供需对照的输入；ONES 的资源规划视图可按业务优先级安排团队资源，帮助在可用资源与需求之间做平衡，缺口部分再进入容量规划环节处理。

状态字段建议控制在少量取值，例如待澄清、已澄清、阻断、已移交，避免状态过多导致维护成本上升。负责人字段与证据字段是判断条目是否真正完成的关键，评审时以这两个字段为准，而不是以口头说明为准。清单条目的字段配置和状态流转方式，按团队现有的工作项类型和流程设置即可。

常见问题

同一需求同时出现在立项承诺和版本计划里，清单上应该怎么记？

指定一个唯一主来源，另一处只作关联记录。来源核对完成后先做去重：两条记录指向同一交付物时合并为一条，保留信息更完整的那条，并在备注里写明关联来源。这样在容量测算时不会被算两次，评审时也能追溯需求最初由哪条承诺或计划触发。

期望交付日期和最晚可接受日期都拿不到，能不能先进入容量测算？

不建议。时间窗口属于交付约束检查项，两个日期都缺失时无法判断资源紧张时是压缩范围还是调整时间，需求即使来源清晰也不具备承接判断条件。可以先把条目保持“待澄清”状态，由项目经理向提出方补齐日期后再进入测算；确实无法给出日期的，应在阻断项记录中写明原因和补全期限。

技能要求写出来了，但暂时不知道有没有人可用，这条算澄清完成吗？

需求侧的技能要求写明后，来源与约束部分可以视为已澄清，但整条需求还要完成供需对照才算走完流程。做法是把技能要求归入技能族，用统一的可用人力口径计算缺口；缺口为正的条目连同技能族、缺口量和时间窗口一起移交容量规划环节。澄清阶段只记录“要什么人”，不在这里决定“怎么调人”。

清单条目放在表格里维护，和放到协作工具里跟踪，差别在哪里？

表格适合一次性核对，但状态更新和交接容易与实际情况脱节。把每条需求登记为工作项后，来源类别、唯一主来源、日期、技能族、人数与投入比例可以作为字段承载，澄清状态用少量取值表示，证据以附件或关联文档挂在条目上。ONES 支持通过工作数量和工时规模了解成员排期，并可按筛选与分组查看成员在不同项目的投入比重，适合承接这类逐条跟踪的条目；具体字段和状态流转按团队现有配置设置即可。