产品的需求评审

什么是需求评审？

需求评审就相当于产品经理的一次考试，做过产品经理的人都知道这有多可怕。它需要产品经理向大家阐述自己的设计结果，这时候应该是有相对完整的原型设计，需要一步一步讲清楚自己的思路，接受大家的拷问，来获得大家的认可。在这个环节，如果不能让大家理解你的设计，那么就会导致后面同事的工作无法展开。所以这是每一个产品经理必备的一个工作。

需求评审需要做什么？

需求评审，需要统一思想，明确需求，确定实现过程的会议。需要与相关方达成统一认知。

让所有人都明确需求的背景和目的，这有助于相关人员了解用户的需求。利于了解为什么产品经理会这么做。

提前确认和统一产品需求实现的过程和方法，在需求评审过程中如果发现不明确或者技术实现有难度的需求，这需要产品经理进行取舍。

需求评审过程中可能会发现产品经理的某些需求有问题，或者没有考虑清楚，这时候就需要参与评审的相关人员可以群策群力共同思考解决问题的方式。

让参与者明确知道工作内容和交付时间，具体表现为让研发、测试评估产品开发周期，产品经理来做决定。

需求评审参与人员

同行，本项目产品、配合部门的产品，他们主要是来给你加油助威的，毕竟都是同一工种，都是有相同的感受。

设计，UI设计师\UE设计师，他们主要看原型是否有问题。

研发，iOS\安卓客户端开发、前端开发、后端开发，如果项目需求过大，或者改动较多，有必要邀请各开发负责人一起参与，它们主要是看流程、逻辑是否有问题。

运营，运营推广，客服，它们主要看这个功能有什么亮点，怎么包装把它推给用户。

测试，需要测试人员就产品的需求写出对应的测试用例。

需求会议评审现场    

在组织需求评审之前，需要再次确认你的需求、文档、原型是否真正的完成了？没有没遗漏重要的需求。

如果自己不确定，可以提前找核心人员小范围的沟通，确保不会出现大的问题。

如果邀请了重要级别的领导，可以再次确认一下与会者的时间是否能够参与。在邀请重要级别的领导参加时，可以通过邮件的形式将本次讨论的需求文档、原型、交互设计稿等相关资料一并发给领导，让领导提前了解一下，同时至少提前两天时间把相应的会议室预定好，如果怕到时候紧张，可以趁着下班的时候演练一下。

在需求开始评审之间，首先开始讲解时不要一上来就直接讲需求设计结果和功能点，应该通过故事的方式明确需求产生的背景，让参与评审的相关人员能知道这个需求是如何产生的，有助于让大家建立起共识。

其次讲需求时要有节奏和条理，要让大家知道需求实现的价值，这时更多都是预估的，要用相对科学的方式去预估，若有相关的数据分析支撑，会更有说服力。对设计人员、开发人员来说，需求理解的越深刻，开发实现的一致性就越高，越不容易偏离需求设计结果。

在讲解需求时，应该抓大放小，在一些细节问题上，可以会后与具体相关人员具体商议，要知道，让这么多人聚在一起花费较长的时间开会并不容易，要适当的控制需求评审的节奏，可以适当的开个小玩笑来调节一下现场氛围，但是不能偏离主题，让大家越扯越远。

还有在评审会议现场，针对产品经理提出的解决方案，一定会有其他同事不认同，从而发生争议，这时产品经理应该敞开心菲的先让对方把话讲完，尝试着让自己站在他人的立场思考问题，确保自己理解对方的问题，不能一味的抱着自己必对的角度不让对方讲话。适当的争议有利于澄清问题，从而想出更好的解决方案，因为不同的人总归有不同的角度，多吸收总不是坏事。

评审会议结束

评审会议结束之后，不是事情做完了，而是事情刚刚开始，首先需要确认的就是排期，在会上，相关人员已经答应过的需求排期，会后再跟对方确认一遍，做到心中有数，有必要的下，要以邮件的形式确定，确保每个需求，都有行动计划。

需求评审很多时候也是一个迭代过程，很多情况下不能一步到位，这时候，你应该整理遗留的问题，并拿出解决方案，需求遗漏发现的越早，修复成本越低。在评审过程中，或许某个问题，真的就是产品经理之前由于自己的认知没有想到，这时能够发现解决现实问题更好的方案，等到修改完成之后，更新到内部系统中，如果有必要约下一次评审时间，如果没必要则直接更新到内部系统中，同时做好版本更新记录，通知到相关的每一个人。

总之需求评审环节是非常重要的环节，是承上启下的环节，如果这个环节没有衔接好，那么就会导致后期实现需求有偏差，产品经理一定要在需求评审环节让大家达成统一的认知。

谨记，需求评审是产品经理积攒人品的重要时刻，如果不想让同事说你不靠谱，那么就需要好好准备你的评审，争取做到用户需求把握明确，功能模块设计合理，业务流程结实可靠，交互流程亮点突出，原型结构清晰有层次。