产品经理与程序员沟通的艺术：避免这5个错误的思路

　　职场没有彼岸，只有在路上，且行且珍惜
　　还是在几年前，一个普通的工作日，我正准备完成滴答清单上今天最后一个任务清理邮箱。此时一封“情感丰富”的邮件映入眼帘，“UCANUUP，NOCANNOBB”。
　　直觉告诉我，一定是某个RD又被PM逼疯了。
　　想想也挺有意思的，这几年的工作中，不断重复上映着类似的一幕。
　　下面我们就看看这五个小技巧，有那些亲还没有“掌握”？
　　第一招：高山流水
　　“这个实现起来，应该很容易吧！”，一个怀疑的小眼神，像激光一样在RD身上扫来扫去。
　　这句话的潜台词是：你最好给我的工期短一些，否则就是你能力不行！
　　这句话不是不能说，是要分谁说。
　　如果是该RD的leader，研发总监之类的说，有资格。为啥？因为他了解开发原理、理解开发过程和熟悉工程代码现状。
　　如果是你说，就不行。为啥？你不懂开发啊
　　越俎代庖不但不会拿到好的结果，还会暴露你的情商。有的人会说了，我也是为了给对方点压力，尽快上线给公司创造价值啊。
　　这个出发点是没有错的，有问题的是方式方法。
　　例如：先不着急下结论，听听对方给的排期自己是否能接受？不能接受的话，可以询问一下主要的工程量在哪儿，PM是否可以做些什么，好加快进度？技术难点是否需要和组内leader一起讨论一下，必要的时候PM可以再进一步精简方案等。
　　第二招：绵里藏针
　　“那个，实在不好意思啊，这儿在改一下哈”，娇滴滴的一个小女生面红耳赤的望着RD（有的时候确实是半蹲着，好吧其实是跪着）、
　　频繁的改需求，你的形象值出现了赤字。
　　究其原因，主要是两方面：客观原因和主观原因。
　　前者，典型案例如下：
　　老板临时要求：提前做好预期管理，充分沟通，一般是可以避免的。但如果真遇到了老板不方便说（eg。资金压力），或者还处于试用期的你，就先强调执行力吧（在做了充分沟通的情况下）。
　　业务变更了需求（部分修改）：重点在于引导业务同学关注目标，只要是当前方案能解决业务痛点，达成业务目标，产品应坚持不调整或下个版本调整。
　　业务反水（全盘否定）：利用业务评审会、会议纪要和测试验收充分做好风控流程。
　　技术瓶颈：很多技术难点是在开发过程中暴露出来的，这种情况下的修改产研双方都能理解，重点是最大程度的复用方案，将工程资源浪费降到最低。
　　后者，主要是方案设计能力出了问题，出门左拐看《写给RD的一份情书PRD》。
　　没有人敢承诺开发过程中方案一定不会发生改变，但是发生频率还是可以控制的，以上概括起来就三点：
　　尊重过程
　　关注目标
　　严谨负责
　　第三招：八步赶蝉
　　“兄弟，啥进度了？”
　　经常看到小白产品，不是钉钉催，就是跑到工位问，要不就用老板压。
　　说真的，没必要。
　　你可能会说了，站着说话不腰疼，不催领导找我要进度，我怎么说。
　　不是不让你催，而是不建议你“愣头青”式的催，可以试试“灰度催工法”。
　　具体如下：
　　针对信用值高且技术能力的强的大牛，你根本就不用催，这些人把职业形象看的比什么都重，你的催促除了给对方带来反感，伤害彼此的合作信任关系以外，不会有任何效果。
　　针对信用值高但技术能弱的研发，其实也不用催，为了他的信用值，他自己就会想办法保证进度，你根本不用操心。
　　以上两种都比较省心，最怕的是信用值低的研发（无论其研发能力如何），需要费些心思。
　　例如：
　　可以询问PRD是否有不清楚的地方，自己可以在单独给详细讲一下，捎带在确认一下进度；
　　工程开始时候，可以参与工程早会关注进度，哪怕是催图这种事也要积极参与，营造一种重视感；
　　公开场合赞扬改研发，并“无意间”提到排期，以便引起对方的重视；
　　通过roadmap，倒逼时间，提醒QA同学，利用团队的压力避免其失信；
　　和其领导强调该工程的意义，并确认时间。
　　项目管理用情商，关注进度重技巧。
　　第四招：雾里看花
　　“这个PRD里竟然出现了【可能】！！！”RD抓住了自己本已稀疏不多的头发说道。
　　如果说研发同学最恨的是什么，那“不确定性”一定能够名列前茅。因为，在研发的世界里，开发的过程就是将PRD里的内容翻译成高级语言，再由计算机讲高级语言翻译成机器语言执行的过程。
　　研发最愿意花时间的地方是“研究如何用高性价比的方式实现需求”而不是“理解这是个什么玩儿意儿？”
　　想象一下，一名出色的翻译官面前站着一个“外国人”和一个“外星人”的画面，你就应该能理解我在说什么了。
　　你的“不确定性”，是在扼杀RD的青春（如果他们还有的话）。
　　第五招：鹞子翻身
　　“这TM弱智也能看出来设计不合理”，胖胖的RD开始嘟哝着。
　　经常听到工程评审时候，PM以这些词汇开头“我觉得”、“我认为”、“我想”、“我猜”
　　腾讯UDC提出来的一个概念，有源设计，即坚持每个方案决策都有依据支撑。
　　深以为然。只有坚持有源设计，这种科学的决策方式，PM个人才能在工程团队中建立起来专业的形象，成为大家嘴里的“靠谱人士”。
　　经过多年的被喷经验，我总结了如下几个打死都能说得过去的决策依据，仅供参考：
　　数据：用数据说话，这个一般不会有人质疑，除非你的数据本身经不起挑战。
　　调研：只要样本量和质控制好了，可信度是很高的（京东的物流就是这么决策的，见《创京东》）。
　　竞品：只要是选择的是一直表现不错的竞品，用好MVP，被挑战的可能性不大。
　　标品：一句话，这是用户的系统习惯，你不应该也没必要去改变。
　　专家：代表着未来，老板支持就干呗。
　　老板：还用问？
　　有源设计，不要意淫。
　　最后，老生常谈一下。职场没有彼岸，只有在路上，且行且珍惜