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