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

职场没有彼岸，只有在路上，且行且珍惜~

还是在几年前，一个普通的工作日，我正准备完成滴答清单上今天最后一个任务-清理邮箱。此时一封“情感丰富”的邮件映入眼帘，“U CAN U UP, NO CAN NO B B”。

直觉告诉我，一定是某个RD又被PM逼疯了。

想想也挺有意思的，这几年的工作中，不断重复上映着类似的一幕。

下面我们就看看这五个小技巧, 有那些亲还没有“掌握”？

第一招：高山流水

“这个实现起来，应该很容易吧！”，一个怀疑的小眼神，像激光一样在RD身上扫来扫去。

这句话的潜台词是：你最好给我的工期短一些，否则就是你能力不行！

这句话不是不能说，是要分谁说。

如果是该RD的leader，研发总监之类的说，有资格。为啥？因为他了解开发原理、理解开发过程和熟悉工程代码现状。

如果是你说，就不行。为啥？你不懂开发啊~

越俎代庖不但不**拿到好的结果，还**暴露你的情商。有的人**说了，我也是为了给对方点压力，尽快上线给公司创造价值啊。

这个出发点是没有错的，有问题的是方式方法。

例如：先不着急下结论，听听对方给的排期自己是否能接受？不能接受的话，可以询问一下主要的工程量在哪儿，PM是否可以做些什么，好加快进度？技术难点是否需要和组内leader一起讨论一下，必要的时候PM可以再进一步精简方案等。

第二招：绵里藏针

“那个，实在不好意思啊，这儿在改一下哈~”，娇滴滴的一个小女生面红耳赤的望着RD（有的时候确实是半蹲着，好吧其实是跪着~）、

频繁的改需求，你的形象值出现了赤字。

究其原因，主要是两方面：客观原因和主观原因。

前者，典型案例如下：

• 老板临时要求 ： 提前做好预期管理，充分沟通，一般是可以避免的。但如果真遇到了老板不方便说（eg.资金压力），或者还处于试用期的你，就先强调执行力吧（在做了充分沟通的情况下）。
• 业务变更了需求（部分修改）：重点在于引导业务同学关注目标，只要是当前方案能解决业务痛点，达成业务目标，产品应坚持不调整或下个版本调整。
• 业务反水（全**否定）：利用业务评审**、**议纪要和测试验收充分做好风控流程。
• 技术瓶颈：很多技术难点是在开发过程中暴露出来的，这种情况下的修改产研双方都能理解，重点是最大程度的复用方案，将工程资源浪费降到最低。

后者，主要是方案设计能力出了问题，出门左拐看《写给RD的一份情书-PRD》.

没有人敢承诺开发过程中方案一定不**发生改变，但是发生频率还是可以控制的，以上概括起来就三点：

1. 尊重过程
2. 关注目标
3. 严谨负责

第三招：八步赶蝉

“兄弟，啥进度了？”

经常看到小白产品，不是钉钉催，就是跑到工位问，要不就用老板压。

说真的，没必要。

你可能**说了，站着说话不腰疼，不催领导找我要进度，我怎么说。

不是不让你催，而是不建议你“愣头青”式的催，可以试试“灰度催工法”。

具体如下：

• 针对信用值高且技术能力的强的大牛，你根本就不用催，这些人把职业形象看的比什么都重，你的催促除了给对方带来反感，伤害彼此的合作信任关系以外，不**有任何效果。
• 针对信用值高但技术能弱的研发，其实也不用催，为了他的信用值，他自己就**想办法保证进度，你根本不用操心。

以上两种都比较省心，最怕的是信用值低的研发（无论其研发能力如何），需要费些心思。

例如：

• 可以询问PRD是否有不清楚的地方，自己可以在单独给详细讲一下，捎带在确认一下进度；
• 工程开始时候，可以参与工程早**关注进度，哪怕是催图这种事也要积极参与，营造一种重视感；
• 公开场合**扬改研发，并“无意间”提到排期，以便引起对方的重视；
• 通过roadmap,倒逼时间，提醒QA同学，利用团队的压力避免其失信；
• 和其领导强调该工程的意义，并确认时间。

项目管理用情商，关注进度重技巧。

第四招 ：雾里看花

“这个PRD里竟然出现了【可能】！！！”RD抓住了自己本已稀疏不多的头发说道。

如果说研发同学最恨的是什么，那“不确定性”一定能够名列前茅。因为，在研发的世界里，开发的过程就是将PRD里的内容翻译成高级语言，再由计算机讲高级语言翻译成机器语言执行的过程。

研发最愿意花时间的地方是“研究如何用高性价比的方式实现需求”而不是“理解这是个什么玩儿意儿？”

想象一下，一名出色的翻译官面前站着一个“外国人”和一个“外星人”的画面，你就应该能理解我在说什么了。

你的“不确定性”，是在扼杀RD的青春（如果他们还有的话~）。

第五招：鹞子翻身

“这TM弱智也能看出来设计不合理”，胖胖的RD开始嘟哝着。

经常听到工程评审时候，PM以这些词汇开头“我觉得”、“我认为”、“我想”、“我猜”……

**UDC提出来的一个概念，有源设计，即坚持每个方案决策都有依据支撑。

深以为然。只有坚持有源设计，这种科学的决策方式，PM个人才能在工程团队中建立起来专业的形象，成为大家嘴里的“靠谱人士”。

经过多年的被喷经验，我总结了如下几个打死都能说得过去的决策依据，仅供参考：

• 数据 ：用数据说话，这个一般不**有人质疑，除非你的数据本身经不起挑战。
• 调研：只要样本量和质控制好了，可信度是很高的（京东的物流就是这么决策的，见《创京东》）。
• 竞品：只要是选择的是一直表现不错的竞品，用好MVP,被挑战的可能性不大。
• 标品：一句话，这是用户的系统习惯，你不应该也没必要去改变。
• 专家：代表着未来，老板支持就干呗。
• 老板：还用问？

有源设计，不要意淫。

最后，老生常谈一下。职场没有彼岸，只有在路上，且行且珍惜~

本文由 @吴天 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议