产品经理与开发相爱相杀， 评审会上互怼更是少不了，是否有方法可以让评审更顺利进行呢？
湖畔大学产品模块学术负责人、著名产品人梁宁在《产品思维30讲》里，提到了产品人，应用了丘吉尔的一句话“如果你到了地狱，那就继续保持前行。”
如果把产品的日常工作中一项重要的内容——“评审”算作一个。那么，这绝对可以算得上是“走向痛苦中”去，而又不得不每天面对。
记得之前发生过程序员和产品经理因手机壳颜色而打架的事情，媒体闹得沸沸扬扬——真是一对生死冤家的既视感。
作为产品人一枚，笔者也深知，产品评审是推动产品落地过程中非常重要的一环。产品方案是否能通过是一项重要日程。做不好它，前期的许许多多的工作都白费了，还落一个不讨好的下场。
如何科学面对其他开发的怼？
如何优雅的回怼？
开发说这个功能实现不了怎么办？
其实绝大多数的问题并不深奥，但依然困扰着大家。评审不好，项目止步、没有NB作品、职业生涯受阻……各种心酸涌上心头。
如果遇到此类事情，有没有更好的办法去处理呢？
作为以解决方案为生的产品人，我们应该有自己的“解决方案”，去打破这些评审过程中遇到的“牢笼”吧！
下面跟大家分享8招带你走出困境的方法。
在说这8点评审建议时，我觉得还是有必要去回顾一下这个关键词：会议。
只有知道我们做的是什么，才能做得更好。
01:
在这里，并没有什么大咖开会议的绝技跟大家分享，只分享一本关于会议的书籍：美国Tim-hindel所著的《会议管理》。
在全球范围内，每天举办的大大小小的会议不下几百万场，而这些会议是否成功，是商务效率的一个重要指标。
我们可以想象，在旅途疲惫，穿越万里之后，来到一家公司参加一个合作协商的会议，在会议上并没有达到一些重要的成果。从投入产出比角度，这一趟旅途浪费的成本，平均每个经理人至少上万元；但后面，产出效果几乎为0。
产品评审会也是会议的一种，它的目的是达成某个决策和方案。当然，这是一种正式的、目标性极强的会议，即要开了，就要开得有效率一些；否则，走过场根本是没有意义的。
《会议管理》这本书把会议流程分为了准备会议、出席会议、主持会议。
准备会议阶段
要安排好时间、地点、座位等方面的工作。
当然，有些公司在评审的时候，需要用到电视、投影仪、电脑等电子设备的辅佐工作。这方面需要提前进行调试和准备，防止在会议开始时再进行调整，让一干人在评审室里干等，确实也是沉闷的。
出席会议阶段
提到了重要的5点：
积极参与
外表和讲话
倾听发言
处理问题
做备忘录
主持会议阶段
这本书里重点提及到了一点：研究出席者。
这并不是耍滑的需要，它的目的是知道参会人是谁，并且尊重与会人员。例如：在出席者中，包含了相关者（业务直接相关）、协助者（帮助完成某个功能或业务的解答等）、参与者（参与但不发言，主要做同步、理解内容等，例如运营、客服等部门）。
02:
基本了解了会议的情况后，我们会提出8招建议。
这8个建议，是针对我们熟知的8个被怼被质疑的场景，以及对应的解决方案。
场景一：为什么要这么做？
在评审会上，一上来你跟他们解释一通，这个功能怎么做，甚至零碎地把多个功能一起进行解说。他们一脸懵逼，然后回了一句：“为什么要这么做？”
参与评审的同事在理不清原因的时候，一般都会这么问。他们的出发点很简单，就是：人性的疑虑，他们疑虑你所设计或迭代的功能。背景是什么、为什么这个时间段就要做这个、是否有必要或做了有什么好处。甚至，从他们本身自由的需求、私心角度，也会进行质疑。
于是你再次解释一通，总算把他们的疑惑进行安抚了。甚至，解释了一通，他们还是一脸懵逼。
为什么不提前进行说明功能的目的呢？而等到他们质疑时候才解释？实际上，这样浪费了前面的解说时间。
时间就是效率，浪费时间，就是降低了效率。
造成此类质疑局面的原因，在于想不清楚，表达不清楚；本质上，还是想得不透。
这里，推荐一个提问工具：丰田五问法（日本丰田专家大野耐一提出）。简单来说，针对一个问题，连续问5次，直逼本质的提问、层层递进。
以下是一些参考：
为什么做这个功能？
目的是什么？
有什么优势？
解决什么问题/？
有什么数据、论据的支撑吗？
当然，还有其他的自我提问的方法，这里就不细说了。
场景二：这个场景/因素/……方面有没有想到呢？
假如你是某个电商网站的产品经理，电商集团需要对订单系统进行统一优化，优化方式包含了文案、ICON品牌识别、功能等方面。作为产品经理，在评审会上，把优化的订单功能的页面，放在了订单详情页、列表页入口等位置。但帮助中心-订单的位置和订单结算的位置，你并没有考虑到。
毫无疑问，说开火，就开火。
开发或测试同事，会持续向你施压：
“这个入口都没有啊”
“你让用户在订单结算这里看到的是旧品牌，在首页上看到新品牌，他们就懵逼了”
“你都没有想清楚，就来说”
……
对方的立场告诉你，你的工作是处于盲目优化的地方，很多都没有考虑到。
作为产品经理，你会怎么办？
首先，心态放平，态度谦虚（确实是你想的不周到），记录下来，评审后及时修改并同步即可。
那么，如何处理这种被遗漏的情况呢？
推荐一招：MECE法则（互相独立，完全穷尽）
MECE法则要求我们把各种相关的情况都要想清楚，不遗漏。当然，这是最佳状态。
在考虑事情的时候，我们不妨从时间轴、次序、渠道、相关性等方面进行考虑，把产品方案想得更加完善。
说不定，下次评审时，一些想不到的地方你都想到了，也许开发会向你投快来钦佩的眼光。
场景三：这个方案并不是最好的
在评审环节，我们也会遇到这个情况。那么，开发、测试、UI等同事，就这么来一句，或许会让你胆战心惊。
但别怕，应该这样处理：
如果是对方感觉不对，但又说不出为什么，那么，仍然按照这个方案，但可以底下再讨论。
有更好的方案。
我们也许不相信开发、测试对产品的品味（这当然是不对的，产品人需杜绝高高在上感），但他们确实提出了一些方案。
如果方案较为离谱，那么自然是不过了。反之，如果方案比较靠谱，你自己又觉得比你的好，怎么办呢？
我的答案是：接受、认同并探询细化这个方案。让他们帮你一起想方法，提高了参与度，何乐而不为呢？要知道，评审会绝不是产品人一个人滔滔不绝的演讲，它也是一个沟通的会议。
如果开发或测试仅站在他们自己的角度，去吐槽这个方案（比如开发的技术难度较大、测试繁琐）。此时，你要做好你的坐骑了，径直往前走。
场景四：太啰嗦了，到底想表达什么？
评审会上，你自信满满地表达了一通，但遭到了评审参与同事们的不理解。当你表达完成后，他们会质疑：“你到底要表达的是什么？”
站在对方的立场，主要原因是他们确实听不明白你说的是什么；功能很多，他们听不出重点在哪里。
质疑的问题带来的痛苦，更多的是来自能力本身。
试想，如果一句话能讲完的事情，要拆出2句话甚至5句话讲，听的人不耐烦，说的人也累啊。
何不简洁、高效一些呢？
这里有个训练小技巧：在你设计功能之前，看能不能用一句话表达出来功能的目的。
这里推荐一个工具：黄金圈思考法，通过提出what、how、why的方式，促使大脑思考和解答问题。
场景五：用户量有多大？开发成本太高了
这是让很多人“一句语塞”的话。
真的，你告诉我用户量多大。如果很大，我立马给你开发。
用户量不好评估，难道就这样乖乖就范吗？
“你能告诉我，微信开发语音对讲功能时，有多少用户量？
你能告诉我，微信开发“附近的人”的功能，有多少用户量？”
……
不好意思，还是通不过。
这叫只看趋势，不看自己。
当然，你也可以跟评审同事们讲，竞品都有这个功能了，我们为什么不做呢？
这叫只看竞品，不看自己。
我认为、我觉得，这些话也杜绝说（不是尽量）。
好，既然是你认为、你觉得。那么，为什么要这么做？你的判断被质疑了。
人格没有被质疑、专业被质疑了。
于是，要么默默忍受，要么开启回怼模式，战火不断……
举个例子：你在产品的订单列表上，增加了一个搜索功能。在评审会上，你把原型展示后，开发来了一句：“用户量有多大？”
如何做呢？这里的解决方案是：
可以拿量化的，尽量拿量化
不可以拿量化的，拿自然而然的逻辑，简单到无法反驳。
杜绝：拿感觉、拿竞品、拿大咖、拿公司领导镇压……
什么意思呢？
量化的数据包含了：
你真的知道这块产品会有多少用户量；
你从市场同类数据中，找到了用户使用量。
你从兄弟部门的埋点中，拿到了这个比率；再乘以用户数，就得到使用量。
——这是量化
什么是拿逻辑呢？
就是从A推导出B的吗，比如：美图APP，除了修图之外，能不能加个拍照呢？
这是简单到不能再简单了。美图，就应该增加拍照功能。这是自然而然的。
当然，还有其他的方法，还有一个绝招，就是开发非常信任你，你打个招呼，提了一些，他们立马就做。
这是建立在你的专业能力之上的，如果你是这样的人，请忽略刚才所提到的建议。
场景六：跟之前方案对比，这样做的目的是什么？好处是什么呢？
例如：某电商网站浏览记录入口功能，放在二级页面还是一级页面呢？评审会，开发问你，为什么要把入口前置？
对方的立场是：这是功能的迁移问题。
首先，请杜绝抛出这样的一句话：“这个功能很简单就能实现啊。”
好的，那我们遇到此类提问，如何解决呢？
此时，你要明确告诉对方，优化这个功能的作用和意义。
有以下的告知策略可以参考：
成本优势/投入产出比；
用户路径优势
心智认知优势
产品体验优势
例如：把这个入口放在一级入口，用户会更加方便进入这个最近浏览的页面。之前调研了浏览记录页面的Pv和uv，量级非常大，可见用户还是比较在意这个入口的，能减少直达商品详情页的路径。
这是从用户路径上的说明，其他几点你也可以进一步展开。
场景七：砍掉这个功能，不做
面对这个场景，辛辛苦苦做好的功能，说不做就不做，自然士气被打击了。
当然，也不能糊里糊涂功能被砍掉啊！
建议：
咨询提出决定的这名同事，他/她的回答可能有以下几种：
功能太臃肿了；
很明显不合理，直接下答案；
看你不爽。
遇到这个情况，作为产品人，我们自然不爽。辛辛苦苦孵化的“功能”，咋能说不做就不做呢？
于是，我建议以更加客观的态度去审视他们的回答。
如果功能真的是很臃肿，要倾听是否真的是这样。要知道，这种情况很常见。笔者在开过的评审会中，回顾来看，确实是有许多的功能显得有些臃肿，这是考虑不周全所致。
但如果真不是你的问题，那么就要据理力争。
可以从以下几个方面跟对方阐述，为什么要做这个功能：
强调产品的用户价值；
强调产品的企业价值；
强调产品的优势和解决的问题
适当时候，可以拿上级领导指示说明（不得已）。
杜绝：一味强调产品功能是多么好，要知道，如果产品确实是好，评审要不一定过，现场的评判非常重要。
心态飘起来，跟对方硬抗，严重不建议。
场景八：历史原因，这个功能实现不了
这句话是不是听到油腻了？或者至少听过。
在评审过程中，如果听到开发这么说，也不要着急，你的工作还没有白费。
产品人要善于审时度势。此时，要跟对方进行进一步“切磋”。
那么，在“切磋”过程中，可能会遇到以下几个方面的情况：
1）是否真的实现不了？
行动：妥协或坚持
2）是否有曲线救国的策略?
行动：采用
3）是否可以部分修改，功能也要实现？
行动：妥协且坚持
告知对方，会后进一步讨论这个功能的取舍或采用其他的解决方案。
以上，就是8条产品人常遇到的问题及对应的建议了。
为了少走弯路，提高科学评审的能力和水平，还是建议产品人把评审这一步修炼好，做好产品前的准备功夫。
即使没有遗漏做得妥妥当当，在评审中还是会遇到许多的质疑、追问、妥协、被怼等情况。不用急，见招拆招，做好一个产品评审，为后续的产品落地的硬仗（产品进度管理、突发情况等）做好准备。
这又是精彩的一仗了吧！
