撕逼大会之需求评审
【字数：2849；阅读时长：8min】
需求评审会，又名【撕逼大会】
你们感受一下，脑洞下看看有没有什么画面感可言：安卓端、IOS端、后台、H5端、UI····在会议过程中各种不可以、各种充斥着辩论的声音，然而一个产品孤零零的舌战群儒！
经历过需求评审的我们都知道一件事，就是当我们各项产出物都完成、流程捋顺的之后，我们会跟需求方确认，确认之后呢，紧接着就会进入到技术方的需求评审，这个评审的过程目的很明确，就是阐述自己的观点并且将设计文档在最可行下的方案得以落实和执行~
但是需求评审中，往往不少产品会把自己搞的伤痕累累，为什么呢？做过产品的都知道——技术会喷嘛~而且一路一个坎的喷~
以上是现状！我们今天要说的是，如何让需求评审更高效，更具体的可以落实，而不是变成异常各抒己见的撕逼大会！
1
一、首先，我们得搞清楚需求评审会议的目的：
1、产品自身可以很清晰的表达设计文档的每个流程、每个板块的各项情况，例如各个板块的流程、各个功能的正常情况、异常情况的说明，特殊需求点的规则阐述等等。
2、关于人人都是产品经理，并不是说每个人都可以做，而是每个人都会站在用户角度去观察产品经理设计出来的文档内容是否合理，这样来说，就会出现众口难调的结果——每个人都会有自己的想法，每个人都会觉得自己的观点是正确的，这样我们就需要正确的、合理的、全方位的沟通（此项为沟通方法）
3、关于表达，是否可以正确的表达和聆听，这是产品在需求评审会的核心原则！
2
二、再次，我想通过个人的经历来阐述一下需求评审会的表达方式和原则
1、不可否认，很多人都不会说话！
其实，无论是我们产品经理的产出物（如PRD、流程图、框架图），还是我们的语言表达，最终想要达到的目标就是一次性尽可能没有任何问题的与各个涉及开发的技术方与执行方来正确的交流和表达。那么我们表达的前提就是对业务的了解和对市场的研究
只有对整体业务流非常了解，才能从各个方面去说服技术来按照产品的方案去落地，而针对一个行业的深入了解，是需要时间和经历的；所以，每句话的说与不说，心里一定要有底！
这里面涉及到一个原则性问题，就是，我们为什么有时候被技术一句话怼回来却无言以对？不是因为我们不知道怎么反驳，只是对行业的积累性不是很全面，对某些原理性不是很了解——这也就是我们经常说的那句话：学会站在对方角度去思考~
站在对方角度思考，不是说我要怕你或者无力回击，真心的希望同胞们不要把每次需求评审都当做一场战争去做，那样只会两败俱伤，别忘了，我们做任何事的前提只有一个——我们都希望产品越来越优秀，越来越多的用户爱上我们的产品——这才是我们得以骄傲的事情！而不是战胜谁······
总结：说与不说，有时候不是失败或成功，我们有时候需要通过积累来成为可以拥有更多发言权的人，前提是我们要做到熟知于心！
2、上帝给了我们两个耳朵，是让我们更好的去聆听！
现在让我们静下来，然后深呼吸一下，安静的回忆一分钟，我们在参加了这么多需求评审会，起初我们去撕逼的心态如果是为了坚持自己的想法，那么继续撕逼是为了赢得胜利感，还是为了产品能够得到更好的建议？
首先我需要说明一点的是，产品经理一定要有自己的原则和坚持！但，这并不意味着我们不去倾听别人的建议和意见，如果前提站在为了产品的发展和用户更好的体验来给的建议，最起码我，一定会听！这里面我们需要知道的是，任何一个公司的任何部门的任何人，都是需要相互合作，不是处于敌对双方的关系~技术方在我看来都是非常敬业非常专注的人，有时候可能说话只是为了表达某个建议，如果我们作为产品的误认为人家是为了证明自己，那么有效合作的效率会越来越低。因为你不知道人家的意思啊，总以为是在打仗，那还说什么，谁怕谁？来啊~
但如果这样，产品就完了···我们需要知道的是，大多数人的思想只不过是环境的产物，脑子很清晰和另一种脑子很清晰的想法，最终是通过文字或者语言来进行表达和阐述，但是如果两种思维发生了碰撞，只能说明有一方的思维有了固化的枷锁并且暂时无法摆脱。不要紧，跳出来，想一想，是为了打仗体验胜利感还是为了产品更好？
不管多么激烈，只要我们明白我们最终的初心是没有变的，那么依然可以继续讨论（当然，讨论也是需要技巧的）
总结：不忘出现，方的始终——沟通的过程中实时反思和摆正位置，要知道产品角色的属性不是为了争吵，而是为了解决问题，那么所谓的撕逼，就不是问题了
3
三、技巧
1、不要在某一个点一直争论：
当我们停留在某一个点，打个比方，注册时候我们要不要邀请码？是必填还是选填？（只是举个例子）
如果我们在这么一个点上因为每个人的每个不同的想法而一直争论，那么无疑是对需求评审会的亵渎，需求评审会在我看来本身就是一件以讨论技术实现方案以及评估工期时间节点为主的一场会议，如果真的停留在某一个点上一只撕的话，那么先过，会后冷静下来根据公司业务和数据来给个最终的方案！
2、适当的学会调频：
如果同时负责两个以上产品的时候往往会有这种情况，就是之前某个做过的产品的某些逻辑可以直接拿来复用，这个无可厚非，既节省了时间成本也节省了人工成本；但是出于业务的差异性，如果讨论的过程中，突然某个人想到了之前的某个业务流的问题并发起了谈论，那么暂时不要阻止，允许他有思考的时间，当节点到了之后，那么拉回来，继续我们刚才没有继续完成的问题，继续讨论。
否则，我们在讨论什么？
3、别红脸、别出言不逊：
作为产品来说，需求评审会可能会出现各种意外的情况，不管发生是什么，一定要谨记隐忍这两个字，不能把自己搞的失控了，进而做出主观色彩很强烈的表现，那样首先是对别人的不尊重，另外来说，会影响后期各个部门的协调的配合工作。耽误了工作，恐怕自己也会很难受的！
别做让自己后悔并且无法挽回的事~
以上我们说了需求评审三个需要注意的点
另外，评审会有几个阶段，也想分享一下：
1
一、会前
会前最好把相关部门的现有工作进行一个总体的了解，因为任何一个新需求出来之前，我们要保证之前的需求可以正常完成，没必要给谁增加过重的工作量
提前将产品的交互、需求说明等产出物邮件给相关人员和上级，这种预热是需要的，不然会议前大家一无所知，会上很容易实时发挥各自的意见，那样就真的是临场发挥，各抒己见了
最后，会前一定要自己仔细的过几遍自己的输出文档，以免会议出现自身出现的问题而导致印象会议正常进展，那，你就等着被蹂躏吧
2
二、会中
会中，我唯一的建议就是先把自己即将要做什么、为什么要做这些，做这些可以为用户带来什么、为公司带来什么等等说清楚，可以场景化需求，也可以目标化需求，这样的余热是有必要的，最起码大家知道：哦，做这个可以这样~这样的话，也许，评审会会更顺利呢~
再，就是如何表达和聆听，这个参考上述几个点就可以了
3
三、会后
总结、总结、总结！
首先要有会议纪要，罗列清楚问题和争议点，想清楚如何解决，并给予最终的方案和结论即可
再，将最终文档邮件给各个人员，建立交流群（方便实时交流）、建立项目共享文档、建立反馈渠道
督促、跟进、测试
最后，如果是新上线，要提前准备好商城上线相关材料！切记、切记！
所有的所有，都是我走过的坑，希望我的分享对你有用
别怕，你并不孤独！