如何让PM完成需求评审而不被打？
如果说产品经理的生涯是一条修炼之路，那么需求评审就是产品汪躲不过的劫。
做不好需求评审的产品经理，很可能会对产品生涯产生阴影，因为每一次需求评审都是对产品经理的多人毒打。
心态好的产品经理能每次爬起来完成蜕变，而心态不好的产品经理，很可能会被实力劝退。
尤其是对于新手产品经理，或者是新加入一个团队的产品经理来说，第一次需求评审将决定你在团队中的印象，也将决定你日后的日子是苦是甜。
如何让产品汪完成需求评审而不群殴，本文从需求评审前，中，后三步来谈一下我工作中得到的经验。
一、需求评审前
正式需求评审前，一定要进行一次需求预审。
大事都是在小会上决定的，而大会只是做一个详细通知和布置具体的任务。
需求预审的参加对象，是产品经理、前端主管、后台主管，一般三个人即可，或者是前后台的开发主力。
预审的目的有两个：
- 明确需求能不能实现
- 验证需求文档的主要逻辑没有问题
明确需求是否可以实现。有时候一些想偷懒的开发，面对一些复杂的需求，就会以“这个做不了”来推脱。
这个时候，你把预评审的结论说出来，他也就熄火了，就不至于陷入扯皮的尴尬。
验证需求文档的主要逻辑。大会评审的时候，如果主要逻辑出现了问题，那基本上可以确定要再进行一轮评审，这样不仅浪费了大家的时间，还可能让自己被贴上不靠谱的标签。
需求评审前，一定要提前发评审邀请。可以是邮件，也可以直接在工作群邀约。
但是一定要有提前量，这样可以让开发预习一下，提前把问题准备好，提高大会评审效率。
评审邀请，如果是写邮件，发送邮件前，也最好在群里跟大家约一下时间，免得出现时间冲突的情况。
邀请邮件的内容一般包括：
- 需求的背景，便于理解
- 需求的功能列表（不需要太细）
- 需求文档链接，看团队习惯
- 会议主体、会议时间、地点和参与人员
邮件发完以后，记得在群里和大家同步一声，免得有人漏掉邮件。
二、需求评审中
需求评审的步骤大致如下：
并不是每次需求评审都需要完全按照这个流程，比如是迭代型的需求，就不需要走第二步。
需求评审，本质上就是沟通，用语言配合原型文档的方式，将需求清晰的表述出来。所以，一定要明白我们和其他人之间，肯定存在知识诅咒。
所以，不要一开始就讲细节，不要一开始就讲细节，不要一开始就讲细节。
细节是永远都扣不完的，如果在会议上陷入细节的讨论，不仅浪费时间，而且对于产品经理来说也会非常痛苦。
因为总有一些细节是你没有想到的，而且你会发现，一到这种时候，大家都非常兴奋。
因为谁都会挑毛病，而且大家都非常乐意挑别人的毛病。所以不要找不自在。
而且陷入细节的需求评审，会显得毫无逻辑。大家很容易一脸懵逼，特别是对于没有提前看过文档的同学（不幸的是，大部分同学都不会提前看文档）。
在正式讲解需求之前，一定要先明确本次会议的主题，会议需要完成达成哪些目的。主要事项有哪些，让大家心里有底。这也是串起整个会议的主线。
正式开始需求评审后，首先要做的，就是要和大家达成一项共识：为什么要做本次迭代。也就是这些需求能带来哪些价值。
而不是说那句表面上让大家无法拒绝，但是实际会非常掉底子的一句话：这是老板的需求。
一般的需求价值包括：
- 需求符合公司的战略目标吗？
- 需求能带来直接的收益吗？
- 需求能提升用户体验吗？
- 需求能提高效率或节省成本吗？
和团队成员达成共识的目的，是为了防止大家出工不出力。和大家就这些需求的价值达成一致，有助于更好的完成需求开发。
毕竟一个人从内心认可一件事的动力，和因为外力强迫不得不做的动力，那是天壤之别。
讲解需求要从整体到局部。不要一开始就扎到细节里，否则大家也会跟着你去抠细节。
而需求评审并不是抠细节的，需求评审的主要目的是：
- 传递需求的价值，让大家认可这个需求可以做，而不是被强迫
- 传递功能的场景，让大家理解功能所覆盖的用户和使用的场景
- 明确需求实现的方式，划分大致的任务和排期
我们要先从整体对需求的流程做一个梳理。一般都是从用户的角度，对用户使用这个功能的流程进行一个整体的梳理。
就像你在看一本书时，当读到一半的时候，就忘记之前是讲什么的了。
我们会发现很难将书中的知识串起来，这个时候往往都会选择打开目录，通过看目录来帮我们回忆起之前的章节内容，从而将这些内容都串联起来。
需求评审如何从整体开始？我们以优惠券需求为例。
评审优惠券相关的需求，就可以从优惠券的创建、优惠券发布、优惠券领取、优惠券消费。
这四个大的步骤进行整体的概况说明。以此为需求评审的主线，这样大家在听你讲解具体需求的时候，不至于迷失在细节之中。
接下来，描述该功能的使用场景。我认为产品经理，最强大的软实力，就是讲故事的能力。
如何用一个故事把自己的想法表达清晰，让大家易懂，并且得到大家的一致认可，是产品经理最难能可贵的能力。
在讲解具体功能逻辑之前，可以先描述下具体的功能使用场景。
这样有利于大家理解这个功能：
- 功能的用户是谁？
- 用户通常在什么场景下使用这个功能？
- 用户当前在这个场景下遇到了什么困难？
- 我们的功能是怎样帮助用户解决问题的？
以场景的角度来描述功能，同时也是进一步让大家理解做这个功能的价值所在。
而且产品经理在思考功能的使用场景时，也是进一步思考是否有必要做这个功能？怎么做这个功能才更好的机会？
而且，让大家明确该功能的场景，有时候会有惊喜。有时候对于一些你认为比较复杂的功能，大家在明确背景的情况下，有可能可以想到更简单的方案。
详略得当，不要毫无重点地长篇大论。哪些该讲？哪些不该讲？
这个要看团队之间的默契。如果是初期合作，大家都不太了解彼此的时候，建议要尽量详细。
不要自以为某些功能很常见，例如输入框的一些交互，就省略不讲，到最后开发没做，就只能自己背锅。
对于配合默契的团队，可以根据团队的习惯，忽略掉一些以前做过的东西，或者一些常见的东西，比如输入框的校验规则等。
回答并记录问题。需求评审大家肯定会提出很多问题，有的是质疑需求的必要性，有的是指出需求的不完整，或逻辑的缺失，有的是讨论需求的实现方式等。
有的问题可以直接回答，例如需求的逻辑问题，实现问题，必要性问题等。
而有的问题则可以不回答，例如自己没有想清楚的问题，一些比较细节的问题，而且这些细节不涉及其他同学，会后单独私聊就可以解决的。
自己没有想清楚的问题，千万不要因为要面子强答，那只会让自己更丢脸。
如果是简单的问题，可以直接想一下然后回答。
如果是稍微复杂的问题，或者被问住了的问题，要及时认怂，承认自己事先没有想好，先记录下来，会后考虑清楚以后再同步给大家。
在评审过程中，作为会议的主讲人，不仅要传达完整清晰的传达需求，还要控制会议的节奏，不要让会议陷入抠细节的状况，更不要让会议跑偏。
发现有的同学喜欢抠细节，要及时制止，并建议在会后和他详细讨论。如果是跑偏，要及时将大家的注意力拉回来。
会议最后要形成会议结论。
会议结果无非两种，成功和失败。若会议成功，那大家就分配下一步工作。
若会议不成功，有一些需求逻辑待进一步梳理，那就约定由谁来梳理，什么时候完成并重新组织评审。
一定要有结论，谁干什么，什么时候交付，交付物是什么，都要定义清楚。
如果只定义了负责人，但是没有定义交付时间，就会造成拖延，大学生综合征就是典型。
如果没有定义负责人，到最后，这件事大家都不会去做，三个和尚没水喝。
如果没有定义交付物，那他到底做还是没做，就没有一个可以衡量的结果，容易变成嘴炮。
三、需求评审后
需求评审后还不是结束，需要做两件事：
1. 将会议上记录的问题，一个一个落实
需求该修改的地方修改，该找人落实细节的找人落实细节，并且修改好以后，要以邮件的形式及时同步给大家，并且在群里进行简要提醒和说明。
必要的话，可以组织小范围的二次需求评审。
2. 需求评审复盘
记录每次需求评审，大家提出来的问题。将这些问题进行分类统计。
哪些是自己经常忽略的问题，哪些是自己经常被问到的问题，哪些自己明明说了，但是大家还是会问的问题等。
对自己的每次需求评审都做一次复盘，总结自己没有讲好的地方，讲的好的地方，下次该如何改进等。
有的同学说，需求评审的时候忙着回答问题，哪有时间进行记录。
办法总比困难多，你可以每次找一位产品同事帮忙记录（他评审的时候，你帮他记录），或者买一只录音笔录音，这都是好方法。
最后，总结一下：
需求评审前，尽量先进行一次预评审，并提前发出会议邀请，将需求文档等资料提前发给大家熟悉。
需求评审中，会议一开始就要明确本次会议的主题和目的，需求讲解，要从整体到局部，具体的功能讲解从背景开始。
最后，会议一定要形成结论。另外，谨记：一定不要陷入细节！
需求评审后，将会议上的问题一个一个解决，将分配给或需要自己配合的任务一项一项推动。
另外，坚持对每一次需求评审进行复盘，明白自己的问题和优势，有针对性的改进和提高。
本文作者 @Jarvan
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
