快好知 kuaihz

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

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

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

直觉告诉我,一定是某个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,被挑战的可能性不大。

标品:一句话,这是用户的系统习惯,你不应该也没必要去改变。

专家:代表着未来,老板支持就干呗。

老板:还用问?

有源设计,不要意淫。

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

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:程序员  程序员词条  思路  思路词条  避免  避免词条  沟通  沟通词条  错误  错误词条