产品经理和程序员由于所处的位置不同，所以经常会在网上看到对对方的吐槽，实际工作中的撕逼更是不断，大多数缘由都是因为需求不合理而无法实现。面对这些需求，程序员往往会处于一个难堪的境地。

然而，大多数时候程序员的问题在于对于产品经理提出的任何需求，都不能以道理反驳，而只是以直觉说：『我觉得不行』、『我觉得用户没有这个需求』、『我不管我不做』。如果你认为这个需求不合理，请证明它。

就算你觉得产品经理是个傻逼，请有理有据的证明他是个傻逼。不然你跟无理取闹的小孩子没有区别。

so，一个经验丰富的程序员，不仅要懂得技术，还要懂得研究产品经理的心理，甚至懂得给产品经理设置逻辑陷阱，跟他讲道理。

昨晚刷知乎的时候看到一篇特别有意思的虚构故事，其中的案例让人哭笑不得。

大概是说一个产品经理不顾产品信息结构的优先级，希望把一个”帮助入口” 做在首页中间。而且产品经理说服工程师时候以逻辑漏洞的方式进攻，提出诸如 “我作为用户就有诉求，你没有诉求也不能代表大家都没有诉求” 之类的理由。

因为争论无果最后 PM 提出要 ABtest，上线之后那个帮助入口点击率竟然还挺高的，让工程师非常的郁闷。

这些 “难以拒绝的需求”，他们之间往往都会有一些共性：

1）工程师可以明显的感觉到需求有问题；

2）产品经理无法给出客观的需求支撑，但是给出很多”难以拒绝的” 主观理由；

3）争论无果后 PM 会要求做出来试试，但是上线后数据看起来是有利于那个需求的；

所以当遇到这个问题这么办呢？

1、接到需求的时候，不要讨论设计解决方案，而应该讨论需求本身

a. 这个需求根本是达成什么目的？
b. 这个需求需要的优先程度是怎样的？
c. 这个需求需要的衡量标准是什么？
很显然这里的需求就是『提供一个帮助入口』，并且希望可以『尽量帮助有问题的用户』。

2、要追问需求背后的目标和背景

需求的背景和目标是一个完整的整体，只有全面了解了之后工程师才可能给出 ABCD 等不同的解决方案，并且在这些解决方案中分析出优劣找出最优解。

3、设计效果不能只看单一的某个维度

衡量效果不能只看点击率这么一个指标，转化率、留存和用户反馈等都很重要。

4、工程师要更主动的去获取信息

案例里的工程师还有一个很大的毛病就是完全被 PM 牵着鼻子走，通过有限的信息去判断需求和方案的好坏，其实工程师可以自己主动做到对信息的全面掌握（如产品经理的周会、需求评审会、查看数据、向上反馈等）。

必须直接指出，故事中的工程师的立场和沟通方向是错误的。

在这个故事里，事实是：

1. 产品经理提出了一个不完善的方案；
2. 产品经理提出了一个有需求的模糊的场景；
3. 产品经理提出了不适当的追踪反馈的方式。

有个产品想在外卖产品里做游戏，知道不能做，但却找不到有力的拒绝理由。

我猜想产品经理的回答应该是这样的：

1、有时候等外卖太久，用户很无聊，很焦虑，一旦焦虑就容易对产品产生不满。

2、我觉得是存在的，我每次等外卖的时候就觉得很无聊。

3、特别无聊就给他找点事做，游戏人人都喜欢对吧？

4、我还想过做过阅读产品，让他可以看小说。或者做个社交，让他可以约妹子。但是我想了想，工程量太大了，还是做个小游戏吧。

好了，有了他这些回答，你就可以看出漏洞了。

1、等外卖太久的解决问题难道不是外卖配送的算法不够先进或者配送人手不足决定的吗？那是否应该优先解决根本问题？—— 寻找需求的源头。

2、不要用『我觉得』臆想，你是不是先做个用户调研比较好？—— 让对方为自己的需求寻找依据。

3、用户手机里 App 那么多，为什么要玩我们的游戏，我们的游戏有别家做的好吗？（此时还可以举例）上一家在天气 App 里增加外卖功能的产品被骂的很惨的好吗？添加一个与主业务无关的流程是不是需要谨慎考虑，需不需要请示一下XXX —— 将领导拉入战场。

4、那你觉得如果做了这个以后用户的活跃度或者满意度会提升吗？会提升多少呢？（如果在挣扎不过的时候，一定要做，留着这些以待以后打脸）

还有那些方法应对？

当产品经理提出的需求确实属于不靠谱的行列，程序员可以采用以下方法应对：

1、明确指出问题

每一项需求都要经得住推敲。产品经理难免会出现思考不充分或存在疏漏的情况，这个时候，程序员要直接明确地指出存在的问题，敦促产品经理重新进行梳理。

2、强化职场沟通的能力

每一类职业都会影响从业人员的性格。由于职业特点，程序员对于技术任务的专注往往会淡化他们在职场上与人打交道的能力，比起产品经理，存在更多的被动性。因此，程序员应主动培养职场沟通的能力，以便在工作中更好地转达自己的态度和观点。

3、引入外援，一起讨论

在实际工作中，往往会出现程序员和产品经理谈不拢的情况。此种情境发生时，如果实在无法说服对方，可以多找几个人一块讨论，客观层面上将道理越辩越明，从而消除产品经理的不理解，达到自己的目的。

4、寻求 leader 的支持

通常情况下，大多数产品需求不仅来自产品经理，更源于公司领导的构想。但一些想法在研发人员眼中却存在明显的问题。这种情况下，如果遇上强势的产品经理，或是公司领导的意愿，程序员的意见将可能不被重视。此时，程序员可以向上级 leader 寻求帮助，获得支持。

5、熟悉产品经理的特点

程序员与产品经理处在不同的岗位，拥有不同的诉求，但拥有同一个目标，即做出好的产品。因此，程序员需要认识产品经理这个人，了解他做事的方式、喜好，本身的优缺点。在此基础上，遇到分歧时可以更快地明白症结，通过合适而有效的方式说服产品经理。

6、对产品经理进行“威慑”

在实际工作中，很多产品经理虽然考虑到了研发，常常却忽略了产品需求在测试阶段是否可行。面对这种情况的屡次发生，可以开始考虑用软硬兼施的办法，遇到实在不能接受的需求，可以直言：“不要以为你很牛逼，再牛逼你就自己做！”

在某些情况下，程序员可以摆出强势的一面应对产品经理。

7、决定要做的，也要想出切实可行的办法

一项功能是否真的需要开发，有时候会有很多决定因素。最终仍然决定要做的工作，程序员应想出切实可行的办法。如若没有实现的路径，只能给出做不了的解释。

8、敢于拍板，为拒绝需求承担责任

在工作中，逐渐培养出自己自信果敢的一面，面对不合理的需求会给出明确的理由，并表示为自己的判断和决定负责。专业的程序员，应当做到为自己的职场行为负责，只有这样，才能在与产品经理的博弈中拥有底气。

9、必杀技：为产品经理设计逻辑陷阱

面对不靠谱的需求，最擅长的手法是，在与产品经理对接的过程中，利用自身逻辑思维能力强的优势，引导其掉入需求中存在的逻辑陷阱，无法自拔，从而主动放弃，推翻之前的需求。

此项必杀技，是他与产品经理斗智斗勇的心得。但这项必杀技的使用前提是，确实是从技术角度不能支持的想法。

在任何一家互联网公司，优秀的产品都需要程序员和产品经理的共同协作。产品经理的工作不仅需要程序员的配合，有时更需要技术人员的匡正。

与全盘接受相比，偶尔的拒绝也有其价值。只有在这样的层面下，产品和技术，才能为实现真正好的功能做出贡献。

·END·

程序员的成长之路

路虽远，行则必至