需求评审时常发生的情况中，或多或少都会遇到很多其他的问题。以下这些问题肯定会有。
什么是需求评审会？
首先明确，需求评审会就是产品经理告诉团队，我们将要做什么事，是与团队统一思想，明确需求的大会。
很多产品新人都很怕开评审会，因为害怕被开发Diss，而就算经验丰富的产品经理，也不敢保证每次评审会都是完美。
一不小心就把需求评审会开成撕逼大会，所以又被成为逼死产品经理大会。
作为一个在小公司生存的产品经理，深深感受到需求评审会一方面就是产品的高光时刻，集万千注意力于一身，一方面，就像是战场，集万千炮火于一身。
为什么要开需求评审会？
不论什么会议，都需要先明确目的，需求评审会的目的是为了让所有人都明确需求的背景和目的。
然后提前确认和统一产品需求实现的过程和方法，让团队人员明确知道工作内容和交付时间。
让研发、测试评估产品开发周期，最后敲定人员任务分配和开发计划。
那么，准备工作需要做哪些呢？
检查准备工作
01、场景和故事
每个人都是喜欢听故事的，如果想要团队快速与需求产生情感共振，最好的办法就是给他们描述场景，讲一个生动的故事。
例如，描述我们的用户当前遇到了什么问题，最好举一个张三李四的精确案例。团队小伙伴立马会感同身受，注意！一定要真实。
需求不是凭空产生的，场景和故事是需求的支撑，我们在需求产生时就已经知道了，但是不要依赖大脑记忆，最好书面记录下来，作为项目资料的一份。
一是因为仅靠口述是有限的，我们很容易不小心遗忘；二是让团队成员能够随时查阅，加深认同感。
02、产品需求文档
一些小公司会省略需求文档这一步，理由是效率太低，为了追求速度，直接画原型，然后让开发能明白就行。
一开始笔者也是这么做的，原型加备注就代替需求文档了。这在工作上按理是没问题了。
然而需求文档对评审会的重要性不言而喻。一是可以让开发在会前及时全面熟悉需求，二是编写过程中，我们自己能及时发现漏洞。
有时间因为某些原因，测试不是第一时间就介入项目，可能是开发把静态页面搭建完成了才参与进来，测试才开始编写测试用例。
通常产品经理要单独给测试重新讲功能和流程，而如果产品有写需求文档，可以将需求文档交付给测试，作为测试用例编写的参考（上礼拜笔者就把一份Excel编写的需求文档交给中途参与进来的测试小姐姐，小姐姐非常开心，嘻嘻）
03、需求清单
任何项目需求都可根据优先级进行排序，因此提前列一份需求清单给到开发，开发在评估工作量时可结合实现难度和需求优先级等因素进行分工。
判断需求优先级的办法有很多，比如KANO模型，将需求的特性分为五种属性：必备属性、期望属性、魅力属性、无差异属性、反向属性。
我们的优先级按以上五类由高到低，判断的方法时根据影响因子的权重进行比较，判断需求所属属性。另外还有一些通用的开放的原则辅助判断，比如：
- 基础需求必须做
- 影响主流程的需求必须做
- 符合项目目标需求的优先
- 覆盖用户面广的优先
- 性价比高的优先
这样当面对开发要砍我们优先级高的需求时，拿出上面的理由回应。如果优先级低，那咱好商量，如此淡定从容面对砍需求。
04、原型图和交互
原型图是在需求评审时用来向团队展示的主要内容， 讲解流程和功能时也是使用原型图，为了效率的提高也可以使用低保真，但是笔者观察其他的产品经理还有自己的经验都认为尽量输出高保真的原型图效果会更好，不仅在团队面前展示产品的专业程度，评审过程的团队成员理解成本更低，趣味性更高。
这只是笔者的一家之言，并不了解其他公司的情况，需求评审时用需求文档讲解好像更常见。
确定参与人员
我们需求评审会叫上所有相关的人员，如果他们正在其他项目组中，我们就要找他们负责人安排协调人手。
主要有开发包括前端开发和后台开发、测试、UI设计师等等，在需求评审通过后，我们将组成一个团队，共同推进需求实现。
其次，我们还应该叫上运营同学，也许他们只是听一听，不会在前期参与更多，但是需要了解需求，在上线运营时才不会觉得功能是突然冒出来的，以至于手忙脚乱。
另外，如果需求涉及到其他业务模块，还可以私下叫上这块的产品同事，一来给需求提供支持，二来有关系较好的同行在可以给自己壮胆，尤其是刚入职没多久就负责项目的产品经理。
在文章开头说过，需求评审会是统一思想、达成共识的会议，但是虽然所有人参加的是同一个评审会，但每个人关注点都不同。
开发同学更关注功能的流程和实现难度，UI设计师会关注项目的风格和原型页面设计，而测试同学，就是什么都关注，毕竟他们是“天生挑刺”的，所以也是需求评审中最积极的，会对原型、交互、流程等等提出非常多的问题。
所以我们还需要提前预测他们的关注点，做好充分的准备，减少临时回答不上来的困境，虽然有时候难以避免。
提前沟通
提前沟通有两种方式，一种是找技术负责人先沟通，请他们帮忙排查需求，提前消灭可能存在的大问题。
还有一个是找开发一对一单独过需求，一次次的评审演习，交流的过程也是产品自查的过程。不要担心开发同学不配合，只要你谦虚的请求耽误对方一点时间，人和人之间还是很友好的。
如果开不了口的话，就选在一个非正式的场合，比如下午茶时间，无意间聊到这个需求，“不小心”透露可能需要他的协助，顺便讲一下需求，完美。
邮件邀请
准备的最后一步就是发会议邀请了，我们只需要和主要参与人员协调并确定会议时间即可，然后提前一两天发出会议邀请邮件，定好会议室，切勿临时喊人开会，避免打断对方工作，引起对方不适。
邮件附上会上使用的项目资料，请参与人提前查看，可提高评审会效率。
拥抱质疑
评审会，就是让团队站在他们的角度来对我们的需求提出质疑，我们不能“坐以待毙”等待质疑，而已要主动在会前预测参与者会提出什么样的问题，比如：
“你这个流程跑不通啊？”
“你页面这个xx字段哪来的，现有数据表里没有。”
“这真的是用户的需求吗，好像没有作用。”
“你确定要这么做吗？再想想？”
上面这些话是不是很耳熟？这是我们经常在需求评审时会听到的质疑，因此我们要在会前预测参与人员可能会提出质疑的地方，并做好准备，力求在被质疑时能够相对从容地应对。
我们要学会“拥抱质疑”，这样才能让我们提出来的需求更完整，更有说服力。
而且我们需要感谢开发的质疑，因为一般在需求评审时一点问题都提不出的开发，事实上通常根本没理解需求，往往在开发过程中出现没理解需求，或需求理解上有巨大偏差，导致设计出来无法上线，最后项目延期，浪费人力、物力。后果很严重。
总 结
需求评审会是产品经理工作的里程碑，在准备过程中可锻炼我们的执行能力、沟通能力，做好充分的准备我们的评审会即成功了一半.
接下来就以开放的心态去主持需求评审会吧。
