在需求评审中被diss几乎是每个产品经理都会遇到的问题，要想在评审的时候被diss得越来越少，产品经理必须做好充分的提前准备工作。
需求评审对于产品经理可以说是家常便饭，这是很多产品经理都非常害怕去做的一个会议。因为很多时候产品经理在需求评审会上，是一个被集体攻击的一个的对象，处在一个非常弱势的位置。
我自己也组织过或参加过不少需求评审会，我觉得出现这种情况的最主要原因就是需求评审做得不好，做得不好就会被质疑，然后连带着你的专业能力也会被质疑。
所以做好需求评审对于一个产品经理的专业程度以及参与评审的人的印象是非常重要的，下面我想分享一下作为产品经理，应该怎么样去组织一场成功的需求评审。
总的来说，需求评审就是一个统一目标，明确需求，确定实现过程的会议。在需求会议上，产品经理需要跟大家明确需要解决的痛点问题，有哪些功能以及对应的计划，然后大家在会议上挑刺，讨论，甚至是撕逼，最终全体成员达成一致意见后开始开干。所以，通常一些项目需求都是要经过几次评审会才能完成的。
让大家都清楚需求的背景和目标；
统一需求实现的过程，方案以及相关功能点；
让参与成员清楚知道各种的任务以及完成时间；
确认研发和测试工时，产品经理按照需求上线时间判断是否再进行任务拆分，增加资源。
在需求评审中，选择合适的参会人其实很重要，我们绝不能为了让所有人都有参与感而把能想到的人都邀请了，但是其实很多人去参加完了整个会议发现自己并没有对应任务。
主要邀请的参会人是根据我们在输出需求方案的过程中是否涉及到相关任务决定的，一般一场需求评审会都会邀请以上的人员参加，再根据项目需要还有可能需要邀请前端，UI，UE等。
首先，确认需求文档、原型都已经完成；
提前找核心人员沟通需求主流程，提前消除大问题；
至少提前一天跟参会人员确认会议时间，确认后提前定好会议室并发出会议邀请；
确认会议时间后，提前给参会人员发PRD和原型，让大家可提交了解需求；
做好会议规划，精准管理开会时间，如果是大型的需求或者项目，建议在评审会前先预演一遍评审流程。
需求评审其实就是对PRD的评审，而PRD的文档规格其实就是你在做需求评审时的关键流程，一般我会遵从以下的流程：
（1）需求背景
在需求评审开始的时候，我们首先一定是要介绍需求背景，说明业务现状及存在的问题，明确本次评审的新功能/产品需求解决的问题是什么，让团队成员们都知道我们为什么要做这个产品。
只有让大家对产品需要解决的用户痛点问题保持一致，我们才能开始后续具体功能的评审，也能避免往后更多的争论不休。
（2）用户与需求
根据“用户-场景-需求”的逻辑，阐述此产品主要面对的用户/用户角色，并且描述清楚不同用户对应的职责或者使用场景，通过场景说明列举需求。
因为不同的使用场景功能往往都是大有不同的，描述清楚场景才能让参与评审的人更深入地理解用户的需求。
（3）需求收益
接下来，我们需要跟大家说明一下需求能给公司/用户带来的主要收益，让大家清楚知道这个需求的价值是什么。
（4）产品功能模块
这个部分是需求评审中的重中之重，是我们重点需要评审的内容，涉及到功能、逻辑、原型交互等内容，一般在评审中，我会这样去处理：
首先，简单介绍本次PRD涉及的需求以及模块功能说明，可以用思维导图或者列表，目的就是让参会人先有一个整体的简单的了解。
根据不同的功能模块按子用例维度进行评审，先在每个子用例中说明触发条件、要素定义、权限要求等等；
然后，建议针对每个子用例画出流程图，我一直认为流程图在需求评审中是特别重要的，因为它能够让参会人员特别是开发对我们所需做的功能有一个清晰的认识；
在介绍完流程图后，我们需要再详细地说明一下业务规则，包括但不限于本功能是可以使用已有的哪个产品功能还是需要完全重新开发
如果你的需求涉及到原型交互的话，在需求评审的时候也是需要有相关说明的，我的习惯是在介绍完成业务规则后，在大家知道我们的方案要求后，再给大家介绍我们对应的原型交互是怎么样的
（5）衡量需求成功的数据指标
在介绍完我们所有的功能模块后，我们需要告诉大家我们这个需求的成功指标以及相关的计算公式，取值逻辑，数据取值是否需要重新埋点
（6）需要配合部门的哪些支持
如果需求是需要配合部门的支持的，我们应该把需要支持的清单列举一下并说明具体需要什么样的支持，当然这些在产品功能模块评审的时候也是要具体说明的，这里只是我们做的一个总结
（7）预计上线时间
一般参与评审的需求业务/项目都会要求一个预计上线的时间，我们需要组织开发，测试预估一下需求工时。然后，跟据预估的工时判断一下能否在预计上线的时间准时上线。如果工时比我们计划的要长，那这个就是一个风险，我们就需要跟项目经理一起商量风险应对方案了。
（8）注意点
1）一定要做好会议计划，管理好开会时间，不然你的需求评审会效率可能会非常低；
2）不要一上来就讲功能，这会让你在整个评审会的过程中不停地去解答参会人员的基础问题，浪费评审时间；
3）抓大放小，不要在细节上面过多讨论，如果是没有办法统一大家的决定的，可以统一一下大家做决定的思考方式；
4）讲需求的时候要注意节奏跟条理性，不能只是一个走马观花的评审流程，在评审的过程中，产品更不能乱；
5）因为参与评审的人都有不同的关注点，那评审的过程肯定是会存在争论点的，一些重要的争论点一定要记录下来。
1）给所有的参会人员发一份会议纪要，纪要内容包括：
已经达成一致的会议结果，如：分工，预计上线时间等；
会议上已经确认了的修改点以及修改后的方案说明；
会议上遗留的争论点/问题，每个问题责任方，解决deadline等
2）发出更新后的需求文档，并且更新到公司内部系统的产品资源中
3）如果需求文档需要修改的地方比较多，建议再约一次需求评审会，重点评审修改后部分
五、总结
需求评审会只是作为产品的一个日常的工作，我们常说“凡事预则立，不预则废”，在需求评审工作中，当你有一套自己的方法，当你经历了一次又一次的需求评审后，你会发现它锻炼了你的组织能力、表达能力、逻辑能力、说明力以及执行力等等。
