需求评审，是产品的一项常规工作，做得好的评审可以发挥团队的力量，把问题提前暴露，问题发现得越早，修复成本越低。
产品经理不要把评审作为舌战群儒的战役，在需求描述清楚之后应该广泛接受各个角色的建议，再综合考虑需求问题。
为避免需求评审会趋于形式而没有发挥其作用，应该做好三个事情，一是邀请需求相关方参加评审，包括产品负责人、技术负责人、测试人员、需求提出方，大的需求还需高层领导；二是提前发送会议通知并告知评审的重点；三是评审维度，即从哪些方向评审需求，具体如下：
一、需求层面
1. 场景是否覆盖全面
2. 是否与原功能/需求相互冲突或重复
二、业务流程
1. 流程是否走得通，是否合理，是否可进一步优化
2. 流程之间是否有冲突/矛盾
三、取数及逻辑
1. 需求的取数是否可行，算法是否合理
2. 算法是否完整及描述清楚
四、交互体验
1. 操作流程是否可独立完成
2. 是否有违背用户习惯
3. 交互反馈是否与用户期待相悖
4. 界面是否可读、可理解
5. 界面风格是否可被用户接受
五、需求说明书
1. 是否完整，可理解完整需求
2. 描述是否清晰，是否存在二义性
️六、技术可行
1. 在现有技术上，是否可行
2.需要接入新技术的话，投入成本有多少，是否可复用
以上作为需求评审会上的评审标准，其实在分析需求以及编写需求文档的工作中，也可从这些维度去自我校验需求是否完整与合理，校验完之后，被怼时也可以有理有据地与其交流。
- - - - - - - - - - - -
【一个小目标】40/365，记录产品经理之路的思考，做一个讲故事的人，讲一个好故事。
网友评论