20 | 产品经理如何与开发打交道（下）：合作与共赢
邱岳
该思维导图由 AI 生成，仅供参考
“兄弟阋于墙，外御其务”——《诗经》
上篇文章，我提到产品经理与工程师之间隔阂的原因，主要是思维方式的差异，以及关注领域的不同，然后聊到了几个加强沟通的方法，比如让产品经理向工程师介绍业务，以及主动去理解和学习技术等等内容，今天我们继续聊这个话题。
之前我提到过，因为角色的差异，产品经理和工程师变成了上下游。也就是产品经理折腾半天，做需求收集、分析讨论等等，然后做出 PRD 交给工程师之后就不管了，工程师拿到 PRD 之后做系统设计研发实施。我们希望工程师可以尽量早地参与到流程中来，产品经理则尽量晚地从流程中退出去。
全流程参与
对产品经理来说，首先要做到尽可能在项目的早期去跟工程师沟通。我们在安排一些项目的早期，可能因为很多东西没有最终确定，也不太想跟工程师说，觉得等确定了再沟通；但这样做很容易导致说的时候已经来不及了。比如 11 月 3 日通知工程师说：“咱们 11 月 11 日大促，这是三个需求你尽快做一下”，工程师会非常反感这种带着截止期限的突然袭击。
最好的方式是当某个业务有苗头的时候，产品经理就应该开始跟工程师交流，但这时候不要正式地去提需求，而是做一些非正式的沟通，否则后期如果有变化会让工程师觉得你出尔反尔。
除此之外，一定要邀请工程师来参与项目前期的需求收集和需求评审，不要觉得这种场合不需要工程师，等确定了再转述或者产品经理去宣讲就可以了。你需要尽可能让工程师参与，他可以更全面地了解项目和特性的目的，和不同利益相关者的顾虑和立场，也可以让工程师理解一些产品经理对产品细节的坚持。
除了让工程师往前走参与需求过程之外，产品经理也要主动往流程的后半部分延伸，去参与设计、开发、上线中的技术部分。比如在产品上线过程中出了 Bug，服务不可用了。
这时候产品经理应该干什么？可能有的人不参与，等着工程师自己处理，还有的在群里吵，谁的 Bug，什么时候修好等等；但是，其实更合适的方式是能够参与到问题解决中，去问一下具体是什么问题，需不需要帮助。
很多时候工程师在考虑故障的时候，主要会去想如何把出现的问题修好，而产品经理在考虑问题的时候，可能会考虑怎样把问题规避过去。比如说付款流程走不下去，工程师会想着去修复它，而产品经理或许可以协调一些资源，直接在某个时间段内就免费掉，先把付款流程绕过去，不损失用户。
但要注意的是，产品经理可以参与，但不要添乱，人家工程师在紧急地写补丁，你拉着人家说：“别写，先给我讲讲。”这样做就很不得体了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
产品经理与工程师之间的合作关系至关重要，本文提出了一些关键的合作策略。首先，强调了产品经理需要在项目早期与工程师进行沟通，让工程师尽早参与项目，以便更好地理解需求和项目目标。其次，强调了产品经理需要尊重工程师的意见，鼓励工程师提出建议，并且产品经理也需要在必要时为工程师争取利益。此外，文章还提到了产品经理不应强迫工程师做评估，而是应该尊重工程师的专业意见。总的来说，本文强调了产品经理与工程师之间的合作关系需要建立在相互尊重和理解的基础上，以实现更好的项目成果。 此外，文章还提到了一些实用的合作策略，如产品经理背一些工程KPI，以便更好地理解工程师的顾虑，同时也防止立场的对立；寻找共同的“外敌”，以促进团队的凝聚力；鼓励产品经理与工程师建立良好的个人关系，以促进更好的合作氛围。 总的来说，本文强调了产品经理与工程师之间的合作关系需要建立在相互尊重和理解的基础上，以实现更好的项目成果。文章内容丰富，提供了实用的合作策略，对于产品经理和工程师之间的合作具有一定的指导意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《邱岳的产品手记》，新⼈⾸单¥59
《邱岳的产品手记》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(20)
- 最新
- 精选
Ned有项目喝酒吃肉谈工作，没项目吃肉喝酒聊生活 相互尊重是原则，敢于背锅是觉悟作者回复: 赞总结
2018-01-0431
听天由己句句在理，职场残酷，建立良好的人际关系就至关重要了，二爷文章中的几句调侃真的很赞。 说起与工程师打交道，我自己的经历可供大家参考。 小宇是我们创业后认识的一位技术伙伴，熟悉 PhP 程序语言开发，在工作两年后，他辞去知名杂志社工作加入我们的创业团队，他负责技术，我负责产品，两人便因此相识了。 刚认识小宇之时，我还是十分稚嫩，关于需求讨论或是开发进度都不可避免地与他产生各种各样的矛盾，这一度让我十分压抑，似乎我的角色要被代替了。在我看来，他的确经验丰富，对于技术、产品、趋势、商业都有清晰的见解，很多方面我都需要向他请教，但我心里总是有些不甘，希望能够成为全面的产品经理。 再三反思后，我逐渐转变了自己的工作态度以及沟通方式，虽然他说话直白，但就事论事，我认为是很舒服的交流方式。后来，我们也慢慢变成了无话不谈的朋友，现在还在一起学习成长，相互理解。作者回复: 有这样的朋友，比一份工作还有价值，或许你以后会理解，记得一直跟他保持联系
2018-01-0415
孙伟贤工程师是我觉得公司里最好沟通的人，单纯的要命。作者回复: 哈哈哈哈哈哈哈哈，没错
2018-01-0614- 骆驼产品经理怎么帮工程师争取利益？还能升职加薪？一般都是各个部门做自己的review，当然二爷这个位置除外，你是老板，我说的是一般岗位的产品经理
作者回复: 有时候发一封邮件，表达感谢，描述他的出色，抄送他的老板就很好。
2018-01-0412 
拾叔适当的在项目过程或者项目结束后，当着工程师领导的面特别感谢这个工程师，效果非常不错，不一定是要正式的，侧面也许效果更佳，不虚伪。作者回复: 嗯，总之脑子里得有这根弦儿，有这个意识
2018-01-094
时间之树与工程师合作最让我纠结的就是二爷提到的时间问题。大领导会找产品经理要完成时间，而产品经理需要和工程师沟通时间，周期太长大领导不同意，周期短了大部分情况下会延期，尤其面对工程师的延期，会很无奈。如果情绪处理不好，很容易与工程师产生对立。作者回复: 潜移默化的改变，曲线救国
2018-01-103
冯选刚提意见的渠道呢作者回复: 当面提就挺好，可以看看这篇http://qiuyuexp.com/problem-in-implementation/
2018-01-042
Bonnie Mei目前基本上是需求评审，一般比较顺利，如果中途需求有漏洞，开发也会补上，后续我这边完善需求就行，前提是：不超过半个工作日，但是大问题面前，就要给时间了。 有次开发跟我说：这是你该考虑的问题，不是我，然后离开了，开发兼项目经理，呵呵哒，我就懵逼了，原型上看不懂的就按照自己想法做，做错了，产品还不能说。后面还好，问题解决了作者回复: 看不懂就按自己的想法做是个挺常见的问题，策略地说，委婉地说…
2018-01-111
小紅帽#多听工程师的意见 得到 最近半年后台产品工作中这个点感受颇多；第一后台产品经验欠缺，第二对行业了解、业务了解基本空白；第一期产品躺过的坑就不计其数，比如何提好一个“API'需求。首先自己心里有畏难情感，不懂不了解相关技术知识，记得当初直接丢一个文档给技术哥哥，答应直接按别人家来做；有天CTO回国外了，技术突然跳出来，这东西做不了，你得重新提需求（这个过错100%由我来负责到底)，最终在坎坷、各种放低态度中解决了，平时关系也处理的好。最近提相关的技术需求时，就敲响警钟了；不懂没关系，查相关文档资料，问工程师他所知道的，比如字段、规则、甚至业务。 强迫工程师做赶着时间节点的评估，我遇到结果是：画的是圆最终实现是椭圆的，然后大家都不满意；彼此付出的劳动成果不被认可，还会被约谈。作者回复: 嗯，强扭的瓜不甜
2018-01-10
GeekAmI看到这里 作为开发 我很欣慰2018-01-106
收起评论