皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

产品经理如何与开发打交道,才能实现合作与共赢?

因为角色的差异,产品经理和工程师变成了上下游。也就是产品经理折腾半天,做需求收集、分析讨论等等,然后做出 PRD (产品需求文档)交给工程师之后就不管了,工程师拿到 PRD 之后做系统设计研发实施。我们希望工程师可以尽量早地参与到流程中来,产品经理则尽量晚地从流程中退出去。

本文摘自邱岳在极客时间App上开始的全年付费专栏《邱岳的产品手记》,已获授权。欲阅读更多独家文章,请点击此处订阅专栏阅读(支持微信支付)。

全流程参与

对产品经理来说,首先要做到尽可能在项目的早期去跟工程师沟通。我们在安排一些项目的早期,可能因为很多东西没有最终确定,也不太想跟工程师说,觉得等确定了再沟通;但这样做很容易导致说的时候已经来不及了。比如 11 月 3 日通知工程师说:“咱们 11 月 11 日大促,这是三个需求你尽快做一下”,工程师会非常反感这种带着截止期限的突然袭击。

最好的方式是当某个业务有苗头的时候,产品经理就应该开始跟工程师交流,但这时候不要正式地去提需求,而是做一些非正式的沟通,否则后期如果有变化会让工程师觉得你出尔反尔。

除此之外,一定要邀请工程师来参与项目前期的需求收集和需求评审,不要觉得这种场合不需要工程师,等确定了再转述或者产品经理去宣讲就可以了。你需要尽可能让工程师参与,他可以更全面地了解项目和特性的目的,和不同利益相关者的顾虑和立场,也可以让工程师理解一些产品经理对产品细节的坚持。

除了让工程师往前走参与需求过程之外,产品经理也要主动往流程的后半部分延伸,去参与设计、开发、上线中的技术部分。比如在产品上线过程中出了 Bug,服务不可用了。

这时候产品经理应该干什么?可能有的人不参与,等着工程师自己处理,还有的在群里吵,谁的 Bug,什么时候修好等等;但是,其实更合适的方式是能够参与到问题解决中,去问一下具体是什么问题,需不需要帮助。

很多时候工程师在考虑故障的时候,主要会去想如何把出现的问题修好,而产品经理在考虑问题的时候,可能会考虑怎样把问题规避过去。比如说付款流程走不下去,工程师会想着去修复它,而产品经理或许可以协调一些资源,直接在某个时间段内就免费掉,先把付款流程绕过去,不损失用户。

但要注意的是,产品经理可以参与,但不要添乱,人家工程师在紧急地写补丁,你拉着人家说:“别写,先给我讲讲。”这样做就很不得体了。

多听工程师的意见

我们在产品设计的过程中要多鼓励工程师给产品经理提意见,这里产品经理和工程师都要摆正心态。对于产品经理来说,不能听不得反对意见,觉得工程师都是在指手画脚。对于工程师来说,不能觉得产品做成什么样子跟我没关系,反正做不好是产品经理背锅。

跟我合作过的工程师,让我最感动也是印象最深的都是那些能够在业务上跟我有不同意见,提出自己想法的工程师。你会发现工程师角度提出来的想法有时会非常有价值,他们有时候会帮忙指出逻辑中的缺陷,或者从可行性的角度中提出更有创造力的实现方法。

作为产品经理,如果总是不愿意听取工程师的建议,时间久了大家都不愿意跟你提建议,状态也会越来越被动,隔阂就会越来越深,造成双方的对立。

还有一个办法,就是让工程师和产品经理轮番做项目经理,当希望工程师尽可能早一些参与的时候,就让工程师做项目经理,因为需要约各种会议,判断利益相关者,还要理解功能的轻重缓急,这就会推着工程师去完整地了解业务。

如果需要产品经理了解更多技术细节,就让产品经理去做项目经理,他要组织和参加各种技术评审,有时候还要判断是否通过,也一样推着产品经理关注到流程的后半段。

不要强迫工程师做评估

这也是我之前犯过的错误,我有时会强迫工程师给出发布时间点,不给的话我就说他不负责任;但是,你要理解很多时候工程师是没办法给出具体发布时间点的,那这种情况下该怎么办呢?

有时候就会有冲突,我很强势必须要,那工程师就随便定一个,结果还是会延期,而且关系闹得很僵,所以如果确实很难确定工期,就不要定非常精确的时间点,可以做个模糊处理。比如 7 月 1 日交付别定成 7 月 1 日,就定成 7 月第一周,留一点缓冲。

另外,产品经理也不要代替别人做评估。比如跟业务部门交流完了之后,随口给个承诺,说一周做完;毕竟不是你做,不要越俎代庖,最好让工程师自己来做预判。

更不要在工程师做评估的时候去讽刺或者评价,产品经理经常会犯一个错误,工程师说某个功能有点难,我们就会说这有什么难的,你看腾讯早就做出来了。工程师会很反感这种沟通方式,技术基础不同,技术积累也不同,不能这么简单去做横向对比。

背黑锅与争取利益

产品经理有一个天职就是背黑锅,产品经理要勇敢地、毫不犹豫地在第一时间站出来帮工程师承担责任。要有这样的姿态,不要往后躲。

并不是说工程师不能自己去承担责任,工程师一般也都不是软蛋,但产品经理应该有这样的意识和态度。让大家知道这个产品经理是敢去担当的,不能跟人家看月亮的时候叫人家小甜甜,出了事儿又喊牛夫人,长此以往工程师就不愿意依赖和相信你了。

还有一个特别重要的事情,就是产品经理一定要帮工程师争取利益,很多时候产品经理是有这个渠道的,产品经理会跟技术主管有更多的接触。

这时候你要想办法给优秀的工程师争取利益,努力帮他做背书,施加你的影响力帮他晋升,给他加薪。尤其有些工程师会比较腼腆,在争取利益上很儒雅,那产品经理就应该要去帮他争取,可能他很多优秀的地方或许只有你有机会看到,要勇于去表达。

互背 KPI,同仇敌忾

产品经理的 KPI 一般都是产品指标,业务指标,而工程师可能会是可用性,特性交付等等。我一直鼓励产品经理去背一点工程 KPI,比如稳定性和可用性。这样做一来可以让产品经理对工程师的顾虑有切身的理解,不能说不在乎系统挂不挂,随意上线什么的。

另外也是防止立场的对立,跟工程师谈具体项目的时候,有时候开发会以影响稳定性作为推脱,如果稳定性也是产品经理的 KPI,那很多事情就容易沟通一些,因为这个事情也会影响你的绩效。

另外一个办法叫做寻找外敌,这个说起来有点腹黑,但确实非常好用。产品和开发也是,如果你们找到一个“外敌”,这个外敌可能是竞争对手,甚至是整个领域的一个敌人,比如我是一个制药公司,我们共同的敌人可能是癌症和肿瘤,比如我是一个做新零售的,那我们共同的敌人可能是传统的供应链巨头。

当有共同的敌人时,团队就更容易结合在一起,科幻电影里也是,人类之间互相打,一来外星人,马上团结起来同仇敌忾。

所以有时候大家可以适当地去树立外敌,有些公司,具体不说什么公司了,会故意在外面引发一些与竞争对手之间的骂战。本来这个业务团队内部闹得一塌糊涂,一看老板在外头被人欺负了,怎么办,立刻变得特别团结。

当然也不是一定要骂架,对于一条产品线,你完全可以在内部找一个具体的竞争对手,把一些业务指标对标起来,大家本着这个指标去努力,这时候可能很多内部矛盾会被消解掉,团队空前团结。

转自 http://www.infoq.com/cn/news/2018/02/product-manager-cooperation-win