• 公众号
  • 商务合作

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

1099 二月 来源:

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

产品经理与程序员沟通的艺术:避免这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协议

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

转载请注明:爱盈利 » 产品经理与程序员沟通的艺术:避免这5个错误的思路

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved.