产品经理与程序员的相处之道

作为产品经理,如果得不到程序员的协作配合,工作将难以顺利进行。想要处好这个关系,必选先弄清为什么程序员讨厌产品经理。不管是产品经理,还是程序员,在一开始做的时候,或因为专业技术不过关,或因为工作不得法,也或许是因为自己本身就很笨。

产品经理与程序员的相处之道

自产品经理逐渐成为互联网企业标配以来,网上也开始流传着各种产品与开发之间巅峰对决的图片,贴切又形象,这些个梗可以笑个几天几夜了。

产品经理与程序员的相处之道
产品经理与程序员的相处之道
产品经理与程序员的相处之道
产品经理与程序员的相处之道

但是我相信作为一个有人格魅力的产品经理,一定有方法能轻松化解这些问题,而且会逐渐发现他们的可爱之处并建立天长地久的友谊。

接下来给大家分享一下个人“心机”,下面这些问题是经常发生在我们的工作当中的,只需要掌握这五个点:“看听说写问”就可以解决问题。

看:即察言观色
听:倾听他们的想法
说:表达自己的看法
写:尊重他人的说法,认真记录笔记
问:询问他们的建议或意见

情景一:临时新增紧急需求

故事背景

当用户提出某个需求,业务要求尽快优先完成,经过你的思考,觉得需求合理并可行,可和开发说临时增加这个需求的时候

开发:这个需求做不了
产品:加一下吧,用户要求的
开发:不行
产品:不是改下XXX就可以了吗?
开发:这样会影响了整个产品现有逻辑,改动太大了,你不懂技术,和你说了,你也不明白
产品:。。。。。。

准备工作

1)提前准备好实现需求的一种或多种方案,无论是否可行

2)纸笔或白板,讨论需求方案过程当中可能随时会用到

接下来

一看:

观察开发人员当前的面部表情,是皱着眉头正一本正经地在撸码,还是面带微笑和周边的人正在聊天,总之,发现他明显处理放松状态的空隙,再去找他

二说:

1)说明这个需求的来源是用户遇到了什么问题提出的。目的让他也能深入用户的使用场景,在心中模拟使用过程,产生同理心。

2)说明这个需求的紧急性。千万不要以“客户很着急,不做这功能这笔订单就黄了”的负面方式来“威胁”他,而要以正面的方式来鼓励他,比如“这个需求很重要,搞定这个用户你就是大功臣”的方式来鼓励他

三问:

将提前准备好的方案和他讨论(期间可能会用到纸和笔,或者白板),不用理会这个实现方案是否可行,重点是你要有,代表你仔细思考了这个问题,若是明知不可行可能效果更好。

产品:“我想了个方法,你看这样行不行?(描述你的方法)”
开发:“这样肯定不行的,这个可能会对系统造成不可磨灭的灾难XXXXXX”
产品:“啊?这么严重,幸好你提醒了,还是你厉害,你有其它的办法没"
开发:“有一个办法:(开始描述他的想法)”
产品:”嗯嗯,这个好,这样就不会产生这些问题了,那就按你的想法来弄“
开发:”好“(这时候再问开发需要的时间)
产品:”那你预计弄这个功能,需要多久时间?“
开发:”两天“
产品:”会影响你当前现在的工作进度吗?“
开发:“会”
产品:"那我把这次你的需求提测时间往后延一下,先完成这个吧"
开发:“好”

要点

引导他去思考,由他来实现他提出的方法,一切顺理成章、心甘情愿。。。

情景二:需求变更

故事背景

已经和开发说完了本期需求,开发过程中,你由于外部因素或内部因素等原因变更了需求,和负责开发这个功能的同事说的时候

产品:这个需求我改了一下,你按新的来做哈
开发:这个改动很大,我都做了一半了,又得重新来
产品:没办法,改吧
开发:。。。。

准备工作

1、对比新需求,找出需要推翻老需求的合理的“借口”,用来说服开发

2、若改动较大,则需要提前准备好纸和笔,或白板,则改动小,则不用

接下来

一看:

和情景一一样,尽量观察开发人员当前的面部表情,发现他明显处理放松状态的空隙,再去找他

二说与问:

说明原因并询问他的看法

产品:“关于XXXX的需求,我这边做了些调整”
开发:“又改动?”
产品:“是这样的,我发现现在的这种方式可能会存在几个问题:1......2......3......,你说是不?”
开发:“好像是的”
产品:“那我如果改成这样:XXXXXX,,这样这几个问题就不存在了,你看呢?”
开发:“这样也可能会有问题”
产品:“啊?是吗?我就感觉我考虑得可能不够全面,你说说看”
开发:“这个可能会影响到之前的XXX功能”
(这时候他说什么你都要点头)
产品:“你说得很对,要不这样,等功能出来之后,提给测试那边验证一下?”
开发:“嗯”
产品:“那好,那我就按这样更新下需求文档”

要点

引导他的“共情”,让他和你的看法一致,自然就达到目的

情景三:矛盾协调

故事背景

测试组提个bug给某个开发A,开发认为这个问题是当时另一位开发同事B让他这样改导致的,不愿意修改这个bug。

开发A:这个不是我的问题,是XXX当时让我改成这样的
产品:可现在这个改法现在出了问题,这块是你做的,你再改一下吧,不然影响上线进度
开发A:我为什么要改产品:。。。。

准备工作

1、找间会议室

2、准备你自己的“主动认错”陈词

接下来

1、听:

1)倾听开发A描述事情经过。

2)并开发B说明当前情况,倾听开发B描述事情经过,确认开发A是否属实。

2、说与问:

1)组织事件相关人员,测试,开发人员A,开发人员B等相关人员到会议室。。

2)开头陈述事情,并请开发同事B说明情况:“把大家叫到这里来,相信大家应该知道是什么事情了,开发同事B,麻烦你先说一下情况吧”,这里主要目的是为了让A同事的说法得到我们的尊重与认可。

3)陈述自己提前准备好的陈词:“这事情也赖我,没有进一步和你们确认这个,现在由于我们的失误导致这种问题的发生,实在很抱歉,那接下来麻烦开发同事A修改一下这个,可以吗?”

基本这个时候,开发同事A已经没什么抱怨了,心甘情愿去改了。

要点

主动承认错误,双方互相尊重,矛盾自然迎刃而解。尤其当内部矛盾产生的时候,一定要尽快解决并处理,否则越积越深,最终可能就会发生“手机壳变色”事件。

本文由 新媒体运营 作者:春晓 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体运营 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
8

发表评论