这周去参加了 QCon，涨了不少姿势。但是最有收获的反而不是纯技术方面的，而是与技术相关的内容。其中最有意思的是 @邱岳 的『怎样构建产品和技术之间的合作氛围』，那天本来想听听别的场次的技术内容的，但是一看一个熟悉的名字『孙志岗』，这不是大学老师么？那是我拿到最高分课程的操作系统老师，太巧了，于是就奔着老师去了。他是这个场次的出品人，听了之后，觉得很受用，非技术出身的讲师反而在演讲反面更有优势：口才更棒，演讲更吸引人。

我们在公司里面，总是会有很多的沟通问题，尤其是『程序猿』与『产品狗』，在很多时候，我们容易互相为敌，形成水火不容之势。而在这时候，双方最开心的莫过于看对方在公司里出丑。那么，我们都知道互黑开玩笑没事，但是一旦真的有矛盾，就容易影响公司氛围，破坏合作了。

那么，如何解决这个问题？接下来，把 @邱岳 的演讲内容简单复述如下，并加些我自己的感悟，会对原来的内容会有些修改。（可能有些地方记错了，之后再修改）

为什么产品与开发总是容易互相为敌

很显然，两者的思维方式不一致：产品总是在思考 Why 的问题，而开发总是在思考 How 的问题，在两者的交集中，才是我们的 What，或者说 PRD 与产品。

而在我们传统的开发流程中，需求总是从需求方来，到产品经理产出 PRD 之后才会交到开发手里去实现。这就导致了两者之间的机械化流程以及沟通方面的单一方向流动，这是不可避免的。

如何才能解决困境

互动有无

产品需要理解开发的 How，即学习开发的技术内容，不是说非要去跟开发一样工作，而是得了解技术语言，当开发说出一个技术术语的时候，你得了解大概是什么东西。同时，得把自己 PRD 中的价值详细交代给开发，而不是简单把 PRD 扔给开发：我相信优秀的开发总是会让开发真正了解到需求中的价值，有句话分享给大家：『在让别人建造一艘船的时候，首先要做的就是激起他们对大海的向往』。

对于开发来说，你得理解业务术语，产品经理经常说的业务内容是什么意思，有什么价值，同时将技术的实现给产品说说，让他们也涨涨姿势：这有一个非常明显的好处，产品了解到技术实现的过程与难度之后，一方面他会尽量帮你争取更多的时间去完成，另一方面也会在以后的新相似需求中，给你预留更多的完成时间。

另外，数据埋点细化需求能帮开发理解用户，因为这时候开发能看到需求，方便开发以产品的角度去加深对产品本身的认识与理解。

在制度上，开发与产品可以制定相应的流程，来经常性地互相分享知识。

设身处地

在我们传统的开发流程中，产品会组织可行性会议，来召集开发来开会。但是，这有个问题：会议总是正式的，因为这时候的需求已经意味着需要实现了。因此，产品可以做的就是，尽早将需求非正式地通知给开发，比如一起吃饭的时候，一起上下班的时候，任何只要是非正式的时候都可以。这样，对于你来说，能增加开发对你的好感，容易养成兄弟情谊，而开发也会有比较强的 『参与感』。

另外一种方式就是，参与技术问题的解决，比如总会有 BUG 出现，那么当影响到用户的时候，你就可以帮开发去帮忙跟运营或者客服去沟通，说明问题，让开发可以专心解决问题。这里需要说明的是：不要『暴力沟通』，即不要使用『暴力词汇』：『怎么又出 BUG 了？』，『怎么又是你？』，『是不是你写的 BUG ？』。相信我，这也是为了你的人身安全考虑 :P。

对于开发来说，积极参与业务会议也是一种能够加深理解产品以及业务的方式，虽然有时候会浪费时间，但是，以后你总是会需要了解到具体业务需求的。

在制度上，产品与开发可以轮流当 PM，加深合作，也有助于互相理解。同时，新的需求，最好是同时到达开发与产品，这样的话，产品与开发就可以省点时间去沟通细节，也会有一同作战的『参与感』。

在这里，我也想说，我们常说要让公司里面的每个人都要有主人翁精神，其实，让开发尽早参与到需求的制定，就能大大提升他们的主人翁意识，让他们更积极对待需求，拥抱变化，甚至能让他们主动帮产品完善需求，同时减少出错，更早并且更好得完成需求。

严于律己

我们常说要严于律己，宽于待人，但是往往在现实中总是容易反过来。

因此，对于产品，不要代替开发去估时，这是大忌，这会造成的一个后果就是『你这么牛逼，你咋不自己去实现呢？』。产品有自己的专业领域，替开发去做他们做的事情，是一种非常不专业的行为，易招致反感。

另外，『克制变更』就没什么好说了，开发最痛恨的莫过于『那个，XX 啊，需求有点小改动』，分分钟都会让开发暴走。

对于开发来说，负责任是会被每一个产品都肯定的品质了，上线除了问题，开发不能瞒着，更不能大家知道了之后还逃避责任，找借口。同时，出错了第一次，没关系，大家也不会过分责备，而且文化氛围良好的公司，甚至会『鼓励犯错』，只是，不能再犯第二次错误，因为这涉及到责任心了。

『拥抱变更』也是没的说，需求总是会变的，当产品那么尽心克制变更的时候，你就怜悯下他们吧 :P。

制度上，对于长开发周期的需求，不要给需求定死交付时间，开发最痛恨的另一点就是，定一个定死的日期上线，然后倒推需求完成时间，这是一种不尊重也是不负责的表现。我们更想的是：『弹性交付』，给产品预留足够的时间可以将产品做得更好。

这里补充下自己的想法：显然，这可能不是敏捷开发流程，因为在敏捷开发流程中，我们会强调承诺的重要性，将任务拆分足够细之后，我们会能更准确估计开发时间，只是也是不强制交付，我们会要求开发人员分析延期原因，并在下次迭代中调整估时，同时在之后的迭代中，努力达到越来越准确的估时。

建立信任

信任对于开发跟产品来说，是必须的，不然会造成协作上面的种种问题，『文档驱动开发』就是个明显的例子。

因此对于产品来说，有准备的试错，即准好前期的调研工作，将会大大减少开发中的需求变更次数，同时也会让开发认识到你的专业能力。及时通报需求的进展也会让开发有准备，也会让需求更快被开发理解。

不知道你的公司是否也有 KPI，如果是的话，一般来说，你是不会背技术问题的 KPI 的，因此，不妨承担起责任，即帮开发『背黑锅』，也是一种能赢得开发信任的讨巧方式。

然后，当需求顺利上线之后，你是否会想到给开发们发红包呢？其实还有一种非常有效果的办法：给开发向上争取利益，这对于你来说也就是写封邮件表扬他们而已。

当开发知道，你主动为他们背黑锅，并为他们积极争取各种利益的时候，他们有什么理由不帮你好好完成需求呢？

而对于开发来说，不评判需求的价值是你可以做的，毕竟这属于产品的专业范围，而且需求往往是从上层来的，然后到了产品手里，他们也改变不了什么，他们可以帮助你了解到产品的价值，但是请你尽量不要以自己的角度去评判。

对于具体的需求排期，承诺具体交付时间尽管是挺纠结的，但是在产品已经帮你争取到足够多的时间之后，你就忍忍承诺个具体时间把。

另外呢，如果有些需求细节是产品没有想清楚并且是你的举手之劳，你可以帮着去完善，或者直接帮着实现了。这是个非常有意义，也是可以帮助你赢得产品信任的方式。

制度上，产品与开发可以互相背 KPI，可以让他们形成一个利益共同体；同时，为了防止产品与开发互坑，可以将产品与开发长期安排到同一个业务领域中；还有就是适当『追责』，适当批评就行，不要在之后一直提起这个问题，罚钱更是没有必要，（当然了，罚钱如果是用来请大家喝个下午茶倒是不错的）；还有个很取巧的方式，便是制造外敌，我们常说『不有外患，必有内忧』，因此，制造外敌之后，能让公司内部一致对外。

P.S.

其实产品与开发本就是共同体，『本是同根生，相煎何太急』。我们没必要互相为敌：努力增进沟通，加深理解，能让我们更好更快地完成任务，达成双赢，或许，还能变成一生的好朋友。

P.P.S. 关于 QCon 演讲 PPT 下载地址

http://ppt.geekbang.org/qconsh2017

首发于 Github issues: https://github.com/xizhibei/blog/issues/60 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/zh-cn/2017/10/22/how-engineer-and-product-mgr-get-along/