20 | 产品经理如何与开发打交道（下）：合作与共赢

Jan 4, 2018

20 | 产品经理如何与开发打交道（下）：合作与共赢-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

20 | 产品经理如何与开发打交道（下）：合作与共赢

2018-01-04 邱岳来自北京

《邱岳的产品手记》

课程介绍



讲述：邱岳

时长11:02大小5.05M



“兄弟阋于墙，外御其务”——《诗经》
上篇文章，我提到产品经理与工程师之间隔阂的原因，主要是思维方式的差异，以及关注领域的不同，然后聊到了几个加强沟通的方法，比如让产品经理向工程师介绍业务，以及主动去理解和学习技术等等内容，今天我们继续聊这个话题。
之前我提到过，因为角色的差异，产品经理和工程师变成了上下游。也就是产品经理折腾半天，做需求收集、分析讨论等等，然后做出 PRD 交给工程师之后就不管了，工程师拿到 PRD 之后做系统设计研发实施。我们希望工程师可以尽量早地参与到流程中来，产品经理则尽量晚地从流程中退出去。
全流程参与对产品经理来说，首先要做到尽可能在项目的早期去跟工程师沟通。我们在安排一些项目的早期，可能因为很多东西没有最终确定，也不太想跟工程师说，觉得等确定了再沟通；但这样做很容易导致说的时候已经来不及了。比如 11 月 3 日通知工程师说：“咱们 11 月 11 日大促，这是三个需求你尽快做一下”，工程师会非常反感这种带着截止期限的突然袭击。
最好的方式是当某个业务有苗头的时候，产品经理就应该开始跟工程师交流，但这时候不要正式地去提需求，而是做一些非正式的沟通，否则后期如果有变化会让工程师觉得你出尔反尔。
除此之外，一定要邀请工程师来参与项目前期的需求收集和需求评审，不要觉得这种场合不需要工程师，等确定了再转述或者产品经理去宣讲就可以了。你需要尽可能让工程师参与，他可以更全面地了解项目和特性的目的，和不同利益相关者的顾虑和立场，也可以让工程师理解一些产品经理对产品细节的坚持。
除了让工程师往前走参与需求过程之外，产品经理也要主动往流程的后半部分延伸，去参与设计、开发、上线中的技术部分。比如在产品上线过程中出了 Bug，服务不可用了。
这时候产品经理应该干什么？可能有的人不参与，等着工程师自己处理，还有的在群里吵，谁的 Bug，什么时候修好等等；但是，其实更合适的方式是能够参与到问题解决中，去问一下具体是什么问题，需不需要帮助。
很多时候工程师在考虑故障的时候，主要会去想如何把出现的问题修好，而产品经理在考虑问题的时候，可能会考虑怎样把问题规避过去。比如说付款流程走不下去，工程师会想着去修复它，而产品经理或许可以协调一些资源，直接在某个时间段内就免费掉，先把付款流程绕过去，不损失用户。
但要注意的是，产品经理可以参与，但不要添乱，人家工程师在紧急地写补丁，你拉着人家说：“别写，先给我讲讲。”这样做就很不得体了。
多听工程师的意见我们在产品设计的过程中要多鼓励工程师给产品经理提意见，这里产品经理和工程师都要摆正心态。对于产品经理来说，不能听不得反对意见，觉得工程师都是在指手画脚。对于工程师来说，不能觉得产品做成什么样子跟我没关系，反正做不好是产品经理背锅。
跟我合作过的工程师，让我最感动也是印象最深的都是那些能够在业务上跟我有不同意见，提出自己想法的工程师。你会发现工程师角度提出来的想法有时会非常有价值，他们有时候会帮忙指出逻辑中的缺陷，或者从可行性的角度中提出更有创造力的实现方法。
作为产品经理，如果总是不愿意听取工程师的建议，时间久了大家都不愿意跟你提建议，状态也会越来越被动，隔阂就会越来越深，造成双方的对立。
还有一个办法，就是让工程师和产品经理轮番做项目经理，当希望工程师尽可能早一些参与的时候，就让工程师做项目经理，因为需要约各种会议，判断利益相关者，还要理解功能的轻重缓急，这就会推着工程师去完整地了解业务。
如果需要产品经理了解更多技术细节，就让产品经理去做项目经理，他要组织和参加各种技术评审，有时候还要判断是否通过，也一样推着产品经理关注到流程的后半段。
不要强迫工程师做评估这也是我之前犯过的错误，我有时会强迫工程师给出发布时间点，不给的话我就说他不负责任；但是，你要理解很多时候工程师是没办法给出具体发布时间点的，那这种情况下该怎么办呢？
有时候就会有冲突，我很强势必须要，那工程师就随便定一个，结果还是会延期，而且关系闹得很僵，所以如果确实很难确定工期，就不要定非常精确的时间点，可以做个模糊处理。比如 7 月 1 日交付别定成 7 月 1 日，就定成 7 月第一周，留一点缓冲。
另外，产品经理也不要代替别人做评估。比如跟业务部门交流完了之后，随口给个承诺，说一周做完；毕竟不是你做，不要越俎代庖，最好让工程师自己来做预判。
更不要在工程师做评估的时候去讽刺或者评价，产品经理经常会犯一个错误，工程师说某个功能有点难，我们就会说这有什么难的，你看腾讯早就做出来了。工程师会很反感这种沟通方式，技术基础不同，技术积累也不同，不能这么简单去做横向对比。
背黑锅与争取利益产品经理有一个天职就是背黑锅，产品经理要勇敢地、毫不犹豫地在第一时间站出来帮工程师承担责任。要有这样的姿态，不要往后躲。
并不是说工程师不能自己去承担责任，工程师一般也都不是软蛋，但产品经理应该有这样的意识和态度。让大家知道这个产品经理是敢去担当的，不能跟人家看月亮的时候叫人家小甜甜，出了事儿又喊牛夫人，长此以往工程师就不愿意依赖和相信你了。
还有一个特别重要的事情，就是产品经理一定要帮工程师争取利益，很多时候产品经理是有这个渠道的，产品经理会跟技术主管有更多的接触。
这时候你要想办法给优秀的工程师争取利益，努力帮他做背书，施加你的影响力帮他晋升，给他加薪。尤其有些工程师会比较腼腆，在争取利益上很儒雅，那产品经理就应该要去帮他争取，可能他很多优秀的地方或许只有你有机会看到，要勇于去表达。
互背 KPI，同仇敌忾产品经理的 KPI 一般都是产品指标，业务指标，而工程师可能会是可用性，特性交付等等。我一直鼓励产品经理去背一点工程 KPI，比如稳定性和可用性。这样做一来可以让产品经理对工程师的顾虑有切身的理解，不能说不在乎系统挂不挂，随意上线什么的。
另外也是防止立场的对立，跟工程师谈具体项目的时候，有时候开发会以影响稳定性作为推脱，如果稳定性也是产品经理的 KPI，那很多事情就容易沟通一些，因为这个事情也会影响你的绩效。
另外一个办法叫做寻找外敌，这个说起来有点腹黑，但确实非常好用。产品和开发也是，如果你们找到一个“外敌”，这个外敌可能是竞争对手，甚至是整个领域的一个敌人，比如我是一个制药公司，我们共同的敌人可能是癌症和肿瘤，比如我是一个做新零售的，那我们共同的敌人可能是传统的供应链巨头。
当有共同的敌人时，团队就更容易结合在一起，科幻电影里也是，人类之间互相打，一来外星人，马上团结起来同仇敌忾。
所以有时候大家可以适当地去树立外敌，有些公司，具体不说什么公司了，会故意在外面引发一些与竞争对手之间的骂战。本来这个业务团队内部闹得一塌糊涂，一看老板在外头被人欺负了，怎么办，立刻变得特别团结。
当然也不是一定要骂架，对于一条产品线，你完全可以在内部找一个具体的竞争对手，把一些业务指标对标起来，大家本着这个指标去努力，这时候可能很多内部矛盾会被消解掉，团队空前团结。
建立良好的个人关系最后一个建议，是鼓励做产品可以多跟工程师交朋友。我工作这么多年，结交到的朋友大部分都是工程师。当跟他们真的成为朋友时，你会本能地考虑他们的立场，担心他们的担心，当然他们也会用心理解和帮助你。
我之前工作中偶尔会有自己没处理好的事情，或者因为任性捅的篓子，有时候对应的工程师可能就会加班，甚至通宵帮我处理掉。甚至也有朋友为了保护我，帮我承担了一些东西。这些工作量和付出其实都算是友情赞助的，也都不算是他们的绩效，这些感情我一直都记在心里。也想借着专栏的版面，向他们表达我的感激。
总结到这里我们关于如何与工程师打交道的分享就全部结束了，这次我们提到尽可能让产品经理和工程师都全流程参与到一个产品的规划和实施中，建议产品经理多去听取工程师的建议，不要强迫或代替工程师做评估，尽量帮工程师争取利益等等。
所有的这些方法都只是方法，最重要的还是要始终重视打造与工程师之间合作氛围，与工程师相互尊重，始终保持合作的态度和意识，只有这样才能发挥各自的优势和长处，把产品做好，把事情做成。
你有没有让你印象深刻的，产品经理与工程师之间合作的故事？欢迎你在留言中分享，今天的文章就到这里，谢谢你。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 7

提建议

19 | 产品经理如何与开发打交道（上）：打破思维的边界

21 | 产品案例分析：Fabulous的精致养成

 写留言

精选留言(20)

Ned
2018-01-04
有项目喝酒吃肉谈工作，没项目吃肉喝酒聊生活相互尊重是原则，敢于背锅是觉悟
作者回复: 赞总结
29
听天由己
2018-01-04
句句在理，职场残酷，建立良好的人际关系就至关重要了，二爷文章中的几句调侃真的很赞。说起与工程师打交道，我自己的经历可供大家参考。小宇是我们创业后认识的一位技术伙伴，熟悉 PhP 程序语言开发，在工作两年后，他辞去知名杂志社工作加入我们的创业团队，他负责技术，我负责产品，两人便因此相识了。刚认识小宇之时，我还是十分稚嫩，关于需求讨论或是开发进度都不可避免地与他产生各种各样的矛盾，这一度让我十分压抑，似乎我的角色要被代替了。在我看来，他的确经验丰富，对于技术、产品、趋势、商业都有清晰的见解，很多方面我都需要向他请教，但我心里总是有些不甘，希望能够成为全面的产品经理。再三反思后，我逐渐转变了自己的工作态度以及沟通方式，虽然他说话直白，但就事论事，我认为是很舒服的交流方式。后来，我们也慢慢变成了无话不谈的朋友，现在还在一起学习成长，相互理解。
展开
作者回复: 有这样的朋友，比一份工作还有价值，或许你以后会理解，记得一直跟他保持联系
15
孙伟贤
2018-01-06
工程师是我觉得公司里最好沟通的人，单纯的要命。
作者回复: 哈哈哈哈哈哈哈哈，没错
14
骆驼
2018-01-04
产品经理怎么帮工程师争取利益？还能升职加薪？一般都是各个部门做自己的review，当然二爷这个位置除外，你是老板，我说的是一般岗位的产品经理
作者回复: 有时候发一封邮件，表达感谢，描述他的出色，抄送他的老板就很好。
10
GeekAmI
2018-01-10
看到这里作为开发我很欣慰
6
拾叔
2018-01-09
适当的在项目过程或者项目结束后，当着工程师领导的面特别感谢这个工程师，效果非常不错，不一定是要正式的，侧面也许效果更佳，不虚伪。
作者回复: 嗯，总之脑子里得有这根弦儿，有这个意识
4
Dylan
2018-06-28
文中提到的对于上线交付时间的模糊处理是个非常好的方法，我准备去应用。总之做大蛋糕，舍满取半
2
冯选刚
2018-01-04
提意见的渠道呢
作者回复: 当面提就挺好，可以看看这篇http://qiuyuexp.com/problem-in-implementation/
2
悟空来 | Arthur...
2020-06-18
要有前戏，才有高潮，突然来一下谁也受不了，平时就要多在一起勾搭，需求来的时候，默契度，就显得非常重要了
1
Terry郑💫
2020-03-16
屁股决定脑袋，我也是正宗的开发转的产品，在不同的岗位上思考的东西是不一样的。对于开发而言更多的是去考虑逻辑的边界和复用的高可用。对于产品而言更多的是去考虑商业价值，需求痛点的把握。产品用同理心去对待工程师，主动背锅。是可以提高自己在团队中的话语权和影响力的。而不是单纯的一个任务的流转和派发。
2
时间之树
2018-01-10
与工程师合作最让我纠结的就是二爷提到的时间问题。大领导会找产品经理要完成时间，而产品经理需要和工程师沟通时间，周期太长大领导不同意，周期短了大部分情况下会延期，尤其面对工程师的延期，会很无奈。如果情绪处理不好，很容易与工程师产生对立。
作者回复: 潜移默化的改变，曲线救国
1
bing
2021-10-28
看到了第 20 篇了，提个移动端课程阅读的体验问题：阅读过程中，如果是长按，则会显示“划线、笔记、分享、复制”提示信息，同时选中当前段落，感觉这个体验不太好，因为当前毕竟是处在沉浸式阅读的阶段，手指滑动查看文章内容时，难免会长按，这是就蹦出提示来了，强行打断了用户的阅读过程。可以想想：用户究竟是在什么场景下，会做“划线、笔记、分享、复制”这些操作，第一遍阅读的过程中？还是第二遍、第三遍阅读同时深入思考的过程中？建议可以分析下具体的数据：用户在第一遍阅读的过程，究竟有多少用户使用了“划线、笔记、分享、复制”功能？同时个人的方案：在页面底部的操作栏，除“评论、收藏、设置”外，增加一个操作，如“阅读/思考”，默认“阅读”模式，长按不显示“划线、笔记、分享、复制”提示，切换到“思考”模式，长按则显示“划线、笔记、分享、复制”提示。确实是被这个提示烦的不行了，所以提出这样一个建议，不过PC端没找到建议入口，移动端输入太慢了所以就顺手提在反馈里了，希望池老师能看到。同时也想问下邱老师，对于移动端长按显示提示这个体验的看法。
展开
Sam_Deep_Thinking
2020-08-27
个人而言，这个专栏里，这篇文章价值是最高的。还是那个观点【产品和研发是一家人】，另外在创业公司，其实就是看【产品经理】和【研发】，配合好了，效能自然就有了。
Moon
2020-08-20
一个人会比较快，多个人才能走得远
种菜的渔民
2020-07-22
说来说去其实做人的基本原则和情商非常重要，技巧只是辅助手段。
张希音
2020-01-03
找共同假想敌（或者真的竞争对手），这招肯定是屡试不爽。毕竟，都是同一个战壕的兄弟，用共同的目标和共同的阵营，行动，思想上都会有一定的同步。
Gollum
2019-04-21
我就和开发说光靠我一个想是不够的，大家都要参与进来，多多发表意见，找找产品设计的bug~
赫尔曼n
2018-04-02
在哪些情景下是在帮工程师背锅那，有具体的例子吗？
Bonnie Mei
2018-01-11
目前基本上是需求评审，一般比较顺利，如果中途需求有漏洞，开发也会补上，后续我这边完善需求就行，前提是：不超过半个工作日，但是大问题面前，就要给时间了。有次开发跟我说：这是你该考虑的问题，不是我，然后离开了，开发兼项目经理，呵呵哒，我就懵逼了，原型上看不懂的就按照自己想法做，做错了，产品还不能说。后面还好，问题解决了
作者回复: 看不懂就按自己的想法做是个挺常见的问题，策略地说，委婉地说…
小紅帽
2018-01-10
#多听工程师的意见得到最近半年后台产品工作中这个点感受颇多；第一后台产品经验欠缺，第二对行业了解、业务了解基本空白；第一期产品躺过的坑就不计其数，比如何提好一个“API'需求。首先自己心里有畏难情感，不懂不了解相关技术知识，记得当初直接丢一个文档给技术哥哥，答应直接按别人家来做；有天CTO回国外了，技术突然跳出来，这东西做不了，你得重新提需求（这个过错100%由我来负责到底)，最终在坎坷、各种放低态度中解决了，平时关系也处理的好。最近提相关的技术需求时，就敲响警钟了；不懂没关系，查相关文档资料，问工程师他所知道的，比如字段、规则、甚至业务。强迫工程师做赶着时间节点的评估，我遇到结果是：画的是圆最终实现是椭圆的，然后大家都不满意；彼此付出的劳动成果不被认可，还会被约谈。
展开
作者回复: 嗯，强扭的瓜不甜

