需求优先级评审要回答的核心问题是：在资源有限的前提下，哪些需求先做、哪些后做、哪些暂缓。支撑这个判断的依据通常包括六类：业务目标与战略贡献、用户与客户价值证据、成本与投入估算、风险与合规约束、依赖与时间窗口、需求成熟度与证据完整度。本文按“依据清单—操作步骤—角色分工—完整示例—完成检查”的顺序展开，给出可直接套用的字段表、流程和核对清单。评审依据需要落在可填写的字段和可留存的记录上，ONES 可用于承载需求条目、评审结论与决策理由，具体能力以实际配置为准。
要点总览（TL;DR）
- 需求优先级评审的依据围绕需求对象组织，通常包括六类：业务目标与战略贡献、用户与客户价值证据、成本与投入估算、风险与合规约束、依赖与时间窗口、需求成熟度与证据完整度。
- 评审前先确定统一的依据字段表，明确每类依据对应的字段、证据形式和提供角色；目标贡献、风险合规、依赖与时间窗口缺失时，需求不具备评审条件。
- 评审按四步执行：提出人提交依据、会前预审标注待补、会上按统一口径逐项评估并记录分歧、形成排序结论与可追溯的决策理由。
- 角色分工固定为需求提出人、产品负责人、业务方、技术负责人和记录人，记录人负责留存分歧与待补证据清单，保证结论可追溯。
- 评审结束后用检查清单核对依据完整性、证据可核对性、结论可追溯性和待补跟进；目标贡献无法对应、风险未评估、成本缺失时应暂缓排序。
评审前先定依据：六类输入与字段表
评审会开得是否有效，很大程度上取决于会前依据是否齐备。建议在评审前先确定一张统一的依据字段表，让每个需求都按同一口径提交信息，避免会上临时补充、凭印象争论。六类依据分别回答不同问题：值不值得做、对谁有价值、要花多少、有没有硬约束、什么时候能做、信息够不够支撑判断。
| 依据类别 | 对应字段 | 证据形式 | 提供角色 | 必填/选填 |
|---|---|---|---|---|
| 目标贡献 | 支撑的业务目标或关键结果、预期影响指标 | 目标编号、指标基线值与目标值 | 需求提出人、业务方 | 必填 |
| 用户价值 | 受影响用户或客户范围、问题频次、价值证据 | 用户反馈记录、访谈纪要、数据截图、工单统计 | 需求提出人 | 必填（可标注待补） |
| 成本投入 | 研发人力估算、涉及系统、外部采购或资源占用 | 技术方案初稿、工作量估算区间 | 技术负责人 | 必填 |
| 风险与合规 | 安全、隐私、合规、线上稳定性影响 | 风险说明、合规条款引用、评估结论 | 技术负责人、合规或安全角色 | 必填（无风险需明确写“无”） |
| 依赖与时间窗口 | 前置需求、外部依赖、截止时间或窗口期 | 依赖清单、合同或活动时间表 | 需求提出人、技术负责人 | 必填 |
| 需求成熟度 | 需求描述完整度、方案清晰度、验收标准 | 需求文档、原型、验收条件 | 需求提出人、产品负责人 | 必填 |
字段设计上有两点需要提前约定。第一，明确哪些字段允许标注“待补”：用户价值证据和成本估算在早期需求中常常不完整，可以允许标注待补并写明补齐时间，但目标贡献、风险与合规、依赖与时间窗口这三类直接影响排序结论，缺失时应视为不具备评审条件。第二，每个字段都要写明证据形式，例如“用户反馈记录”要具体到来源和数量，避免只写“用户很需要”这类无法核对的描述。
字段表确定后，应作为需求提交模板固定下来，新需求进入评审池时即按此填写。这样评审会上的讨论集中在判断分歧上，而不是反复追问背景信息。
评审操作步骤：从收集依据到形成排序
依据齐备之后，评审本身可以拆成四个动作，每个动作都有明确的输入、输出和完成标志，便于组织者控制节奏。
步骤一：需求提出人按字段表提交依据
输入是需求描述和已有材料，动作是逐项填写六类字段并附上证据，输出是一份完整的评审提交单。完成标志是必填字段全部有内容，允许待补的字段已标注补齐时间。这一步由需求提出人独立完成，产品负责人只在提交后做形式检查。
步骤二：评审前预审，剔除或标注证据缺失项
输入是全部提交单，动作是由产品负责人和技术负责人做一轮预审，检查证据是否可核对、成本估算是否有依据、风险项是否遗漏。输出是进入正式评审的需求清单，以及一份待补证据清单。完成标志是每个需求都被标记为“可评审”“待补后评审”或“退回补充”三种状态之一。预审的作用是把明显不成熟的需求挡在正式会议之外，节省集体讨论时间。
步骤三：评审会上按统一口径逐项评估并记录分歧
输入是可评审需求清单，动作是参会角色按六类依据逐项确认，对存在分歧的项当场记录分歧点和各方理由，而不是强行达成一致。输出是每个需求的评估记录，包括各项依据的结论和未解决的分歧。完成标志是所有可评审需求都完成了逐项评估，分歧项均有记录。统一口径指事先约定的评估方式，例如对目标贡献和价值采用高、中、低三档判断，对成本采用人力区间估算，避免不同需求用不同标准比较。
步骤四：形成排序结论与决策理由
输入是评估记录，动作是由产品负责人汇总形成排序，并为每个需求的位次写明理由，特别是被排后或暂缓的需求要说明是哪类依据起了决定作用。输出是一份排序结论和决策理由记录。完成标志是每个需求都有明确结论（本期做、下期做、暂缓、不做）和对应理由，且理由能追溯到具体依据字段。
角色分工与各角色交付物
评审质量取决于各角色是否在正确环节提供了正确信息。把职责和交付物固定下来，可以避免评审变成产品负责人一人拍板，也能防止技术评估滞后到开发阶段才暴露。
| 角色 | 主要职责 | 交付物 | 参与环节 |
|---|---|---|---|
| 需求提出人 | 说明需求背景，提供价值证据与初步成本信息 | 完整评审提交单、证据材料 | 提交、答疑 |
| 产品负责人 | 主持评审，维护评估口径和排序规则 | 评审议程、排序结论、决策理由 | 预审、主持、结论 |
| 业务方 | 确认需求与业务目标的对应关系及优先级期望 | 目标贡献确认、优先级期望说明 | 提交、评审 |
| 技术负责人 | 评估实现成本、技术依赖与风险 | 成本估算、依赖清单、风险评估 | 预审、评审 |
| 记录人 | 留存评估过程、分歧与待补事项 | 评审记录、待补证据清单及责任人 | 评审全程 |
其中记录人常被忽略，但对结论可追溯至关重要。记录人不需要参与判断，只需保证每个结论都能对应到会上确认过的依据，以及每个待补项都有责任人和时限。产品负责人维护口径的职责也包括在评审前确认本次使用的评估档位和排序规则没有临时变动，否则不同批次的需求之间无法比较。
当评审依据需要长期留存和跨批次复用时，可以把需求条目、字段内容和评审结论放在同一套协作工具中管理。ONES 可承载需求条目与评审记录，ONES Assistant 智能助手能够基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，将结果保存为工作项或 Wiki 页面，便于把评审结论与需求条目关联留存；具体字段与评审流程的配置方式以团队实际使用为准。
示例：一次需求优先级评审的完整依据与结论
以下为演示情景，用于说明依据如何填写并影响排序，不代表真实客户案例。
某团队本季度有三个候选需求：A 为结算页面增加发票下载入口；B 为后台增加批量导入功能；C 为移动端增加消息推送。业务目标是提升续费转化和降低客服工单量。
| 依据 | 需求A 发票下载 | 需求B 批量导入 | 需求C 消息推送 |
|---|---|---|---|
| 目标贡献 | 降低客服工单量，预计减少相关工单约三成 | 提升运营录入效率，支撑续费活动上线 | 提升用户活跃，与当前续费目标关联较弱 |
| 用户价值 | 近两个月相关工单 40 余条，有明确记录 | 运营团队反馈，缺少量化统计，标注待补 | 用户调研提及，样本较少 |
| 成本投入 | 约 5 人日，涉及结算模块 | 约 15 人日，涉及导入校验与权限 | 约 10 人日，涉及推送通道对接 |
| 风险与合规 | 涉及发票信息，需确认权限控制 | 无特殊风险 | 涉及消息授权与退订合规 |
| 依赖与时间窗口 | 无前置依赖 | 依赖续费活动排期，窗口在两周后 | 无硬性窗口 |
| 需求成熟度 | 验收标准清晰 | 方案初稿完成，验收标准待补 | 方案未定，待补 |
评审中的主要分歧出现在需求B：业务方认为它直接支撑续费活动，应排第一；技术负责人指出其用户价值证据尚未量化，且验收标准不完整。处理方式是记录分歧，将需求B标记为“待补证据后评审”，并约定由需求提出人在三个工作日内补充运营侧的效率数据。需求C因方案未定且与当前目标关联较弱，结论为暂缓。最终排序为：需求A 本期做，理由是工单证据充分、成本低、无前置依赖；需求B 补证据后进入下一轮评审；需求C 暂缓，待方案明确后重新提交。每个结论都对应到具体依据字段，后续可追溯。
完成检查：评审依据是否齐全、结论是否可追溯
评审结束后，可用以下清单逐项核对本次评审是否达到可交付标准。
- 依据完整性：所有进入评审的需求，六类字段均有内容；标注待补的字段写明了补齐时间和责任人；风险项即使为“无”也有明确记录。
- 证据可核对：用户价值、成本估算等关键字段附有可查证的来源，而非仅凭描述。
- 结论可追溯：每个需求的排序结论都能对应到具体依据字段，被排后或暂缓的需求写明了起决定作用的依据。
- 分歧有记录：会上未达成一致的项已记录分歧点和各方理由，并指定了后续处理方式。
- 待补跟进：待补证据清单已明确责任人和时限，并约定在下次评审前复核。
出现以下情况时，建议暂缓对该需求排序，而不是带着缺口进入结论：目标贡献无法对应到任何业务目标；风险与合规项未做评估；成本估算完全缺失；需求描述不足以判断验收标准。暂缓不等于否决，补齐依据后可重新进入评审。把这套字段表、步骤和检查清单固定为团队惯例后，每次评审的准备时间和争议都会明显减少，排序结论也更容易在后续复盘中解释清楚。
常见问题
需求优先级评审中，哪些依据缺失时必须暂缓排序？
目标贡献、风险与合规、依赖与时间窗口这三类依据直接影响排序结论，缺失时应视为不具备评审条件，暂缓排序。用户价值证据和成本估算在早期需求中常常不完整，可以标注待补并写明补齐时间，但补齐后应重新进入评审。暂缓不等于否决，补齐依据后可再次提交。
评审会上出现分歧时，应该当场表决还是记录后处理？
建议记录分歧点和各方理由，而不是当场强行达成一致。分歧本身反映了依据上的信息缺口，例如业务方看重目标贡献、技术负责人关注成本与验收标准。记录分歧后，指定补充证据的责任人和时限，在下一轮评审中复核。这样排序结论保留了解释空间，后续复盘时也能说明当时为何这样排。
需求提出人和产品负责人在评审依据准备上如何分工？
需求提出人负责按字段表逐项填写六类依据并附上证据，包括用户反馈记录、工单统计、目标指标等可核对材料。产品负责人负责维护评估口径和排序规则，在提交后做形式检查，并主持评审。两者分工的关键是：提出人提供事实材料，产品负责人保证不同需求用同一标准比较。
评审依据和决策理由如何留存，方便后续复盘？
可以把需求条目、字段内容和评审结论放在同一套协作工具中管理，让每个排序结论都能对应到具体依据字段。ONES 可承载需求条目与评审记录，ONES Assistant 智能助手能够基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，将结果保存为工作项或 Wiki 页面，便于把评审结论与需求条目关联留存；具体字段与评审流程的配置方式以团队实际使用为准。
评审依据字段表需要每次评审前重新设计吗？
不需要。字段表确定后应作为需求提交模板固定下来，新需求进入评审池时即按此填写。每次评审前产品负责人只需确认本次使用的评估档位和排序规则没有临时变动，否则不同批次的需求之间无法比较。字段表本身可以按团队实际情况调整，但调整应统一生效，避免同一批次内标准不一致。
