一直看到各种讲PM肿么肿么样的“讨好”RD，然并卵，受伤的总是PM，呜呜。。。。。作为一名PM，有时候不在于我们是否“讨好”RD，而在于RD是否平等的看待PM。
不能总是围绕PM怎样迎合RD，换位思考下→_→PM更喜欢和神马样的RD合作，RD童鞋也要试着这么想一想
作为一名PM，就已合作过的几种RD来说，哪种才是PM的心目中最喜欢的程序员欧巴or欧妮。
场景：
前端已经完成静态页，开始后端数据填充，遇到了问题，PRD文档没有标注清楚（怪PM不认真写文档！），几种RD面对此种情境，开始各自回答。
RD 1：这个功能做不了，你写的什么东西啊，乱七八糟的，作为产品你都不清楚，我就跟文档来。。。blabla，反正就是做不了，就这样了。。。（PM虽然已道歉，然并卵。。。PM这时已吐血一大盆，伤害值3000点）
RD 2：你的需求文档没标注这里怎么做，你把这部分描述清楚，然后我才能接着做，你先去把逻辑补充清楚，现在逻辑不全，最后需求上线时间延迟几天不定（PM滚回去补充逻辑文档，然后再找研发继续开发。。。PM的伤害值1000点）
RD 3：你的需求文档没标注清楚，不过我想逻辑是这样的吧（此处省略逻辑确认对话，PM回答是）。那行，逻辑是这样的就行，我先开发着，你把文档补充清楚，下次要注意写清楚哦~（遇到这样的RD，PM即使被指责需求文档没写清楚，内心也是暖暖的~~~~，PM伤害值200点）
你以为事情到这里就结束了，那就错了。什么叫祸不单行！PM滚回去补充PRD后，开发继续，中间又遇到了问题，又有问题，又有问题，PM吐一口老血（内心独白：妹的，怎么那么多问题？？？？！！！！坑啊！坑啊！）
RD 1：这问题我解决不了，就只能这样上线。（PM肯定不死心的，设计的东西按理说是能实现的，各种挣扎，一律被否决，伤害值再加2000点）
RD 2：这里有个问题，按照你的需求文档来，目前实现不了，这个功能要不就先别做了（PM哪是那么容易放弃功能的，想了另外一种实现方式，伤害值再加500点）。嗯，现在这个方法ok，可以实现，那我继续开发了，上线时间再延后一些。
RD 3：妹纸，你这个需求按目前的设计实现不了，我想了想，可以其他方式实现，比如方式一，优缺点blabla，方式二，优缺点blabla，方式三。。。。。我建议你用方式一（PM经过思考，认同RD的建议，按照RD的建议继续开发），上线时间需要延后一天（PM伤害值再加100点）
总算开发的坑填上了，需求上线了。与3种类型的开发合作下来，PM的生命值所剩不同：
RD 1对PM伤害值5000点，PM濒临死亡
RD 2对PM的伤害值1500点，PM需要食疗补充一段时间
RD 3对PM的伤害值300点，PM睡一觉立即精神焕发
绳命有限，且行且珍惜！还是选择伤害力度小的程序员合作吧
经过这样的合作，3中RD在PM心中也有了各自的定位：
RD 1：尼玛，再也不要和这样的程序员合作了！！！！！
RD 2：下次可以继续合作~
RD 3：太赞了，真希望以后都是和这样的程序员合作~~~~~~
PM不是神，很多也不懂技术，难免设计的东西做起来遇到问题，遇到问题时RD童鞋要是能帮着PM一起想办法解决，PM内心绝对是感激不尽的~
