需求评审的标准

需求评审，是产品的一项常规工作，做得好的评审可以发挥团队的力量，把问题提前暴露，问题发现得越早，修复成本越低。

产品经理不要把评审作为舌战群儒的战役，在需求描述清楚之后应该广泛接受各个角色的建议，再综合考虑需求问题。

为避免需求评审会趋于形式而没有发挥其作用，应该做好三个事情，一是邀请需求相关方参加评审，包括产品负责人、技术负责人、测试人员、需求提出方，大的需求还需高层领导；二是提前发送会议通知并告知评审的重点；三是评审维度，即从哪些方向评审需求，具体如下：

一、需求层面

1. 场景是否覆盖全面

2. 是否与原功能/需求相互冲突或重复

二、业务流程

1. 流程是否走得通，是否合理，是否可进一步优化

2. 流程之间是否有冲突/矛盾

三、取数及逻辑

1. 需求的取数是否可行，算法是否合理

2. 算法是否完整及描述清楚

四、交互体验

1. 操作流程是否可独立完成

2. 是否有违背用户习惯

3. 交互反馈是否与用户期待相悖

4. 界面是否可读、可理解

5. 界面风格是否可被用户接受

五、需求说明书

1. 是否完整，可理解完整需求

2. 描述是否清晰，是否存在二义性

️六、技术可行

1. 在现有技术上，是否可行

2.需要接入新技术的话，投入成本有多少，是否可复用

以上作为需求评审会上的评审标准，其实在分析需求以及编写需求文档的工作中，也可从这些维度去自我校验需求是否完整与合理，校验完之后，被怼时也可以有理有据地与其交流。

- - - - - - - - - - - -

【一个小目标】40/365，记录产品经理之路的思考，做一个讲故事的人，讲一个好故事。