上篇文章《产品功能调研，需要注意的3个要点》我们讨论了产品功能调研的相关知识，这一次我们来谈谈产品经理如何打好“需求评审”这场仗。
在产品经理岗位的能力要求中，其中两项是强大的心理抗压能力和良好的沟通能力。
因为产品经理很重要的一个职责就是与公司的各个部门协调沟通，保证项目进展的有效性。工作中接触的场景和同事涉猎面越广，就越容易被怼，在各部门同事云集的需求评审会中更是如此。
需求评审是产品经理工作中非常重要的一环，它决定着我们的想法是否能够落地实现，也是产品经理被怼可能性最大的时候。
若准备不够充分，需求评审会可能演变成群起而攻之的批斗大会，而被挂在十字架的对象就是产品经理和原型图。
以下列举了一些本人被怼的血和泪：
“在XX情况下，你没有做条件限制呀，能不能考虑的全面点？”
“你这个流程太麻烦了，用户能被你绕晕，能不能简单点？”
“现有的数据库结构不支持，要实现只能重构，太麻烦了！有时候你产品的一句话，开发要做一个月呀，兄嘚！”
“这样开发难度很大，最好基于现有的数据库结构考虑业务拓展性，”
“这个功能操作好奇葩，哪有产品像你这么设计的”
需求评审的目的是让相关人员（开发、设计、测试、运营、老板等）理解需求背景、需求目的以及具体的需求描述，并认可原型设计和解决方案。
在需求评审中多多少少会碰到被怼的情况，那么作为产品经理，怎么才能使需求评审会保持高效，并在评审会中降低被怼的可能性呢？
俗话说“台上一分钟，台下十年功”，想要在需求评审会的有限时间内，保持高效且不被怼，必须做好充分的提前准备工作。
1. 充分准备原型和PRD
首先充分理解自己所负责的需求，不要一拿到需求，头脑一热就开始画原型。
先做需求分析和产品调研，梳理出功能架构和业务逻辑，最好输出“业务流程图”和“功能结构图”，图表比文字更容易让人理解需求。
另外尽可能输出逻辑严密，表达清晰的原型和文档，尽量考虑到所有的边界场景，并提前和开发人员沟通，就需求的实现方案达成一致。
如果评审会中被挑出各种疏漏问题，不仅影响会议的效率，而且会让同事质疑自己的专业能力，也会成为以后工作中同事不积极配合的诱因。
针对同一问题给出多个解决方案，这样在评审中，哪怕开发表示方案A不能实现，还可以补充提出方案B。
需求文档的表达要简洁，逻辑要严谨。有的公司需求文档和原型是分开各一份；而有的公司是需求文档直接写在Axure里面，直接备注在原型页面旁边（我目前用的后者）。
很多产品新人都会问哪种方式更好，其实不管哪种形式，要学会因地制宜。
说到底需求文档是给开发和测试人员看的，他们是需求文档的核心用户，产品经理要倾听用户的诉求，多询问他们的意见，如何能让他们更有效率的阅读需求文档，以及更容易理解需求文档中的表述。
2. 产品组内评审
在真正的需求评审会之前，一般情况下，要先对原型初版进行组内评审，原型初版一般不需要完整的需求文档，只需要标注出重点的交互和功能逻辑。
组内评审的目的是让组内产品同僚帮自己擦漏补缺，提前检查出疏漏和不合理之处。
另外产品组内评审是基于用户体验5层要素（战略、范围、结构、框架、表现层）来审视原型和PRD，检视产品设计的合理性。
比如有时候在组内评审时，判断需求不符合当前产品的战略方向，应该暂缓或不实现。这是开发、设计、测试、运营都不太重视的维度。
3. 提前告知
在通过组内评审之后，接下来就应该修改并完善原型和prd。
在需求评审会的前一天把原型和prd发送给参会的相关人员，目的是让其提前熟悉需求，达成目标上的一致性。
如果有问题及时收集，在需求评审之前向提问者解答，能大大提高需求评审会的效率。
需求评审会是一个极度频繁的场景，除了早上晨会，应该是初级产品经理开过最多的会议。
只要我们提前做好了充分准备，就可以当作是个人的小型“产品分享会”。只有放松了，在讲解原型时也不会因为太紧张出现磕巴的状况。
1. 切记阐明背景和缘由
会议首先要向大家阐明需求背景、需求目的，让他们了解这个需求是怎么产生的，需求是为了解决什么问题，让参会者了解并达成目标上的一致性，有助于理解业务。
切忌一上来就讲功能、讲交互，导致参会者一脸懵逼，知其然不知其所以然，会影响会议的效率和后续的项目进展过程。
2. 产生互动
目的是为了让参会者更专注的听评审，减少会议室玩手机的情况。
分享一个不成熟的小技巧，原型中的名称和内容示例，可以使用周遭同事的名字（他们不介意的前提下），并在讲解中念出名字，这样被Q到的的同事会放下手机专心看投影仪，提高互动性和趣味性。
比如评论模块中的评论示例，可以这样在原型中标注：
运营廖小骊：昨晚吴亦凡被爆恋情了，你们看新闻了么？
开发杨因：谁？
测试朱序：听说了，好大一个瓜，不过很快爆了另一个瓜！
设计雪琳：吴亦凡被套路了，好可怜
开发苏驰：谁……？
另外当讲到某个开发同事负责的功能时，可以与其产生互动，一个眼神示意或提及名字。
比如评审时可以这样说：
“后端同学杨因注意一下，CMS后台新增了2个字段。需要配合前端超哥调你的接口。”
“UI同学瓜瓜注意下，这个抽奖页面要有酷炫吊炸天的动效，足够吸引用户的眼球”
“任务系统新增1个触发操作，需要后端同学苏驰在数据库加一下。”
这样互动可以很自然的打断玩手机的同事，使其更专注，毕竟我们不能禁止评审中玩手机，万一别人是在回复领导消息呢~
沟通协调本就是产品经理工作中的常态，如果善用沟通技巧，可以提高我们的工作效率。
3. 权衡轻重
讲解具体的页面、功能点和交互时，可以按照大纲结构依次讲解，事无巨细，不要有任何遗漏。
但由于评审会的时间有限，遇到不重要的点可以一句话概括，比如某个页面怎么排版，显示哪些字段。遇到重点的功能和业务逻辑时就需要详细讲解。
注意！每讲解完一个模块，都要停顿下让大家提问，全部讲完时，也要简单回顾所有页面，让大家提问。
有的话当场提出当场解决，尽量让所有参会者在会上理清大致的业务流程。可以大概率避免在开发、测试过程中，他们再来问自己讲过的逻辑，导致过多的打扰自己正常的工作。
想象一个场景，某天自己正在梳理思路，画原型时，一会儿开发A来确认某个会上讲过的逻辑，一会儿测试B来确认另一个问题。
如此一来，不仅我们要做很多次打断思路再连接的额外操作。结果可能是一天感觉原型没什么进展，时间基本都花在和开发测试确认问题了。
至于一些排版、交互的细节问题，如该页面内容最多显示几行。可以会后再确认。
4. 把控时间节奏
评审中，有一种不幸，是参会人员对产品经理的解决方案提出质疑，就会进入“需求的讨论期”，没参与讨论的人员可能就会玩手机。
若讨论期过久（建议最多不超过10分钟）仍没有达成一致，说明自己的解决方案多少是有问题的。这时候要主动提出停止讨论，会后考虑是否有更好的解决方案，同时与对应人员进行沟通。
另外，开发都会在评审会上讨论技术实现方案，我们要允许开发人员展开讨论，因为要确保需求是可以实现的。
有时候开发会下意识的将讨论延伸到具体开发细节，比如用H5，还是原生开发。从而导致讨论时间过长，我们要审时度势，及时制止，提醒开发可以会后再讨论。不要让需求评审会变成了技术研讨会！
最后，需求评审涉及的人比较多，讨论经常会“跑题”，有时候话匣子一打开关不上，又扯到其他业务上去，导致评审的效率很低。产品经理应该适当制止，把大家的思维拉回来。
5. 需求是领导提的
在评审中，产品经理的内心活动几乎都是“希望一切顺利，没有人唱反调就完美了”。但往往事与愿违，产品经理时常会遇到有人唱反调的情况（对事不对人）。
比如，技术人员发出“这个实现起来太麻烦了”、“开发难度很大”的声音，这种情况一般都代表着巨大的开发量。
因为需求评审前都会先通过领导或老板的审核，但也不建议直接丢出一句“这个需求是老板提的”，用老板这个靠山来反驳。这是不充分理解需求的表现，不做需求分析，拿到需求就埋头画原型。虽然这句话如尚方宝剑般，效果可能很好，但是不能让开发信服。
首先我们要权衡会否值得这么大的开发量。如果确实值得，可以给开发人员“洗脑”，强调需求的重要程度，实现这个需求可以创造什么用户价值，给产品带来什么收益。
以理服人，让开发人员没有理由拒绝。或者可以做适当的让步，表明需求必须实现，但可以接受较长的开发周期。
最好的结果就是需求没被砍，开发人员无奈的丢出一句：“可以实现，只是要排期……”。
6. 做好会议记录
敲黑板啦，这里是重点，在会议中一定一定一定要记录下争论的遗留问题。
或者让同事帮自己记录也可以。不然过后靠自己回忆或者找别人问，会很麻烦。有可能别人也想不起来就尴尬了。
1. 整理遗留问题，给出解决方案
评审结束后，整理并解决会议中的遗留问题，若遗留问题太多，有必要进行二次评审。
检视并修改原型和PRD，然后把最终版发送给相关人员。
2. 督促排期，跟踪进度
督促项目经理进行排期，确认预估的开发周期和测试周期。
接下来不要以为就没事了，都说产品是产品经理的孩子，我们这些当爹妈的，难道我们怀了ta，给ta做了体检，就不负责把ta健康的生下来吗？
后续要持续跟进开发测试进度，直到上线。在跟进过程中，大概率上还有未考虑到的问题逐一浮现出来，产品要和开发测试紧密合作，讨论新的解决方案，并同步修改原型和PRD。
四、反思
人类在很多时候分不清自己是“坚持真理”还是“固执己见”，产品经理亦是如此。
在需求评审中遇到反对观点，我们常常会不自觉产生自我保护意识，一味的进行反驳，却忘了需求评审的目的，决不妥协和轻易妥协似乎都不是好办法。
产品经理应当具备同理心，用我爸常教育我的话就是“换个板凳坐”，学会在他人立场思考同一个问题，或许会有额外的收获。
需求评审对产品经理树立威信很有帮助，想要打好这场仗，就踏踏实实做好每一步。希望自己能在每一次需求评审后，都有一点点的进步。
感谢你的阅读！如果有不同想法，欢迎交流讨论。
