个应对策略践行产品经理反怼指南
⇨⇦
作为一名产品经理，不仅要具备合格的专业技能，还要具备额外的buff加成——＂反怼＂。有句话说得好＂学不会反怼，妄为产品人＂，有理有据的＂反怼＂是一门功课，下面看看笔者是怎么介绍的吧：
没有被人怼过的产品经理，职业生涯是＂残缺＂的。不管身处大厂还是＂小作坊＂，争吵无处不在，想转身退出，可谓是＂痴人说梦＂。正所谓：有人的地方就有江湖，人就是江湖，你怎么退出？
被怼和怼人，一般也都不会按照套路出牌，但这不妨碍我们可以进行一个大致上的复盘。这就像和别人吵架一样，不管吵赢了还是吵输了，我们都会在吵架过后反复思考：如果刚才我那么说，是不是就占据上风了。
回想自己这些年的产业道路，大致和谐，但也不乏与RD、QA、POM以及各路业务方的＂口角厮杀＂，其中的主要场景与应对策略总结如下：
我和你说，这是需求不明确！
这句话就像一把刀，插入PM的胸膛。它会出现在QA、UI、RD等人的口中，会出现在需求评审期间，会出现在测试用例评审期间，也会出现在BUG出现的时候。它也像一把万能钥匙，具有相当的普适性。
当面红耳赤、头脑发胀，想要挽胳膊撸袖子、赤膊上阵的时候，先别着急。
＂想问为什么，要先知道是什么＂（关于＂是什么＂，我们时常经历，本文就不过多赘述了），然后再考虑怎么应对，最后需要知道以后该怎么预防。
1. 应对策略
（1）万能的＂静一静＂
怼是一个一二三木头人的游戏，谁先动，谁就输了。当然，PM在项目推进中的争吵目的不是口头上的输赢，而是达成既定的需求目标。
在被人指出需求不明确的时候，不要急于反驳，＂静一静＂这一点很关键。
指责与反驳都会存在出发点，你需要一点点时间，找到对方的出发点：
需求本身存在问题，业务场景覆盖不全或存在未处理的异常场景等问题；
需求隐藏了大量潜在工作，这些工作量未能通过需求文档的字面意思体现出来；
需求描述存在模棱两可之处，而开发人员自然而然地选择他们认为工作量小的那种。
以上等等，我们都需要一些＂静一静＂的时间来思考，借以明白当前这次被怼，是因为什么。
（2）聪明的＂以退为进＂
在弄清被怼原因之后，我们可以选择这样的话术：
＂嗯嗯，好的，你看问题我们已经明确了，你觉得现在这种情况，咱们应该怎么处理呢？＂
这种看似把决定权给对方的交流方式，不仅可以缓和气氛，还可以让对象充分表达他们的看法，更给了我们PM深度思考的时间。
不要急于表达或者争辩，要给对方充分的时间来释放情绪，同时我们也得以倾听到对方在＂怼＂背后的真实诉求。
（3）和谐的＂求同存异＂
其实，该补充的异常场景处理，终究还是要补充的。该解释的需求模糊点，也终究是需要解释的。但什么时间来处理，需要产品经理决策，也需要开发与测试配合。
这里存在两个判断点：
需求不明确之处，已经采用了某种不太合适实现的方案或者压根就没有进行处理，对用户存在不大的影响，是否可以延期至下期处理；
需要补充和处理的需求，需要我们付出多少成本，是否对项目预期上线时间产生影响；如果产生影响，如何进行需求优先级的重新排列；
求同存异，最终得到团队可以认可，用户可以满意的方案，皆大欢喜。
2. 预防措施
治病不如做好预防，防患于未然，我们在产品设计与需求输出的过程中，我们可以遵守以下两个原则：
（1）业务场景覆盖充分
业务场景不是产品设计出来的，而是源于对实际业务的抽象，需要PM进行需求挖掘。
对于业务场景的分析，我们要尽量完善，哪怕是不能覆盖的业务场景，也需要预留提示策略与引导策略，不要让用户在使用过程中出现断崖。不过还要学会取舍，不能因为低频场景，把系统复杂化。这个度的拿捏，需要不断锤炼。
（2）异常场景处理到位
如果正常流程的设计与创新是PM基本功中的进攻能力，异常场景的分析与处理就是PM基本功中的防守能力。
关于异常场景的梳理与处理方案，有很多现行的方法，如MECE法则、穷举回归法等等。大家可以在项目实操中一一尝试，针对这部分的内容，之后我也会单独行文。
其实某种程度上异常场景就是业务场景的一部分，同样要遵循＂不必面面俱到，但是用户在使用产品的过程中可以自洽，可以形成闭环。＂
重点补充：需求文档是需求输出的一部分，但需求文档是测试人员与开发人员进行各自工作最重要的基础与依据，当口述的需求在文档中了无痕迹的时候，这就是埋雷。好记性不如烂笔头，古人诚不我欺。
估时就这么多，你砍需求吧
开发人员估时是一场不见硝烟的战争，因为产品经理大多＂无力＂控制开发人员的估时，就算对估时不满意，也很难说服开发缩短估时。不压缩工期，就意味着砍需求，这里可以引入一个＂纳什均衡＂的博弈论概念。
要记住不要信心满满地对业务方许下承诺，因为开发人员的项目估时可能会给我们当头棒喝。项目时间在理想和现实碰撞的时候，该怎么办？难道要高喊：＂砍我可以，需求不能砍。＂当然不能，我们可以这样做。
1. 应对策略
（1）明确需求背后的业务目标
首先，我们需要向项目成员再次进行需求阐述。这里不是重新复述我们的需求文档，而是向项目成员阐明需求背后的业务目标，也就是说明白＂之所以设计这个功能是为了解决什么样的问题。＂
这样便于开发人员提出他们的解决方案，大家都经历过很多项目，总会有相似点。让开发人员明白他们工作任务背后的业务目标时，很有可能会给到PM意想不到的点子。
（2）时间长度固定，尝试加强深度
如果项目时间相对固定，我们也可以尝试增加时间的深度，这里有以下几种方式：
寻找更多的项目资源，俗称＂加人＂。不过抢资源这种事儿，要么自上而下、要么哭天抹泪，没有死皮赖脸的劲头儿，那真的有点不好办；
适度地提高工作效率或者相对＂残暴＂地增加单日工作时长，俗称＂加班＂。其实减少日常摸鱼时间，没准直接就效率翻倍了。
作为产品经理，能直接说服项目成员加班，那绝对是纯正的革命友谊。
（3）尝试寻找替代方案
从A点到B点从来都不会只有一条路，现有的产品方案只是N种可能中的一种。
如果在加人加班都解决不了问题的时候，产品经理就应该考虑或者说需要提前考虑，是否存在替代性的产品方案，可以在满足用户核心需求的同时减少工时。
2. 预防措施
（1）项目经验积累归纳
项目估时有点卖油翁的感觉——＂无他，唯手熟尔＂。
项目做得多了，做好归纳，自然而然地就会对各类组件与交互的实现时间有所了解。不过这种事儿大都出现在＂饿汉子＂家，对于开发资源富得流油的PM可能就没这种体会了。
（2）做个懂点技术的产品经理
产品懂技术，谁都挡不住。不过切忌在＂一瓶子不满，半瓶子晃悠＂的时候，对开发的工作指手画脚，这就像开发不能直接用Axure帮我们画原型一样。
我们不一定会熟练地写代码，但是如果能看懂代码，并知道大致的逻辑，这肯定是个加分项。向开发请教他们擅长的，不仅可以让我们在日后估时这件事上占据更多的主动性，还可以增进我们与开发人员的感情，一箭双雕。
都要上线了，你怎么又改需求呢？啊！
你怎么又改需求呢？什么你没修改，那这是神仙变出来的吗？对对，你这不是修改，你这就是纯粹的加需求？
上面的话，熟悉吗？
有人笑着说，就这一次，保证，保证下次不改了。有人无奈着说，不是我要改的啊，是老板说的啊。
有人说……
1. 应对策略
在这种情况下，话语是苍白无力的，我们也很绝望啊。不过为了缓和这尴尬的气氛，我们可以尝试讲一讲，需求修改背后的故事：
需求是业务方提的，公司业绩是业务方挣得，咱工资是公司给的。换言之，业务方就是咱衣食父母昂，你说爸妈提点意见怎么了，看在今天中午外卖有肉的面子上，你就从了吧。
如果，你真的这么说了，估计很有可能被＂活活打死＂。
需求背后是业务目标，更好地实现业务目标是项目组工作输出的意义，应对这样的问题，两个参考方向：
向需求修改提出方阐明修改需求的成本，争取更多的修改时间；
向项目组成员阐明本次需求修改的出发点，在获得理解的同时，协助项目成员进行方案评估，必要时申请更多协助性项目资源；
最怕唯唯诺诺，上面说什么，你就做什么。做需求修改，要有理有据，也要有情有义。
2. 预防措施
项目进行期间，想要需求封闭，可谓是可遇不可求。
需求变动的预防，我们能做的是在前期做好业务调研、做好产品设计，这里面可以尝试进行功能解耦，这样会降低变动修改的代价。
至于完全杜绝需求变动，来吧，请天降神兵。
以上内容是产品经理一部分被怼的场景，更多案例就不一一描述了，可谓是：满纸荒唐言，一把辛酸泪。
但我们应该看到：如果项目开始前，我们做到需求明确、场景清晰，项目进行中可以做到需求相对封闭，那被怼的概率基本可呈几何指数下降。
产品经理这条路，并不是一路坦途，双脚沾泥，静水流深，且怼且珍惜。