告别撕逼大战!产品经理「需求评审会」通关指南!.pdf

告别撕逼大战！产品经理「需求评审会」通关指南！ 你还记得自己参加过多少场「需求评审会」吗？不管自己是作为主机主导，还是作为僚机 配合，「需求评审会」的现场都是让人不明觉厉。而产品经理就是在这一个又一个的「需求 评审会」中磨练过来的，是一个真正刷怪升级的过程。据说「需求评审会」又名「撕逼 大会」，你可以感受下这其中的画面感。 产品经理组织的「需求评审会」类似多方会谈，与会人员很容易进入角色后产生「自主」情绪，形 成正反两派甚至是多派，最后由「讨论」演变为「辩论」，有点类似「奇葩说」的形式。产品经理 在这个「辩论」的过程中，不断展示自己的观点，希望获得更多的认可，可不少产品经理都在这 个「辩论」的过程中把自己搞的伤痕累累，十分狼狈。 关于「需求评审会」的个人目标 产品经理需要明确自己在这次「需求评审会」的个人目标是什么。这个目标是制定给自己的，而非 给团队制定的，说白了就是通过「需求评审会」达到什么效果。 比如：让开发团队、测试团队的同学能认同自己本次迭代的产品方案，这是一个非常务实的目标。 比如：让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试，这是一个 展示设计团队的目标。 比如：向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力，这是一个偏个人的 目标。 虽然出发点不同，但这些都算是一个前置条件。 关于「需求评审会」的原则 一、「不要试图将自己的想法移植到别人的大脑中」 首先产品经理需要明确一点，我们召开「需求评审会」不是为了「移植想法」到别人的大脑中，而 是通过「引导」和「讨论」磨合得出大家都认可的产品方案。 我参加过不少「需求评审会」，产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求 宣讲，产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中，可想而知这个过程是 多么的痛苦；双方又为了「说服」彼此，必然会找出自己经历过的项目中比较极端的案例来支撑自 己观点，可想而知这个过程又是多么的火爆。 其实产品经理和开发团队、测试团队应该是一个「配合」的过程，也就是说在产品经理的基础方 案上，不断的优化和调整的过程，如果开发同学有更好的想法，产品经理就应该去采纳。可现实情 况是，很多产品经理碍于「面子」问题，总觉得必须听我的，别人说的「对」或者「不对」我都 不管，一直在单方面的坚持自己。这就很没必要了，对吧？ 二、「不要在不同观点上过于纠结，浪费时间」 我们本着「求同存异」的观点来进行问题的「讨论」，也就是说大方向相同，小细节可以有不同 观点，并且鼓励大家表达出自己的观点，产品经理的「开放」心态是很重要的。 在整个需求评审的过程中一定有不少大大小小的问题，对于彼此认可的地方我们确认完毕后快速 带过，对于彼此不认可的地方我们不再纠结，如果讨论了 5分钟以上仍然没有结论，产品经理就记 下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。 我经历过一场很煎熬的「需求评审会」，从下午 13 ：30 一直持续到 19 ：00 左右仍未结束，原因就是 由于产品经理没有控制好问题讨论的时间，以及细节讨论的颗粒度，导致需求评审的战线拖的很长 ，而且效果非常一般，大家苦不堪言。 三、「要给所有人明确本次需求评审会的背景及目标」 很多产品经理在「需求评审会」刚开始的时候就讲交互流程，功能 feature ，这是大忌。大家都还没 有摸清状况呢，怎么会进到你的流程中呢？又怎么能找到里面的细节问题呢？又怎么会认可你的方 案呢？ 所以产品经理在最开始需要给大家「调频」，让大家都到一个频道上来。其实就是需要产品经理 在「需求评审会」开始后先别急着讲交互和功能，而是给大家介绍一下我们这个版本要「做什么」 ，「为什么做」，「有什么价值」这三个方面（其实也是做产品规划时需要考虑的），这也就是所 谓的背景和目标。 这里其实也符合「金字塔原理」中的背景 →矛盾 → 问题-解决办法的思维模式，我在曾经的文章中有 做详细的描述。你可以点击查看：产品经理必备技能：金字塔思维。 四、「不管现场状况多么恶劣，产品经理不可露怯，不可红脸，不可出言不逊」 在「需求评审会」的现场难免会遇到各种意外的状况，不管发生了任何事，产品经理需要时刻谨记 两个字「隐忍」，不管任何观点都要冷静客观的表达出来，千万不要没有控制好自己，把某些观点 加上了自己的主观色彩，这样就把一件简单的事变的复杂了。 关于「需求评审」的三个阶段 第一阶段：「需求评审