RD和PM的恩怨是历年来有目共睹的，

每一个项目迭代中，RD都是希望能得到更多的“空闲时间”，这时间可以养精蓄锐或是技术学习。 PM则希望能够尽最大效率使用RD，把自己堆着的那些prd都能最快落地，希望不管出现任何问题都别延期。 这也是造成了两者最直接的矛盾。 

但天天重复相似的问题，有没有通用的解决方案？ 秉承多年与PM周旋的经验下面主要从以下八点开始阐述

• 求其上得其中

• 合理的攒人情

• 如何给PM施压

• 该正面交锋时，绝不手软

• 先小人后君子

• 如何砍需求

• 不该背的锅不背

• 工作同事和生活朋友角色转换

一、求其上得其中

有的PM非常凶悍，说话好像没商量似得， 这里的原因有几个（级别高，或是上级拍板的重要需求，或是那厮最近干了什么自信爆棚的事，或是看不起你们RD觉得只能干活），这种人就是非常讨厌的，觉得好像只有他自己有产品思维，其他人都是棋子，估时一定要往多几倍估，12天的需求 就估18天，他肯定会缩时间，因为他肯定不想吃亏，就是想压榨你们。 有的时候让你改3个需求，如果你觉得最多只能改2个了，就先说全不改，讨价还价之后让你改1~2个。  这个求其上得其中 大家基本都有理解，具体不做赘述。

二、合理的攒人情

PM岗位换的比RD要勤，经常会有一些PM刚来不久内心比较虚。

有时他明知道自己的错误（需求文档哪里写的产生了歧义，或是漏了哪种场景）想找你改需求。假如这个地方很好改，你眉头一锁（装的很难的样子），说：“哎，当时需求咋不早说，我等会晚上帮你改了吧” 或是 “哎，好吧，那我之前的几个函数要推倒重写了”。  其实可能就是一个if分支或是循环算法改下，PM会马上说 谢谢谢谢... 多谢理解... 给你添麻烦了....  害得你要加班了...  我干过一次，一个改动秒改，然后晚上我看开发文档很晚才走，新来的PM胆小看我们没走也不好意思走，以为我帮他改需求呢，每次见面都客客气气的。

三、如何给PM施压

场景：PM在群里说：这里我们改成这个逻辑了...  很明显这是对我们不利的，需要给他施压让他放弃。

方法一（揭竿起义）拉动自己组或是别的组的（比如安卓和iOS）都在群里回复“卧槽，改不了啊！” ，“根本没法改！”，“以前的多好，我都写完了！” PM看着群里一条条的刷屏不由的菊花一紧...

方法二（吓唬外行）“这样改的话风险不可控！”，“这样改可能会和我们XX组件背道而驰，发生冲突”，“这样改我们需要重构了！” （PM很害怕“重构”这个词） PM心想我也不懂啊，这么严重啊，要不就算了...

方法三（事情闹大）“这样改需要发邮件抄送双方上级周知一下” ，PM心想我可不想惊动老大啊...  老大们如果看到个邮件都会以为出大问题了

四、该正面交锋时，绝不手软

楼主有的时候也是被PM气的无语了，那时候没经验，自己生闷气一周。 这就好比于，大学里有时谁和你争吵说的很难听，那时你也许是怂也许是当时脑袋卡壳，就认输了，后来回头想想，无限后悔我当时真应该怎么怎么怼他。 对于PM我觉得也是，该交锋时绝不手软。 我建议“得理不饶人”的做法，只要你不理亏，一定要为自己争得最大利益。

有些人可能会问，PM也是同事也是要好好相处的，以后低头不见抬头见，闹翻了不好吧？ RD为什么总是这么自作多情，大部分RD少言寡语，木讷。PM则是油滑，三寸不烂之舌。 你想和他好好相处，人家照样当你是傻子。 其实我们可以利用我们傻子的形象，所有玩过分了的事，说过分了的话 我们都可以用 “我们RD一直面对代码比较呆，不会说人话，大家不要放在心上啊” 类似这种策略为自己洗白减轻罪名，大事化小小事化了。 相反如果你当时认了怂，那加班12点改bug都只能赖你自己无能。

大妈和卖菜的讨价还价说的面红耳赤，这边说菜不太新鲜，那边说原料涨价了，互喷争吵到最后买了菜，以后见面还是乐呵呵，中间有来有往当然不是仇人啊。 和PM讨价还价砍需求也是这样，争吵没有你想的那么严重。

五、先小人后君子

在开发前期和PM各种互撕毫不收敛...加需求一律不改...估时估的多...增加了细节还一律重新估时...PM哪里漏了分支马上提出让PM丢脸...  一整个版本下来PM对你的仇恨值已经达到了峰值！！ 然后等到版本正常发布上线之后，你可以主动和PM示好，安抚他，比如中午食堂吃饭的时候，夸他这个版本需求很赞；那几张流程图用什么工具画的这么好看；你需求写的很清晰我开发也很顺畅。 又比如在版本总结会上，大家心情相对轻松，你可以说我们这个版本按时上线按时发布毫无delay，PM们功不可没！运筹帷幄啊！...

这样一个版本下来你既没累到，也没受委屈，PM呢也安抚了毫无问题，大家还都是好同事，结果是很好的。 很多RD不会说这些打圆场的话，可能是内向，也可能是觉得没必要，这些都是你不成熟的表现。   我问你一个问题，你微信里有上级，有领导，平时也不说话，过年群发一个很土的拜年信息 有没有必要？

六、如何砍需求

方法一：（优先级法）PM出了需求池后，一定要让他们列出优先级。 优先级排的低的直接砍掉。

方法二：（场景弱化法）有些场景，可能几乎不会出现，但是大多数bug都容易出现在极端场景叠加时，这种地方的需求从一开始就应该从简处理。可以利用埋点工具，看看有的需求做了都没人用得到，反过来黑PM。

方法三：（不吃螃蟹法）不吃螃蟹就是不去第一个踩坑的意思，人家PM出的需求觉得不合理的就让他找出业界有哪些其他公司做了这个功能？ 你能找到个例子我再做。 这一点非常有用，有的PM和UI天马行空想的需求，你和他说人家能做出来的我都能做，人家做不了的我也不做。 如果你态度非常强硬很多不合理需求可以过滤掉，或是用业界常用作法，那就比较简单了。 一般很不合理的需求很难找到业界例子。

方法四：（价值观法）有很多需求不是不能做，而是这么做值不值得？ 本来可以用系统组件的，你非要有一点不一样，叫我单独写个自定义控件？有的组件用户基本不会用，你让我投入这么多精力 这也是不合理的。

方法五：（无奈哭穷法）估时估好了，上线时间也确定了，我反正就是做不完了怎么着吧，要不然你去别的组看能不能借人来，要不然就是我给你做上线时间顺延。 这是大实话啊。

七、不该背的锅不背

工作中最怕的是干一些费力不讨好的活，开发到了后期所有可能造成风险的需求一定要拒了或是声明风险。 有时最后PM实在还是改了需求，或是第三方原因导致延期，一定要在延期邮件里明确说明，因为很多上级官员并不太清楚下面发生了什么，有时你以为别人都知道了觉得没必要那样去申明，忽视了这一点，那吃亏就是自己。 别人看到的是最后那几天你还在提PR，都以为是你没做完呢，汝不知是PM改的需求。 我们公司有Task的工具，有的bug不是你的锅，一定要在下面评论，我给你改可以，但不是我的锅是产品bug。

还有一点也是需要提前声明的，就是工程层面的时间消耗，比如水平低的产品以为你改一个逻辑1分钟就ok了，其实你需要经历：暂停当前开发分支→切到stage分支→拉代码→新建fix分支→解决→自测→提pr→组内review并merge→部署到jekins-ci打包→新包在内网可下载 。 经历这么多的步骤 中间还不算编译的时间，如果是Android studio那就慢慢等着吧，iOS xcode编译的倒挺快，但是如果涉及到pod install那也得等会。 这些你不说他们是不知道的，所以在他们说：“你怎么这么慢啊” 之前必须先给他们科普。

八、工作同事和生活朋友角色转换

类似于NBA赛场上的科比詹姆斯，赛场上是对手，赛场下是朋友 这种关系。 这里倒不是说要在工作上和PM做对手， 重点是在你自己的人脉，前面对PM又黑又骂的，但是要让他们知道大家都是为了自己工作上的事在互喷， 这并不影响生活中大家还是朋友，职业生涯也是个人脉。有的以前争论需求差点打起来的PM转组了不和我们直接对接了，大家见面依然都是老熟人，打招呼，微信游戏有时还邀请下。 有些时候两个男人之间的需求更好解决，大家认识时间长了，渐渐也就知道对方的底线了，而且供需不对等时，大家也知道这是两边上级的原因，不能把气撒在好友身上。 相比之下男女之间的关系较为复杂，女生不太会和你讲道理讲底线，除非你长得帅。

最近业务需求太多，没啥长进，遂吐槽之余整理了这篇杂文，希望能引起共鸣，转载需注明出处。

程序猿如何“智斗”产品经理