需求评审开完却没人说得清谁该负责什么，往往是因为职责只停留在口头约定。本文以一次“会员积分兑换规则调整”的演示评审为例，给出一份可直接参照的职责分工表与评审记录，说明各角色在会前、会上、会后分别交什么、判断什么，并提炼换需求、换团队时的调整方法。示例为虚构情景，用于展示填写方式。
要点总览（TL;DR）
- 需求评审职责示例的核心是一张可填写的分工表：每个角色在会前交什么、会上判断什么、会后交付什么，都要落到具体字段。
- 示例按需求提出人、产品负责人、业务/领域代表、研发代表、测试代表、评审主持人、记录人七类角色分工，提出人管价值与验收口径，产品负责人管范围与条目维护。
- 评审结论固定为通过、有条件通过、退回补充、不通过四档，每条待办写明负责人、截止时间和验收方式，避免待办被标记完成但内容未落地。
- 换需求时按类型增减角色：涉及资金、权限、合规增加领域代表，跨团队需求增加依赖方接口人；小需求可合并主持与记录，但主持人角色建议保留。
- 本文范围限于需求评审；方案原型评审与研发阶段决策评审属于相邻主题，职责表不能替代评审结论的决策责任。
示例目标：这份职责分工要解决什么问题
这份示例要回答一个具体问题：一次需求评审里，谁负责讲清楚需求，谁负责判断值不值得做，谁负责判断做不做得成，谁负责判断验不验得了，以及结论由谁记录、待办由谁跟进。把这些写进一张表，评审就从“大家聊一聊”变成有输入、有判断、有交付物的协作动作。
示例针对三类常见问题设计。第一类是职责重叠：产品、业务、研发都在讲需求背景，真正该被追问的验收口径反而没人说清。第二类是结论无人记录：会上口头达成一致，会后找不到“通过了什么、附带了什么条件”。第三类是评审后无人跟进：待办散落在聊天记录里，没有负责人和截止时间，下次评审时才发现上次的修改还没落地。
需要说明，本文的“会员积分兑换规则调整”是演示情景，不是真实客户案例，也不附带任何量化成效。它的作用是让分工表的每一格都有具体内容可填，读者可以对照自己的需求替换名称和角色。
示例的输入与产出物如下，可作为组织评审前的准备清单：
| 类别 | 内容 | 责任角色 |
|---|---|---|
| 输入 | 需求说明（背景、目标、范围、验收口径初稿） | 需求提出人 |
| 输入 | 需求条目及优先级建议 | 产品负责人 |
| 输入 | 业务价值与影响面说明 | 业务/领域代表 |
| 输入 | 初步技术影响与依赖判断 | 研发代表 |
| 输入 | 可验证性关注点清单 | 测试代表 |
| 产出 | 评审结论（通过/有条件通过/退回补充/不通过） | 评审主持人 |
| 产出 | 评审记录（结论、争议点、决策依据） | 记录人 |
| 产出 | 待办事项表（事项、负责人、截止时间、验收方式） | 记录人整理，各负责人认领 |
完整示例：一次积分兑换规则调整的需求评审分工表
以下为已填写的示例。需求名称为“会员积分兑换规则调整”，演示情景设定为：现有积分兑换门槛与有效期规则需要调整，涉及会员端展示、兑换流程和后台配置。表中角色按一次中等规模需求评审配置，团队可按实际情况增减。
评审基本信息
| 字段 | 填写内容 |
|---|---|
| 需求名称 | 会员积分兑换规则调整 |
| 需求发起人 | 会员业务负责人（示例角色） |
| 产品负责人 | 会员产品经理（示例角色） |
| 评审时间 | 示例：需求说明提交后第3个工作日，时长60分钟 |
| 参与角色 | 需求提出人、产品负责人、业务/领域代表、研发代表、测试代表、评审主持人、记录人 |
| 评审材料 | 需求说明、兑换规则变更对照表、影响范围初判 |
逐角色职责分工表
| 角色 | 会前输入 | 会上动作 | 会后交付物 |
|---|---|---|---|
| 需求提出人（业务方） | 提交需求说明：调整背景、目标用户、期望效果、验收口径初稿 | 说明为什么调整、调整后业务上如何判断“做对了”；回答范围与优先级追问 | 补充或确认验收口径，确认业务侧验收人 |
| 产品负责人 | 整理需求条目，标注范围边界、与既有需求的关系、优先级建议 | 组织评审、主持需求讲解、明确本次讨论范围；记录争议点并推动收敛 | 更新需求条目（范围、优先级、验收口径），维护需求状态 |
| 业务/领域代表 | 准备受影响业务场景清单，如兑换入口、会员等级差异 | 判断业务价值与优先级是否成立，指出被遗漏的使用场景 | 确认受影响场景清单，参与业务验收 |
| 研发代表 | 给出初步实现路径、影响模块、外部依赖与工作量量级 | 评估实现可行性、影响范围与技术风险；对不明确处提出需要补充的信息 | 输出技术影响说明与依赖清单，认领技术侧待办 |
| 测试代表 | 梳理可验证性关注点：规则边界值、历史数据兼容、回滚场景 | 确认验收口径是否可测，指出无法验证或表述模糊的条目 | 输出测试关注点清单，认领验收口径澄清待办 |
| 评审主持人 | 确认材料齐备、参与人到齐，设定议程与时间盒 | 控制节奏，确保每个角色都给出判断；在争议无法当场收敛时明确升级路径 | 宣布评审结论，确认待办与负责人 |
| 记录人 | 准备评审记录模板与待办事项表 | 记录结论、争议点、决策依据与待办，会上复述确认 | 发布评审记录，跟踪待办状态直至关闭 |
评审结论与待办事项
结论字段建议固定为四类，避免“差不多通过”这类模糊表述：通过、有条件通过、退回补充、不通过。示例填写为“有条件通过”，条件与待办同时记录。
| 待办事项 | 负责人 | 截止时间 | 验收方式 |
|---|---|---|---|
| 补充积分有效期变更对历史积分的影响说明 | 需求提出人 | 评审后2个工作日 | 产品负责人确认说明覆盖存量积分场景 |
| 明确兑换门槛调整的后台配置项与灰度方式 | 研发代表 | 评审后3个工作日 | 技术影响说明中列出配置项清单 |
| 将验收口径改写为可测条目（含边界值） | 测试代表与产品负责人 | 评审后2个工作日 | 测试代表确认每条口径可设计用例 |
| 更新需求条目状态并附评审记录链接 | 产品负责人 | 评审当日 | 记录人核对条目与记录一致 |
逐项解释：每个角色为什么这样分工
分工表的价值在于每个字段都对应一个判断，而不是把参会人名单抄一遍。下面解释几处容易混淆的安排。
提出人与产品负责人的职责边界
提出人回答“为什么做、做成什么样算对”，产品负责人回答“这次做到哪、先做什么、需求条目怎么维护”。示例中，提出人负责背景与验收口径初稿，产品负责人负责范围边界与优先级。这样划分的原因是：业务价值判断需要贴近业务场景的人给出，而范围收敛和条目维护需要熟悉需求池的人持续负责。两者混在一起，常见结果是需求说明写成了业务愿望清单，缺少可执行的范围界定。
研发与测试的判断对象差异
研发代表判断“做不做得成、影响多大”，关注实现路径、影响模块、外部依赖和风险；测试代表判断“验不验得了”，关注验收口径是否具体、边界值是否覆盖、历史数据是否兼容。两者都在评估可行性，但对象不同：研发评估实现可行性，测试评估验证可行性。示例中把“验收口径改写为可测条目”单独列为待办，就是为了让测试的判断有落点，而不是会上点头、会后无从验证。
主持人、记录人与决策人的分离
主持人控制节奏和议程，记录人负责留痕，决策责任则由对应角色的负责人承担。分离的原因很实际：主持人若同时负责拍板，容易在时间压力下跳过争议；记录人若同时承担决策，记录就容易写成对自己有利的版本。示例中，结论由主持人宣布，但“有条件通过”的条件是否满足，由产品负责人和对应待办负责人确认，决策责任跟着事项走，而不是跟着会议走。
待办事项为什么要写验收方式
只有负责人和截止时间的待办，完成与否靠自觉；加上验收方式，关闭待办就有了可核对的依据。示例中每条待办都写明“谁确认、确认什么”，例如“测试代表确认每条口径可设计用例”。这一列看似多余，实际是防止待办被标记完成但内容并未真正落地。
评审记录与待办需要在团队日常使用的协作工具中留痕，才能被持续跟踪。以ONES为例，需求可以作为工作项维护范围、优先级与状态，评审记录可以沉淀在Wiki页面并与需求条目关联，待办则以工作项形式分配负责人和截止时间，后续状态变化在同一处可见。这样下次评审时，可以直接回看上次结论与待办关闭情况，而不必翻找聊天记录。
可迁移规律：换一个需求如何套用这份分工
这份分工表的结构可以复用，角色和字段需要按需求类型调整。可迁移的核心是三条原则：每个判断都有唯一负责角色；每个结论都有记录；每个待办都有负责人、截止时间和验收方式。
按需求类型增减参与角色
涉及资金、权限、合规的需求，应增加对应领域代表，并在结论字段中增加“需额外审批”的条件说明。涉及多系统集成的需求，研发代表之外应增加依赖方接口人，把外部依赖列为独立待办。纯展示类小需求可以合并角色，例如由产品负责人兼任记录人，但主持人角色建议保留，避免讨论失焦。
小需求与跨团队需求的分工差异
| 维度 | 小需求（单团队、影响面小） | 跨团队需求 |
|---|---|---|
| 参与角色 | 提出人、产品负责人、研发、测试，可兼任主持与记录 | 在上述基础上增加各依赖方代表与领域代表 |
| 评审材料 | 需求说明加验收口径即可 | 需附影响范围清单、依赖清单与排期约束 |
| 结论字段 | 通过/退回补充两档即可 | 建议保留四档，并记录条件与升级路径 |
| 待办跟踪 | 随需求条目一并关闭 | 按依赖方分列待办，分别确认 |
职责表与评审记录的维护节奏
职责表不需要每次评审重写，建议按团队固定一版基础角色表，评审前只调整本次参与角色与材料清单。评审记录则每次新建，评审结束后当日发布，待办状态在后续固定节点检查，例如下次评审开始前先过一遍上次待办的关闭情况。这样职责表保持稳定，记录保持连续，两者配合才能让分工真正被执行。
适用边界：哪些评审不属于本文范围
本文聚焦需求评审阶段的角色分工与记录填写，以下相邻场景不在展开范围。方案与原型评审关注交互方案、视觉稿和技术方案的评审职责，参与角色和判断对象与需求评审不同，应参考产品方案与原型评审相关主题。研发阶段评审与组织阶段决策机制关注阶段门禁、决策权限和资源投入判断，属于组织层面的决策安排，本文的职责表不覆盖这类决策责任。
还需要明确一点：职责分工表能厘清谁做什么、交什么，但不能替代评审结论的决策责任。表格填得再完整，如果结论无人拍板、条件无人确认，评审依然会流于形式。分工表的作用是让决策有依据、有记录、可追溯，决策本身仍由对应角色的负责人承担。
常见问题
需求评审中，需求提出人和产品负责人的职责怎么划清？
提出人回答“为什么做、做成什么样算对”，负责提交需求说明中的背景、目标用户、期望效果和验收口径初稿；产品负责人回答“这次做到哪、先做什么”，负责范围边界、优先级建议和需求条目的持续维护。划分依据是：业务价值判断需要贴近业务场景的人给出，范围收敛和条目维护需要熟悉需求池的人持续负责。两者混在一起，需求说明容易写成业务愿望清单，缺少可执行的范围界定。
评审会上争议无法当场收敛时，主持人应该怎么处理？
主持人的职责是控制节奏和议程，在争议无法当场收敛时明确升级路径，而不是代替业务或技术负责人拍板。可以按这个顺序处理：先确认争议属于价值判断还是实现判断，交回对应角色给出结论；仍无法收敛的，记录争议点与双方依据，指定升级对象和回复时间，作为待办写入评审记录。结论字段此时可填“退回补充”或“有条件通过”，条件与待办同时记录，避免会议无限延长。
小团队人手少，评审角色可以合并吗？
可以合并，但要保留关键判断的落点。单团队、影响面小的小需求，产品负责人可以兼任记录人，研发或测试代表可以兼任主持人；建议保留主持人角色，避免讨论失焦。合并时注意两点：一是提出人与产品负责人的判断对象不同，尽量由不同人承担；二是记录人兼任其他角色时，结论与待办仍要在会上复述确认，防止记录写成单方版本。跨团队需求不建议合并，依赖方代表和领域代表应单独参与。
评审记录和待办用什么方式留痕，下次评审怎么衔接？
评审记录应在评审结束后当日发布，内容包含结论、争议点、决策依据和待办事项表；待办逐条写明负责人、截止时间和验收方式。下次评审开始前，先过一遍上次待办的关闭情况，确认条件是否满足，再进入新需求的讨论。留痕位置选择团队日常使用的协作工具即可，关键是记录与需求条目关联、待办状态在同一处可见。以ONES为例，需求可作为工作项维护范围、优先级与状态，评审记录可沉淀在Wiki页面并与需求条目关联，待办以工作项形式分配负责人和截止时间，后续状态变化在同一处可见。
需求评审和方案原型评审、阶段决策评审的边界在哪里？
需求评审判断的是“做不做、做成什么样算对”，关注需求背景、范围、优先级和验收口径，产出评审结论与待办。方案原型评审关注交互方案、视觉稿和技术方案的评审职责，参与角色和判断对象不同。研发阶段评审与组织阶段决策机制关注阶段门禁、决策权限和资源投入判断，属于组织层面的决策安排。三类评审可以衔接，但职责表各自独立，本文的分工表不覆盖后两类的决策责任。
