产品经理「需求评审会」通关指南！
作者： 点击量：
2015-12-05 13:57:07
内容导读：
森普软件专业致力于软件定制开发，依托一整套成熟的服务体制和工作流程为客户提供高质量的软件系统顾问咨询、实施和售后等一系列优质、快速、便捷的服务，详情咨询：400-677-0389
产品经理组织的「需求评审会」类似多方会谈，与会人员很容易进入角色后产生「自主」情绪，形成正反两派甚至是多派，最后由「讨论」演变为「辩论」，有点类似「奇葩说」的形式。产品经理在这个「辩论」的过程中，不断展示自己的观点，希望获得更多的认可，可不少产品经理都在这个「辩论」的过程中把自己搞的伤痕累累，十分狼狈。
关于「需求评审会」的个人目标
产品经理需要明确自己在这次「需求评审会」的个人目标是什么。这个目标是制定给自己的，而非给团队制定的，说白了就是通过「需求评审会」达到什么效果。
比如：让开发团队、测试团队的同学能认同自己本次迭代的产品方案，这是一个非常务实的目标。
比如：让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试，这是一个展示设计团队的目标。
比如：向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力，这是一个偏个人的目标。
虽然出发点不同，但这些都算是一个前置条件。
关于「需求评审会」的原则
一、「不要试图将自己的想法移植到别人的大脑中」
首先产品经理需要明确一点，我们召开「需求评审会」不是为了「移植想法」到别人的大脑中，而是通过「引导」和「讨论」磨合得出大家都认可的产品方案。
我参加过不少「需求评审会」，产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求宣讲，产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中，可想而知这个过程是多么的痛苦；双方又为了「说服」彼此，必然会找出自己经历过的项目中比较极端的案例来支撑自己观点，可想而知这个过程又是多么的火爆。
其实产品经理和开发团队、测试团队应该是一个「配合」的过程，也就是说在产品经理的基础方案上，不断的优化和调整的过程，如果开发同学有更好的想法，产品经理就应该去采纳。可现实情况是，很多产品经理碍于「面子」问题，总觉得必须听我的，别人说的「对」或者「不对」我都不管，一直在单方面的坚持自己。这就很没必要了，对吧？
二、「不要在不同观点上过于纠结，浪费时间」
我们本着「求同存异」的观点来进行问题的「讨论」，也就是说大方向相同，小细节可以有不同观点，并且鼓励大家表达出自己的观点，产品经理的「开放」心态是很重要的。
在整个需求评审的过程中一定有不少大大小小的问题，对于彼此认可的地方我们确认完毕后快速带过，对于彼此不认可的地方我们不再纠结，如果讨论了5分钟以上仍然没有结论，产品经理就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。
我经历过一场很煎熬的「需求评审会」，从下午13：30一直持续到19：00左右仍未结束，原因就是由于产品经理没有控制好问题讨论的时间，以及细节讨论的颗粒度，导致需求评审的战线拖的很长，而且效果非常一般，大家苦不堪言。
三、「要给所有人明确本次需求评审会的背景及目标」
很多产品经理在「需求评审会」刚开始的时候就讲交互流程，功能feature，这是大忌。大家都还没有摸清状况呢，怎么会进到你的流程中呢？又怎么能找到里面的细节问题呢？又怎么会认可你的方案呢？
所以产品经理在最开始需要给大家「调频」，让大家都到一个频道上来。其实就是需要产品经理在「需求评审会」开始后先别急着讲交互和功能，而是给大家介绍一下我们这个版本要「做什么」，「为什么做」，「有什么价值」这三个方面（其实也是做产品规划时需要考虑的），这也就是所谓的背景和目标。
这里其实也符合「金字塔原理」中的背景→矛盾→问题-解决办法的思维模式，我在曾经的文章中有做详细的描述。你可以点击查看：产品经理必备技能：金字塔思维。
四、「不管现场状况多么恶劣，产品经理不可露怯，不可红脸，不可出言不逊」
在「需求评审会」的现场难免会遇到各种意外的状况，不管发生了任何事，产品经理需要时刻谨记两个字「隐忍」，不管任何观点都要冷静客观的表达出来，千万不要没有控制好自己，把某些观点加上了自己的主观色彩，这样就把一件简单的事变的复杂了。
关于「需求评审」的三个阶段
第一阶段：「需求评审会」前
产品经理在这个阶段需要注意几点。
提前3天与开发、测试、设计等团队沟通协调时间，确保关键角色都有时间可以参加，最后确定好「需求评审会」的时间安排，订好会议室，发出会议邀请，并拉好RTX工作讨论组周知大家。简单来讲就是：哪个版本、哪些人、在哪、开会。
提前2天将「产品交互原型」、「产品需求文档」通过邮件及在RTX讨论组发文件的形式发送给与会成员，并严格要求与会成员必须抽时间查阅相关文档，并提出自己的问题。
提前1天收集大家对于本次评审内容的问题，汇总好问题后逐一解答，以邮件的形式统一回复给大家。根据问题修改文档，最后再次提醒大家「需求评审会」的时间、地点。
这也就是「需求评审会」的黄金72小时。我们要利用好这72小时，提前做好准备，将会大大提高「需求评审会」的效率，而且可以有效降低产品经理被误伤和蹂躏的概率。
第二阶段：「需求评审会」中
「需求评审会」说白了就是一次面对面的「讨论会」，所以「中」这个环节是重中之重，不可怠慢。因为之前我们已经做了充足的准备，所以要放松一点，当成自己的「脱口秀」演讲就好了。
告诉大家我们这个迭代要为用户讲一个什么故事（做什么），这个故事是怎么来的（为什么做），用户看完这个故事能得到什么（有什么价值）。这也是一个标准的背景和目标陈述的方式，切忌上来直接讲交互、讲功能，同时还要回想一下自己对于这次「需求评审会」的个人目标是什么。
好了，我们进入到真正的主题了，开始讲解这个迭代的功能点、产品交互原型、产品需求文档，每个功能点逐一讲解，事无巨细，不要有任何遗漏。讲解的顺序一定是先从功能点开始，然后讲原型，最后才是需求文档，一个由点及面的过程。
这时候我们普遍会遇到这几种状况。
第一种：你认可我的方案，这种是最理想的状况，也是产品经理最期望的状况，撸起袖子开工就好了。
第二种：你认可我的方案，但你有更好的想法，这也是一个非常和谐的状况，整个屏幕满满的充满了爱，优化细节，只会让产品逻辑和策略变的更加完整，这种状况甚至要好过第一种。
第三种：你不认可我的方案，你有更好的想法，OK，我们在这个状况下先讨论下关于背景和目标，这些你是否认可呢？如果认可目标，那我们来听下你的方案，如果确实可行，我来调整，然后撸起袖子开干。如果不认可目标，我需要不断的说服你（这里需要控制时间），让你认可这个目标，然后再撸起袖子开干，只不过这种很少见到。
第四种：你不认可我的方案，但你也没有更好的想法，这个…你确定这个人不是无间道吗？这种情况也非常少见。
③经历了暴风雨后，我们已经可以看到了一些曙光了，稍安勿躁，胜利是属于我们的。这时候「需求评审会」其实已经接近尾声了，只是要提一句，关于细节讨论颗粒度的问题，讨论双方必须站在同一个层面讨论，已经下结论的地方不再重复，只讨论同一个纬度的问题，不能我还在跟你讲功能需求，你已经在跟我讨论代码的指针应该放在哪里。
噢，对了，所有讨论的问题记得都写在本子上。
第三阶段：「需求评审会」后
①会后及时输出会议纪要，罗列清楚问题或者争议点，已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。
②最后的最后，一封华丽丽的邮件周知给全部与会成员，邮件内容包括需求评审的争议点和结论，最最最重要的是要将更新后的需求文档发出来给大家。
③最后的最后的最后，督促开发、测试同学评估开发、测试周期，给出时间节点。
以上，一次费心费力的「需求评审会」终于完成了，从开始组织到最后的确认邮件，无一不饱含产品经理的汗水和泪水，但是一次好的「需求评审会」是会为产品的健康成长增加助力的，所以再多的付出都是值得的。
从目前实践来看，产品经理在「需求评审会」上最好的开场就是自我总结，并且送上酸奶。一般比较复杂的迭代，在开场的时候我都会先总结一下自己在上个版本中作为产品经理，自己的过失有哪些，不要琢磨这么做是不是丢面儿了，其实开发和测试同学也都非常关心产品，所以想知道产品层面决策有哪些是对哪些是错。而这种态度，是非常能够得到他们认可的。我们不是经常说，产品如人品吗？就是这个意思。
选购都难：
本公司主要为山东地区的商业、企业单位及个人提供各类定制开发服务，如：软件定制开发、APP定制开发、微信定制开发以及P5业务支撑平台等整体的信息化解决方案，能够满足各种大中小型商业、企业及个人的需要。
如需了解本公司的详细业务情况，敬请访问本公司官方网站：http://www.simpro.cn。
公司名称：山东森普信息技术有限公司
公司地址：济南市高新区齐鲁软件园C座3楼
公司网址：http://www.simpro.cn
业务ＱＱ：176099777
联系电话：400-677-0389
业务咨询
我们的微信
我们的微博