需求评审职责可以按“谁提、谁评、谁定、谁记、谁跟”来划分：提出方说明业务目标与验收口径，产品负责人组织评审并维护需求内容，业务与领域代表判断价值与场景，研发与测试代表判断可实现性与可验证性，主持人收敛结论，记录人留档并跟踪。本文只讨论需求评审本身的职责与机制，方案原型评审、研发阶段评审不在范围内。评审材料、结论与待办需要承载和追踪时，可以放在ONES的工作项与文档中统一管理。
要点总览（TL;DR）
- 需求评审职责按决策权、专业判断、执行落地三层划分，再落到提出方、产品负责人、业务与领域代表、研发与测试代表、主持人、记录人等角色，避免把职责绑定在固定岗位名称上。
- 每个角色按“输入—动作—输出—完成标志”描述，主持人在会末逐项确认结论，记录人把结论转成可跟踪条目，两者衔接决定机制能否落地。
- 执行按评审前、评审中、评审后三阶段推进：材料缺项不进入议程，议题按背景目标到可验证性的顺序收敛，修改后再评需明确回评触发条件。
- 结论分为通过、修改后再评、暂缓、不通过四类，每类指定判定责任人与时限，需求状态与评审结论保持同步。
- 检查落地看职责覆盖、材料齐备、结论明确、跟踪闭环四类证据，任一类持续不通过先修正对应环节再扩大评审范围。
需求评审职责按什么逻辑划分
职责划分的起点是评审中需要做出的判断类型，岗位名称只是承载这些判断的组织形式。同一个需求，在不同团队里可能由产品经理、业务分析师或项目负责人发起，但“说明业务目标”“判断技术可行性”“拍板结论”这些动作必须有人认领。按判断类型分层，比按岗位列表分工更稳定，人员调整时也容易找到替代者。
可以分成三层。第一层是决策权，负责对需求是否进入后续环节作出最终判断，并对结论负责；第二层是专业判断，由业务、领域、研发、测试等代表从各自专业角度给出意见和风险；第三层是执行落地，负责组织会议、记录结论、分发材料、跟踪修改与关闭。三层职责的输入与输出各不相同，混在一起容易出现“人人有意见、无人对结论负责”的情况。
| 职责层 | 核心问题 | 主要输入 | 主要输出 |
|---|---|---|---|
| 决策权 | 这个需求是否通过、何时再评 | 各方评审意见、风险清单、资源约束 | 明确的评审结论与责任人 |
| 专业判断 | 价值是否成立、能否实现、能否验证 | 需求说明、业务背景、技术方案要点、验收口径 | 分角色的评审意见与遗留问题 |
| 执行落地 | 评审是否按计划发生、结论是否被跟进 | 评审材料、会议安排、上一轮结论 | 评审记录、待办事项、状态更新 |
划分依据主要看需求类型与影响范围。涉及跨部门流程调整的需求，业务代表和领域专家的判断权重更高；涉及系统改造或外部接口的需求，研发与测试的意见需要前置；影响范围小、边界清晰的需求，可以由较少角色完成评审，但仍要保留结论责任人和记录人。把职责绑定在固定岗位名称上，遇到兼职或轮岗时机制就容易失效。
各角色在需求评审中做什么、交什么
角色清单按“输入—动作—输出—完成标志”描述，便于逐项核对。以下角色可以根据团队规模合并，但合并后对应的动作和交付物仍需有人承担。
| 角色 | 输入材料 | 核心动作 | 交付物 | 完成标志 |
|---|---|---|---|---|
| 需求提出方 | 业务背景、目标、初步验收口径 | 说明需求来源、要解决的问题、期望结果与边界 | 需求说明与验收口径初稿 | 评审前材料齐全，关键问题可被追问 |
| 产品负责人 | 需求说明、历史需求记录、相关文档 | 组织评审、维护需求内容、汇总修改意见 | 评审版本的需求文档 | 需求内容与评审结论一致，修改有记录 |
| 业务代表 | 业务流程说明、使用场景 | 判断业务价值、场景合理性与优先级 | 业务侧评审意见 | 价值判断与场景边界有明确表述 |
| 领域代表 | 领域规则、合规或专业约束 | 判断需求是否符合领域规则与既有约定 | 领域约束与风险提示 | 约束条件写入需求或列为遗留问题 |
| 研发代表 | 需求说明、现有系统情况 | 判断技术可行性、影响范围与实现成本量级 | 可行性意见与风险清单 | 实现路径或阻塞点有明确结论 |
| 测试代表 | 验收口径、需求边界 | 判断需求是否可验证、验收标准是否可执行 | 可测试性意见与验收补充 | 验收口径可被转化为检查项 |
| 评审主持人 | 议程、各方意见、时间安排 | 控制议题顺序与时间，收敛分歧，形成结论 | 评审结论与待办分配 | 每项议题有结论、责任人和时限 |
| 记录人 | 会议过程、结论、待办 | 记录意见、结论与修改项，分发并跟踪 | 评审记录与跟踪清单 | 记录可查，待办进入跟踪状态 |
主持人与记录人的衔接是机制落地的关键。主持人负责在会议结束前逐项确认结论，记录人负责把结论转成可跟踪的条目，包括修改内容、责任人和完成时限。两者之间如果缺少交接，会议上的口头共识很容易在会后丢失。评审记录应包含需求版本、参与角色、结论类型、遗留问题和下次评审条件，方便后续回评时对照。
在ONES中，需求说明、评审记录可以作为文档沉淀，评审结论与修改待办可以转为工作项，由责任人更新状态。这样记录人与跟踪人面对的是同一份可追踪的内容，减少会后另行整理和反复确认的成本。
评审前、评审中、评审后各阶段怎么执行
阶段执行的重点是让每个阶段有明确的输入、动作、输出和完成标志，避免评审变成临时召集的讨论会。
评审前：材料准备与准入检查
输入是需求提出方提交的需求说明。产品负责人检查材料是否包含业务目标、需求边界、初步验收口径和影响范围，缺项的需求退回补充，不进入评审议程。主持人确认参与角色与需求类型匹配，提前分发材料，让评审人带着问题参会。完成标志是材料齐备、参与角色确认、议程和时间已通知。
评审中：议题顺序与结论形成
建议按“背景与目标—业务价值与场景—领域约束—技术可行性与影响范围—可验证性—结论”的顺序推进。先确认要解决的问题，再讨论方案细节，可以减少在细枝末节上消耗时间。主持人控制每个议题的时间，遇到分歧时区分“需要当场决定”和“需要补充信息后再定”两类，后者转为待办而不是无限讨论。会议结束前逐项确认结论类型、责任人和时限，完成标志是每项议题都有明确结论。
评审后：结论分发、修改回评与关闭
记录人在会后分发评审记录，产品负责人按结论修改需求内容，研发与测试代表在修改后确认关键问题是否解决。修改后再评的需求需要明确回评触发条件，例如验收口径补充完成或技术阻塞点有结论。需求进入后续环节或明确不通过后，由记录人更新状态并关闭本次评审。完成标志是结论已分发、修改项已关闭或转入下一轮、需求状态与结论一致。
评审结论怎么分类与跟踪
结论分类的作用是让每个需求在评审后都有明确去向，而不是停留在“再讨论一下”。建议使用四类结论，每类指定判定责任人与时限。
| 结论类型 | 判定标准 | 判定责任人 | 后续动作与时限 |
|---|---|---|---|
| 通过 | 价值、场景、可行性与可验证性均有明确判断，遗留问题不影响进入后续环节 | 主持人汇总，产品负责人确认 | 需求状态更新为已通过，遗留问题转为待办并设定时限 |
| 修改后再评 | 核心方向成立，但材料缺项或关键问题需要补充 | 主持人提出，产品负责人认领修改 | 明确修改内容、责任人和回评时间，修改完成后按约定回评 |
| 暂缓 | 需求本身成立，但当前资源、依赖或优先级不支持推进 | 主持人会同业务代表与产品负责人判定 | 记录暂缓原因与重新评估条件，由产品负责人定期复查 |
| 不通过 | 价值不成立、场景不合理或存在无法接受的约束 | 主持人汇总，产品负责人确认 | 记录不通过理由，需求关闭或退回提出方重新论证 |
结论变更需要有记录。需求在修改后回评时，应引用上一轮结论和遗留问题，避免重复讨论已经确认的内容。需求状态与评审结论保持同步，状态变更由记录人或产品负责人执行，其他角色以评审记录为准。暂缓的需求重新进入评审时，按新需求对待，但保留历史结论作为参考。
一个需求评审分工的示例
以下为演示情景，用于说明职责如何落到一次具体评审中，不对应真实客户案例。
某团队收到一个需求：在现有审批流程中增加“超时自动提醒”能力。需求提出方为业务运营人员，评审参与角色包括产品负责人、业务代表、研发代表、测试代表、主持人和记录人。
评审前，需求提出方提交业务背景：审批平均停留时间偏长，希望减少人工催办。产品负责人检查材料，发现验收口径只写了“提醒及时”，退回补充为“超时后多长时间触发、提醒渠道、重复提醒规则”。补充完成后，主持人确认研发与测试代表参会，提前分发材料。
评审中，业务代表确认场景成立，但提出不同审批类型的超时阈值可能不同；研发代表判断提醒能力可以复用现有消息通道，但需要确认触发频率对系统的影响；测试代表提出需要明确提醒失败时的处理方式。主持人按议题顺序收敛，将“阈值是否可配置”列为需要业务与产品补充的问题，将“提醒频率上限”列为研发补充项，其余问题当场形成意见。
结论为“修改后再评”：产品负责人补充阈值配置规则与验收口径，研发代表补充频率上限的技术约束，约定三个工作日后回评。记录人将修改项转为待办，分配责任人和时限，并在回评时对照上一轮遗留问题逐项确认。回评通过后，需求状态更新，遗留的提醒失败处理方式转为后续设计待办。
这个示例中，每个角色都有明确的输入和交付物，主持人的收敛动作与记录人的跟踪动作前后衔接，结论类型决定了后续路径。评审材料与待办在ONES中分别以文档和工作项承载时，回评时可以直接对照上一轮记录，减少信息散落。
怎么检查评审职责是否真正落地
检查机制是否有效，可以按职责覆盖、材料齐备、结论明确、跟踪闭环四类逐项核对。每项检查都应有证据来源和负责人，检查结果不通过时应有阻断条件。
| 检查类别 | 检查项 | 证据来源 | 负责人 | 不通过时的处理 |
|---|---|---|---|---|
| 职责覆盖 | 每次评审都有提出方、产品负责人、业务或领域代表、研发代表、测试代表、主持人、记录人，或合并后对应动作有人承担 | 评审记录中的参与角色与分工 | 主持人 | 补齐角色或明确动作承接人后再评审 |
| 材料齐备 | 需求说明包含业务目标、边界、验收口径和影响范围 | 评审前提交的需求文档 | 产品负责人 | 材料缺项的需求不进入议程 |
| 结论明确 | 每项议题有结论类型、责任人和时限 | 评审记录与结论清单 | 主持人 | 结论不明确的需求不更新状态 |
| 跟踪闭环 | 修改项、暂缓复查项、遗留问题均有责任人和完成状态 | 待办清单与需求状态记录 | 记录人 | 超期未关闭的待办升级到产品负责人处理 |
检查频率可以按评审批次或固定周期执行，重点看证据是否可查，而不是只看会议是否召开。职责覆盖检查关注动作是否有人承担，材料齐备检查关注评审是否有判断依据，结论明确检查关注会议是否产生可执行结果，跟踪闭环检查关注结论是否真正被落实。四类检查中任何一类持续不通过，都应先修正对应环节，再扩大评审范围。
当团队把评审记录、结论和待办放在同一套工作项与文档体系中管理时，检查可以直接基于状态和记录完成，减少额外收集证据的工作。ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行后续操作，结果可保存为工作项或Wiki页面，适合在评审记录查询和待办整理环节提供辅助；评审流程本身仍由团队按上述职责与规则运行。
常见问题
小团队人手有限，评审角色可以合并吗？
可以合并，但合并后对应的动作和交付物仍需有人承担。例如产品负责人同时担任主持人时，会议中要明确区分“组织材料”和“收敛结论”两个动作，并在评审记录中写明由谁执行。研发与测试代表由同一人兼任时，可行性判断和可验证性判断仍要分别给出意见，避免只讨论实现路径而遗漏验收口径。
合并的底线是保留结论责任人和记录人两个角色，否则评审容易停留在讨论层面，会后无人对结论负责、无人跟踪修改项。
需求提出方不在评审现场，评审还能进行吗？
可以，但前提是需求说明已包含业务目标、需求边界、初步验收口径和影响范围，且提出方指定了能回答业务问题的代理人。评审中如果出现材料无法回答的关键问题，主持人应将其列为待补充项，而不是由参会者替提出方推测业务意图。
涉及业务价值判断的议题，建议在提出方或代理人到场后再形成结论；仅涉及技术可行性和可验证性的议题，可以在提出方缺席时先行评审，结论中注明待业务确认的部分。
“修改后再评”和“暂缓”在实际操作中怎么区分？
两者的区别在于阻塞来源。“修改后再评”是需求方向成立，但材料缺项或关键问题需要补充，阻塞点在需求内容本身，由产品负责人认领修改并约定回评时间。“暂缓”是需求本身成立，但当前资源、依赖或优先级不支持推进，阻塞点在外部条件，需要记录暂缓原因和重新评估条件。
操作上，修改后再评的需求有明确的回评时间点，到期按约定回评；暂缓的需求由产品负责人定期复查，条件满足后按新需求重新进入评审，历史结论作为参考。
评审结论形成后，需求内容又被修改了怎么办？
修改需要与结论关联。产品负责人修改需求内容时，应引用上一轮评审记录中的遗留问题和结论类型，逐项说明修改是否回应了对应问题。如果修改涉及价值判断、技术可行性或验收口径的实质变化，应触发回评，而不是直接更新状态。
记录人负责核对需求状态与最新结论是否一致，状态变更以评审记录为准。这样在后续追溯时，可以看到每次修改对应哪一轮结论，避免结论与需求内容脱节。
怎么判断评审职责机制是否在有效运行，而不是走形式？
看证据，不看会议是否召开。职责覆盖看评审记录中的参与角色与分工是否完整；材料齐备看评审前提交的需求文档是否包含业务目标、边界、验收口径和影响范围；结论明确看每项议题是否有结论类型、责任人和时限；跟踪闭环看修改项和遗留问题是否有责任人和完成状态。
四类检查中任何一类持续不通过，应先修正对应环节，例如材料缺项的需求不进入议程、结论不明确的需求不更新状态，再考虑扩大评审范围或调整角色设置。
