产品经理作为一个产品或者一个模块的管理者，需求评审是必不可少的环节。在整个产品的建设期内，需求评审是一个承上启下的环节，上一环节承接的是需求分析，需求立项，下一环节推向的是研发测，需求评审通过后需求将进入研发阶段。因此需求评审的重要性是不言而喻的。
然而在现实情况下，我们可能遇到各种各样的情况，导致需求评审不顺。比如：
1、开发可能是公共资源，一个开发可能负责各个产品线，各个业务域的情况，开发可能没有时间，或者开发很难聚集到一块儿。
2、针对大型的项目，需求评审可能会持续很久，一天或者几天，这个时候长时间的评审可能会导致效果不好
3、开发可能会拒绝你，开发认为需求不合理，
4、需求评审完了，没结果，没下文，没结论，不知道下一步该干什么？
5、需求评审的时候话题蔓延，超出需求评审的范围，导致需求评审效率低下
6、评审过程中过于关注研发实现的细节问题，导致评审会议拖沓。
7、评审过程中，忘了各方的提出的问题，导致需求再次评审的时候出现问题。
那么如何解决上述这些问题呢？
其实我们可以将需求评审过程分为三个阶段准备阶段，评审阶段，完成阶段，这三个阶段所面临的问题是不一样的，将这个三个阶段的问题划分至各个阶段去各个击破。
一、准备阶段
1、需求方案三检
自检：所谓自检就是自己在写完需求方案时对自己的方案再次进行检查一遍。
首先，在这个环节依然需要将需求再次分析一遍，道理其实很简单，自己debug永远要比需求评审时被开发怼上天要好。
然后，需求没问题，那么需要检查的就是，需求方案的成本（不只是钱，人力，资源等等）、逻辑是否有问题，交互是否通畅，流程状态设计是否合理，方案是否写的清晰易懂，方案前后是否矛盾，需求上线对产品的影响等等。
互检：所谓互检就是可以将写好的需求方案交给同一团队的同学去相互检查，发现其中问题。
专检：所谓专检就是将方案交给更加专业的大佬去看看，看看大佬有没有什么更好的建议或者方案上有什么问题。
2、需求获得业务方/客户/用户认可
我们所有的需求都有直接或者间接的受众，这个受众我们成为我们的用户，客户，业务方，我们的方案的使用方是他们，是他们最终为这个方案买单，因此他们的意见很重要，和他们沟通方案，让方案获得他们的任何是非常重要的。
3、安排需求评审会议
确定参会人员
需求评审常见的参会人员有，产品经理（主持人，或者需求范围相关的产品，上游等等）、前端、后端、测试、UI。这些角色是需求评审中常见的角色。
确定参会地址
参会人员确定好以后，就是确定会议室，对于线下会议这个很重要，因为有可能会议室被占用，从而导致会议被推迟或者取消的情况时有发生。因此在确定参会人后，及时预约会议室是比较重要的事情。当然线上会议这一步骤可以忽略，比如钉钉视频会议等等还是比较方便的。
确定参会时间
确定好参会人员与会议室后，这时需要做的是沟通时间，这种对于研发是公共资源的情况尤为重要，你以为他们可能有时间，最后可能参见不了评审，从而导致需求评审会议流产的事情时有发生。通常可能发生情况是，有大部分研发有时间，极个别同学时间错不开，这时候的策略是需求评审会议时间不变，让没有时间的同学找可以替代他参见评审的同学也是可以的。
发起会议预约
在上述几个步骤做完以后，为了避免遗忘，至少提前一天发起会议邀请，可以通过钉钉发送待办，会议邀请，邮件等等。
4、熟悉评审的内容
经常有常见的现象是会议上开发对需求方案一点不熟悉，从而导致在评审的时候效率低下，这种情况可以在会议评审前至少2小时内将需求方案发送给需要参会的同学，让他们对需求方案有大致了解，从而提早发现问题。
二、评审阶段
评审的正确姿势
1、结构化
评审的时候如果我们能够按照一定的结构（总分总，因果，时间序列，问题导向等等）去讲述我们的方案，这样不仅能便于其他同学的理解，也能使得会议更加高效开展。
2、说重点
在评审中，我们的方案可能成千上万字，全部讲述下来是很花时间而且费力的事情，我们可以将逻辑，功能，流程讲清楚，对于细节部分例如字段怎么取，时间戳怎么算，按钮的交互逻辑这类问题可以一笔带过（但前提是你的demo或者prd有这些内容，否则开发过程中你可能会被烦死- -），如果是涉及到对既有流程改造，那么重点突出改造的内容即可。
3、带节奏
在评审过程中，产品经理是会议的发起人，同时也是会议的主持人，会议的节奏应该由你去掌控，对于会议上的争论，应该积极引导，避免由争论发展成为争吵，同时，对于与需求评审无关的话题应及时纠正，避免跑偏，从而导致会议拖沓。
评审的几个技巧
1、分批次评审
需求评审时，一个迭代可能会有很多小需求，而这些小需求可能会涉及到不同的开发人员，这个时候，可以分组评审，相关的研发负责人评审完成后即可离开，这样不仅可以提高评审效率，也可以节省大家时间。
2、求同存异
需求评审中遇到不同意见，不同声音，这是很常见的事情，我们的需求评审，本身也是将方案抛出去，让大家发现问题的一个过程，因此需求评审的基调应该是发现问题，解决问题，在明白这个基调的情况下，我们大可不必因为不同意见，不同声音而将问题升级，或者是引发无休止的讨论，对于此类现象正确的姿势是，求同存异。对于有问题的方案中没有问题的可以先通过，有问题的可以放在其他方案评审完成之后再去讨论。
3、会议纪要
在需求评审中，做好会议纪要是非常重要的，一个需求评审可能很长，参与方可能很多，光凭记忆很难记住，这时会议纪要就很重要。简单来说，会议纪要就包含几方面
参与人
参与时间
参会方式
会议内容
会议结论
遗留问题及action
会议过程中你可能没时间记，这时可以找同事代为记录，或者记录关键字，关键点会后再补充。
三、完成阶段
需求评审完成的第一件事情就是写会议纪要并且同步给参会人与及相关负责人，对于这种正式的会议，会议纪要是非常重要的，它是产品经理保护自己，避免以后背锅的一种书面凭证，同时也是产品过程的重要过程资产，最重要的是会议纪要中会记录评审过程中的相应决策与后续的action，这些action是推动需求进行的重要手段。
需求评审的结果就那么几种情况，通过，不通过，部分通过。
对于通过的需求，那么自然就可以进行到研发阶段，那么下一个会议你可能需要参与到TC评审，技术方案评审。对于会议纪要中的遗留的action，你需要一一跟进并落实。
对于不通过的需求方案，那么你可能需要根据会议纪要提到的疑问与缺陷去修正方案，对于会议纪要中的action，需要指派具体的责任人，跟进他们并一一落实。
对于部分通过的需求，这些方案可能存在迭代中，一个迭代中可能包含很多子需求，其中部分可以进行开发，还有一部分评审未通，这时可以根据评审中提到的问题或者解决方案去修正方案，其中可能出现的情况是这个迭代资源排满了，没时间做，那么这时如果需求不紧急且优先级不高则可以排入下一个迭代，也有可能是需求方案本身出了，比如实现成本太高，逻辑有问题，等等，这个时候需要做的就是去调整方案，排入下一次评审。第三种则可能是需求本身的合理性，价值不高，而被拒，这个时候则需要回到需求分析阶段去通盘分析需求，再做决定。
需求评审，事情说小，也小，说大也大。用正确的姿势去开评审会议，一定能为你节省很多时间，这些方法你get了吗？
