三、需求评审关键要点

需求评审，就是产品经理将收集、整理的需求，通过向团队成员（项目经理、研发、测试）进行阐述、说明或者演示，使团队成员对需求的理解保持一致，从而使产品达到预期效果。

一、需求评审的重要性

实际项目中，我们常见的几类与需求有关的问题：

需求开发的过程中发现有逻辑不通、逻辑遗漏，研发不知道该如何继续实现开发前评估工作量2周，实际开发却发现越做越多，工作量远超计划测试的过程中提交的bug有争议，测试认为是bug，开发认为需求设计如此开发测试都很顺利，但交付后，运营不满意、客户不满意，认为没有满足自己的需求

需求评审的好处：

评审过程本身也是一个知识传递过程，评审人员与需求分析人员一起讨论用户需求，这有助与评审人员获得用户需求的前期认识，确保对需求理解的一致性评审过程中，沟通细节，可能发现不明确的或者遗漏的需求各方思考的角度不同，可能可以产出更合理或更有建设性的解决方案

二、如何进行需求评审

需求评审流程

1、范围评审

评审目标：明确需求范围，要做什么，不做什么文档准备：需求场景、需求清单、客户调研报告、竞品调研报告等参会人员：产品、需求方（业务、销售、售后、老板等）评审产出：达成一致的需求范围清单

2、低保真评审

评审目标：初步明确大致的样式交互及业务逻辑方案文档准备：低保真稿（包含核心业务逻辑说明及核心页面交互）参会人员：产品、需求方、研发（前端、后端）、UI/UE评审产出：就核心业务逻辑及核心页面交互达成一致

这个流程可视团队情况、需求复杂度、需求量决定是否进行。

3、方案评审（高保真）

评审目标：关注粒度更细的方案细节，需求、逻辑需覆盖全面文档准备：包含全部业务逻辑说明、页面样式交互说明，是可以直接开始研发的终稿参会人员：产品、研发（前端、测试）、UI/UE评审产出：理想状态下，就全部业务逻辑和页面交互达成一致

会议管理

会议前

明确本次会议的目的、提前确定与会人员、与会时间、会议时长、会议室预约、会议材料准备。

在评审前，需先把需求文档、原型图、流程图等材料提前邮件给会议相关方，各方查看后标注评审意见，方便会议上提出讨论，提高评审的效率。

目的：让团队所有人员对需求达成一致与会人：项目经理、产品、研发、测试、UI设计、运营、需求方，尽可能召集与项目有关的所有人员，各个领域的负责人必须到场与会时间：提前协调各方合适的时间会议时长：最好控制在1个小时以内，时间太短无法把需求说清楚，时间太长容易疲劳、注意力不集中会议室预约：根据参会人数、以及演示方式预订符合自己需要的会议室会议材料：提前准备好项目概要、需求文档、原型图、流程图、项目排期计划并提前发送给相关与会人

会议中

评审流程：

需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义

澄清需求时要注意以下几点：

> 在进行需求澄清前不要忙着讲解用户操作流程，演示原型图，首先我们应该对需求的价值进行澄清，然后澄清需求的背景以及需求想要实现什么目标、解决什么问题，这样的话大家对需求的理解才能更深刻，才不会在后期质疑是否需求的必要性。

> 尽量用举例子、讲故事的方式来澄清需求。在讲解用户操作时可以结合具体的业务场景。

> 节奏把控，避免在一个问题上讨论太久，一时半会儿没有结论的问题需要记录下来，后续再专门安排时间讨论；避免讨论溢出范围的问题

> 记录会上提出的所有问题

> 与每一块的负责人确认排期时间是否有疑义

> 防止突发事件，预留一定时间

会议后

输出会议纪要，一般分为3部分：待讨论、待完善、已确认。

待讨论：指会上的遗留问题待完善：指会上确认要改的问题，后续要完善在文档中已确认：指会上讨论得出要做/不做的结论的点

会议纪要需要发送给参会的所有人员，待完善的部分待补充后视具体情况再组织二次评审，待讨论问题记录待办工作，择期组织会议进行讨论。

三、需求评审关键要点

需求层面

正确性

是否清晰准确的描述了要实现的功能需求描述是否无二义性，例如存在模糊描述（同已有逻辑）

完整性

场景覆盖是否全面（正常场景、异常场景）是否存在隐藏的需求

合理性

是否与原功能/需求相互冲突或矛盾

业务流程

是否有完整清晰的流程图流程是否能走得通，是否合理流程之间是否存在冲突/矛盾

交互体验

交互设计是否完整用户体验是否合理，是否有违背用户习惯用户操作流程是否可独立完成界面是否可读、可理解界面风格是否可别用户接受

技术可行性

需求中的功能是否能通过现有技术实现要接入新技术的话，投入成本有多少，是否可复用

可测试性

是否每项需求均有验证的标准及方法，可通过设计测试用例或者其他验证方法来进行测试

可交付性

评估是否能在规定时间内进行交付交付成本是否过高，例如部署、迁移

分配优先级

是否对所有需求都进行了优先级分配；若所有需求都一样重要，那么在项目管理过程中便无法灵活管控资源及进度