好久没有写文章了，因为最近换工作了，正在拼命学习新东西中...
上周连续针对同一个版本进行了三次需求评审，第一次进行了全范围的评审，涉及到各方相关人员，包含：产品、设计、开发（客户端和服务端）、测试；第二次产品团队内部小范围的评审，主要是为了确定第一次评审中部分不太确定的/没考虑到实际可能遇到的问题的需求，涉及人员：产品（iOS端和Android端）和运营；第三次针对那些不太确定的/没考虑到实际可能遇到的问题的需求进行确认，涉及人员：开发和测试。等三场评审下来，就累成了狗。
一场需求评审会议变成了三场，这肯定是有问题的，是该好好检讨下了。
之前一直在创业公司，需求评审会基本很随意，叫上开发、设计和老板就可以直接开始了，评审会上也会遇到一些问题，但涉及的人比较少，且一个人从头到尾都只负责一个项目，事后基本上只要口头确认下评审时的问题就行了。但流程较复杂的公司情况就有些不一样了，需求评审会参会人数比较多，并且一个人可能会负责多个项目，需要重新调配资源，一旦评审中需求不确定/没考虑周全的问题，就会出现多次需求评审的情况，这就极大的降低了工作效率。
需求评审时常发生的情况：
1、与会人员对需求的目标不明确，易发散思维，最终偏离方向。
2、对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去。
3、对技术方案探讨不定，对问题点无限引申。
4、遗漏评审时的待改动的需求点，会后找相关人员再次确认。
基本上遇到上面情况中的任意一种，都会将需求评审时间拉长，导致效率低下，轻则需求产生变更，重则需求功能无法实现，产品人员在评审过程中也容易产生浑身燥热、体乏无力和头昏脑涨的感觉_|￣|○...
那如何进行有效的需求评审呢？
我结合我自己上周做的需求评审作了一些总结，天热了给自己拔拔罐，希望能做到更规范，减少评审时会出现的问题，少踩点坑。
将需求评审分为三阶段：
1、评审前
相关资料准备（确保人身安全）
1）产品需求文档
我的需求文档里一般包含四块：项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（说明此次版本可能带来的问题或考虑不够完善的地方）和业务流程图（对某些复杂功能/逻辑的分解）。
产品需求文档主要是要把需求的逻辑表达清楚没歧义，对各个细节描述清晰，各输入输出项（涉及到表单/数据的输入输出）、业务流程（功能的交互步骤和数据的流转）、计算规则（某些特定须计算的规则）、判断逻辑 （业务流程中出现的一些判断逻辑及各种判断下的反馈情况，账号的权限范围也属于这种）和一些特殊情况（如是否支持横屏啊之类的）都要写清楚，如果实在记不住太多，每次写需求文档时都会这里漏个流程那里漏个判断的，可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。当然不能事无巨细都通通一股脑写进去，不然开发和测试的朋友会看的很辛苦，小心被打...
举一个活生生的反例，上周写文档时有一个计算规则比较想当然了，要算“累计阅读时长”，阅读时长嘛就是阅读时长嘛，一句话就带过了，然后在需求评审时就比较惨了，该如何统计这个阅读时长？直接用定时器吗？还是使用本地时间？用定时器比用本地时间相比既复杂又低效，但如果用本地时间，那用户直接修改手机上的时间给不给累计阅读时长？还有用户如果一直停留在当前阅读页还给不给算阅读时长？...后面对这个功能的计算规则讨论了好久，最终评审会上也没确定下来。所以说，做好细节是多么的重要！/(ㄒoㄒ)/~~
产品需求文档的准确和详细可以有效减少需求评审时的花费的时间，也能让参会人员更清楚地了解需求。
2）线框图
带上线框图而不是比如这样或那样，配合线框图有利于对需求点的梳理。需求文档里可以简要配些线框图方便文字的理解，不过需求评审时还是另外打包一份线框图单独带着吧，可以详细点，把交互稿也带上。
第一次评审的时候，我忘了带，而需求文档里也刚好没放那个页面的线框图...于是我只能让大家跟着我一起在脑海中绘制一副图，能不能绘出来我就不清楚了Orz...反正不要学我！
3）相关数据
带上数据而不是我认为，一些需要数据支撑的需求点要带上相关的数据，用数据说话。
小范围的沟通（确认方案）
产品需求文档写好了，这个时候就可以去找涉及到本次改版的同事们去聊聊了，不要有写好产品需求文档就万事大吉，接下来只要等需求评审会就可以了这样的想法。提前小范围沟通可以避免很多不必要的撕逼，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，把这些坑都填好，这样在需求评审的时候就可以快速走过了。
上周我连开了两个项目的需求评审会，一个是改版还有一个是新应用的上线，改版的需求评审总共开了三次，就是最开始说的那种情况，而新应用上线的评审只开了一次而且只用了不到半小时，需求评审前和开发沟通就基本上已经将我不太确定的方案给确定了下来，并且确保了部分不确定需求的可行性，在评审会上是一次就过。有对比才会有真相，多么痛的领悟，不要什么都等到需求评审会议上才去确认/解决，提前做好沟通工作，能大大提高需求评审的效率。但不是说提前把所有的需求都沟通一遍啦！大家都很忙，动好脑子带好方案再去沟通！
产品内部评审（确认需求）
产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。在确定好各种方案后，最好在产品内部先进行评审，特别是当有两个产品经理分别负责Android客户端和iOS客户端但是两种终端数据又是用的同一个接口数据的情况，说白点，就是Android客户端和iOS客户端要求在大体上保持一致的情况下，为了保证逻辑的一致性，最好先进行产品团队内部的小范围评审。
一次内部的小范围评审可以规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率，同时也能增加其他团队对产品团队的信任感，以后办起事来就比较方便了你懂得\(^o^)/。之前在创业公司就没有碰到过这种情况，因为Android端和iOS端都是我负责的，功能是一致的，所以就没这种情况，也就可以省去这一步产品内部评审了...如果功能逻辑涉及到多个产品负责人，这一步还是很有必要的！
提前把需求文档发出来（有备无患）
根据以上步骤确认好需求后就可以把需求文档发出来了，以邮件/群聊的方式发出来，让与会者提前查看产品需求文档，不求他们能够把需求文档从头到尾看一遍，但求大家能知道下个版本要做的需求有哪些，这样前期的服务工作才算到位。
以上工作都做好了基本上就可以进行需求评审了，预约好会议室后通知相关参会人员参加。
2、评审中
正式需求评审时，带好必备品，就可以开始了，基本上只要前期准备工作做得好，需求评审时出现的幺蛾子就不会太多，稍微拍拍就能灭掉，所以评审时状况百出，多半是准备工作不到位。但除了前期的准备工作，在评审时还有几个需要注意的地方，能够帮助提升需求评审的效率。
产品经理应有的态度（兵来将挡水来土掩）
1）有清晰的目标
相比其他参与者，产品经理要对此次需求评审更有方向性和目标性，这次改版所要解决的问题以及所要达成的目标都应铭记于心，只有产品经理自己有清晰的目标才能做到即使同时被多人撕也不发生动摇，才可能确保参会的其他团队能理解并认同该版本所要达成的目标以及要做的功能点。
即使有着明确的目标，也别想着要把自己的想法强加到别人的脑子里，很容易发生：目标很明确，所以大家要按我的想法走的这种情况。需求评审目标并不是为了要说服谁！召开评审会，就是为了让大家对你提出的方案进行批评指正或提出疑问点，从而能及时地解决并发现方案中的问题，保持各团队目标一致，将产品做好。
2）把控好时间
需求评审时很容易会对某个需求/方案僵持不下，常一讨论起来就是半个小时，多遇到这么几个僵持情况，一场需求评审下来就好几个小时，不仅会慢慢耗尽大家的精力，而且需求评审的效果也不好，得不偿失！所以产品经理要严格把控好时间，由于前期工作准备不充分而导致一些需求/方案模棱两可，且暂时无法立马提出解决方案的可以会后确认好后再沟通，必要时可以进行第二次评审。
3）认真倾听
可能别人一上来就开始对你的方案提出不认可，这个时候就得认真倾听；开发在探讨技术方案的时候你也要认真倾听；先在大脑梳理好他们在说什么，倾听后才能对症下药，而不是打断然后陈述自己的观点。
倾听后再陈述而不是直接打断，可以让人觉得你在认真思考后才说出这番陈述的，更有说服力，并且不跟其他团队硬碰硬，先了解他们的问题再提出解决方案，不是显得更理智么？
4）保持清醒的头脑
在需求评审会议中，很有可能会发生争论，产品经理一定要保持理性，切不可让怒气或胆怯冲昏了头脑，失去理智。对会议上提出的每一个问题都应该记录下来并作出解答，要冷静客观的把自己的观点给陈述出来。
小范围的讨论（见仁见智）
在需求评审讲需求点时，开发会针对某个点进行技术方案探讨，这样有利于及早发现需求点与现有逻辑相冲突或由于硬件问题而导致需求变更或夭折的问题，避免到开发时才发现需求没法做...但也要控制好时间，引导大概讨论下技术实现方案，具体的细节之后再讨论。
除了开发团队内部小范围的讨论外，还有设计团队，不过设计一般不在需求评审会上讨论了，毕竟，设计基本上不会影响到产品需求的变更。
定下开发周期（诞辰）
如果评审顺利的话，就可以直接定下开发周期了；如果不顺利，那就放在评审后吧~上周评审时就各种不顺利，三场评审后还加了一场开发周期的确定...祝愿以后一切顺利吧！
3、评审后
会后及时输出会议纪要，罗列出会议中有争议仍待解决的问题、改动的部分和结论，将完善后最终更新过的需求文档发送给参会人员，通知需求评审已完成。之后对问题进行跟踪，保证评审结果的落实。
总结
能否在产品需求评审会议中如鱼得水，提高需求评审的效率，我觉得前期的准备工作很关键！
