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

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

想看更多产品干货文章？推荐极客时间专栏《邱岳的产品手记》，一次订阅、永久阅读。即日起，戳此订阅立享以下两大福利：

福利一：原价 ¥58/45 期，极客时间新用户注册立减 ¥30

福利二：每邀请一位好友购买，你可获得 18 元现金返现，多邀多得，上不封顶，随时提现（提现流程：极客时间服务号 - 我的 - 现金奖励提现）

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

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

全流程参与

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

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

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

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

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

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

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

多听工程师的意见

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

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

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

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

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

不要强迫工程师做评估

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

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

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

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

背黑锅与争取利益

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

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

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

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

互背 KPI，同仇敌忾

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

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

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

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

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

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

注：以上仅为文章的一部分，欲阅读全文，请点击此处订阅专栏（支持微信支付）****。一次订阅，永久阅读。