19 产品经理如何与开发打交道（上）：打破思维的边界
“横看成岭侧成峰，远近高低各不同。——苏轼”
在产品经理的日常工作中，开发工程师可能是我们打交道最多的角色，可是，这两个角色之间却有很多难以调和的矛盾，网上开发工程师怒怼产品经理的艺术作品很多，各种吐槽图片和文章俯拾即是 。
今年的 QCon 会议我也听一个段子，据说在大会的中午自助餐厅里，不同公司相互陌生的工程师，都靠吐槽自己公司产品经理迅速建立了友谊。
我自己写过程序，又成为产品经理，对这个问题有一些自己的理解，今天我就根据这个话题来谈谈产品经理如何同开发打交道。
为什么与怎么做
首先，我们来一起想想是什么原因导致了这两个角色之间的对立。
在面对产品或者特性时，产品经理和开发脑子里的东西是不同的。对于产品经理来说，他想的可能是客户、市场、盈利、竞争优势、政策风险、从哪里获客等等，这些东西想清楚之后，他的产出可能是 PRD，对产品功能需求的描述。开发一看，你折腾半天就这么一个东西，三页纸，没什么难度嘛。
开发脑子里关注的是什么呢？开发会关注手头的系统是不是遗留系统、系统架构有没有限制、公司的技术栈是什么样的、整个链路架构有没有问题、需不需要重构等等。这些东西产品经理可能不关注或者不懂，所以就看着一个挺大的开发团队做了很长时间，推出了一个特性，好像也没什么难度。
作为产品经理，有时我们会低估一个特性背后的技术成本。看什么都觉得简单，人家淘宝也有这个特性，为什么工程师说做不了呢？
尤其是通常在业务初期的时候，为了快速推进，工程师在实现上会做一些比较临时的东西，后期逐渐流量和复杂度提高，即便功能没变，也要花费大量的精力去调整技术架构。
所以你可以看到，产品经理脑子里的东西偏向“为什么”，而工程师脑子的思维方式会比较偏向于“怎么做”，两者的交集在“做什么”上面。也就是说刚才说到的，工程师看到好像产品经理背着手写了三页纸的 PRD，产品经理觉得工程师忙活半天就是一个简单的小特性。
久而久之，就会由不理解变成不信任，越不信任就越缺乏交流，演变成对立。
甲方乙方
关于这个话题我采访过我媳妇，她是做运营的，我说：“开发和产品之间矛盾这么激烈，你怎么看这个问题？”我媳妇觉得很奇怪，问我，你们不是一伙儿的吗？搞不懂为什么天天吵。
其实大部分公司中，最初设计组织的时候都会把产品和开发放到一起来看，希望这两个角色能够合力完成产品的设计和实现；但是在这个团队内部，随着人越来越多，就会有角色的分化，进而有了流程的分化，慢慢形成了甲乙方，或上下游。
如何去分辨团队从合作关系变成甲方乙方的关系呢？
有几个非常明显的信号，第一个是留证据，就是说了什么不算数，要发一个邮件签字画押；第二个是开小会，也就是在跟工程师开会之前，先自己角色内部开个小会，商量怎么对付对方，准备好对策之后再开大会；第三个是用词的方式，当你发现大家的用词越来越谨慎，并且开始在闲聊的时候区分我们和他们，设置大家开始试着从第三方了解彼此在干什么，了解对方对自己的评价等等。
类似的信号如果反复不断地出现，通常就意味着双方开始逐渐走向了对立，如果不加干涉，合作氛围就会出问题，一定要及时发现、及时处理。
加强沟通，互通有无
接下来我们要说怎么去克服双方可能出现的矛盾和对立，第一个要提到的，也是最重要的方法就是沟通。刚才我们说到产品经理脑子里是“为什么”和“做什么”，工程师脑子里是“做什么”和“怎么做”，过去产品经理和工程师的沟通通常会集中在做什么这里；更好的沟通就是要让产品经理把为什么告诉开发，让开发把怎么做告诉产品经理。
彼此说清楚自己的顾虑和困难，英文里有个说法叫做“ on the same page”，就是指产品经理和开发能看到彼此可以看到的东西，互诉衷肠，互相温暖。
专程交代业务规划和产品价值
对于产品经理来说，一定要专程交代产品价值。所谓专程交代，是指不要只在需求评审和需求沟通的时候才去介绍产品的来龙去脉。这是不够的，一定要拿出时间和精力去做专程沟通。
比如平时闲聊的时候，下午茶的时候，一起吃饭的时候，我之前经常会跟合作的工程师在吸烟室里聊，不说项目和需求，而是讲目前产品的状态，为什么要做现在的东西，之前做的东西的近况如何，业务目前是什么状态，接下来可能会向什么方向发展等等。
如果你在做项目的时候去沟通这些，工程师会本能地有所防备，因为你是有企图心的，你想说服工程师投入时间和精力做项目嘛。但当你专程去讲的时候，这个企图心就被放下来了，讲得多了，就会慢慢开始有共鸣。
一开始这么讲的时候会看起来像个神经病，但久而久之，工程师会理解你是真的在沟通，在共享信息。最后达到什么效果呢？就是当你真的开始提需求和项目的时候，工程师会非常理解，有种心照不宣的默契感觉。
掌握技术概念和技术语言
产品经理要掌握技术的概念和语言，这个蛮有意思的，每个公司都有技术栈，技术栈有不同的特点，我刚开始做产品经理的时候，主管知道我有写程序的经验，就让我去看代码，甚至让我去写代码，给我代码库的权限。他的目的就是要我知道，当时的技术栈是什么，基础的架构是什么。
看代码是个效率不太高但非常扎实的办法，还有个办法是去写非功能需求。因为工程师的“怎么做”有很多是在水面下的，比如他要保证可用性，保证安全，比如做一个简单的文本框让大家写东西为什么要花那么多时间？可能就是为了保证不要被黑客利用它做注入攻击。
如果产品经理把这些非功能性需求一条一条写下来，比如浏览器适配，做一个功能可能很快，但要保证在各种各样的浏览器下都表现稳定，就需要花费额外的时间，可能比做出这个功能花费的时间还要多。这些东西写下来，产品经理就可以大致了解真实的开发工作量。
另外就是作为产品经理要跟工程师多接触，让他们多给自己讲一些技术，优秀的工程师提到技术通常会滔滔不绝，如数家珍。当你了解基本的技术常识之后，就会理解技术成本和技术的局限性，知道哪里是技术的边界，如何跟产品更好地做搭配。
总结
我们从产品经理和工程师矛盾的原因开始说起，提到产品经理会更多地关注为什么和做什么，而开发会关注做什么和怎么做，可能彼此之间并不尽然理解对方的思维方式，另外角色的分化又会导致双方逐渐成为上下游的对立关系。
接下来介绍了一些加强沟通，促进相互理解的办法，建议产品经理多向工程师解释产品的来龙去脉，也要多去了解技术领域和技术语言，下一篇分享还会继续聊这个话题。
如果你是产品经理，你在工作中是如何与工程师保持合作的？如果你是工程师，你会反感产品经理的哪些行为？你心目中理想的产品经理是什么样子的？欢迎在留言中分享讨论，我们下次分享再见。
- 精卫鸟 👍（47） 💬（1）
我见过的产品同学被怼，通常逃不出下面两点诱因[偷笑] 1. 需求变更其实没什么，之前没想清楚就说没想清楚，千万别拿用户和体验当幌子，把自己摆在道德高点，让变更变得理直气壮。 2. 永远不要和开发说这个需求你也不想做，都是老大们让做的; 或者说你这个功能不是我要的，是业务部门要的。开发通常会觉得你没担当，而不是理解你的无奈。 原则上不能守护好产品特性的产品经理，与不能守护好代码完整性的开发，都是很难获得尊敬的。
2018-01-04 - Little__ZM 👍（12） 💬（1）
我也是开发专产品。 理解痛点，技术难点。这有时候是好事，有时候会拦住我的想法。 好的一面，我的产品文档，大家愿意看。不好的一面，每次想方案，都会被这个好实现么，拦住脚步。
2018-01-19 - 拾叔 👍（7） 💬（1）
作为后台产品经理，我天天跟开发厮混到一起，可以充分了解开发自己对产品的需求，其实很多开发并不是只单纯想怎么做，很多时候他们会关心为什么做，做的好处是啥，是否是可以复用的？然后在充分了解需求后，好的工程师甚至会给你提供多种实施方案，和产品一起讨论最终得出最优方案。 必要的沟通，就是给开发工程师的尊重，让开发能倍感尊重，开发出的代码质量都会好不少。
2018-01-09 - 张伟 👍（4） 💬（1）
二爷聊的这个确实是一个不错的选题，建议可以做成一个系列，把产品跨职能沟通过程中遇到的坑分享和分析一下，应该是比较有意思的系列
2018-01-03 - 小紅帽 👍（3） 💬（1）
＃我与开发沟通日常经验得到 1.好好说话达成共识，彼此工作目的服务于上级，实现价值。 2.了解彼此，提好需求，同开发技术哥讲清楚为什要做这个功能，最终要实现的结果是怎样的；同时要去了解怎么去实现，过程是否会遇到问题及开发成本。 3.多一起吃工作餐多交流，绝大部分问题都可在此化解。 4.态度一定要好，关于技术相关知识不懂的，多问一句，私下自己多补一点。
2018-01-04 - 听天由己 👍（2） 💬（1）
面对功能的第一反应，我是从用户、场景与问题入手，从第一要点来看，二爷是先考虑业务需求吗？ 关于与开发沟通，我最深的感触就是，要讲清楚为什么，以及这件事情与整个产品的关系，开发不会单独为了某个需求而改变架构，要让他们理解这是产品的分支，而不是另辟蹊径。 还有就是，真的需要提前花时间沟通，而不是现场冲突，很多想法在开会时其实不见得容易问出来，就像二爷说的，每个人都有防备心理，毕竟这是工作，不是闲聊，有些事情不提前搞定，后续再开会就十分难看了。
2018-01-02 - 陈悬高 👍（0） 💬（1）
个人觉得，发邮件签字画押还是要的，毕竟好记性不如烂笔头，而且这对于规范流程确实有帮助，不算对立的表现。
2020-02-17 - Marnie 👍（7） 💬（0）
作为开发，最烦产经说的一句话，“你去网上搜搜，肯定有现成代码”。 第一，这让开发感觉被看轻。好像开发连基本的检索能力都不具备，还要你产经来提醒。 第二，既然开发提出了代码可能达不到预期，就代表项目里可能出了问题。产经根本听不懂，只是一味强压。 还有一点儿，开发提出图片不合适需要修改，产经来了句“反正下次要改版，先凑合用就行。”那反正要改版，我代码是不是也不写你的新需求了？
2018-09-15 - 时间之树 👍（3） 💬（0）
作为产品经理，与开发沟通时，其实也应该把他们当成用户，站在他们的角度分析其真正的需求是什么，关心的是什么，然后以诚恳的态度加强沟通。
2018-01-10 - 小寞子。(≥3≤) 👍（1） 💬（0）
我们做的更狠。 直接在把开发人员放在需求挖掘团队。整个团队一起做调查 需求挖掘。 产品设计。。这样每个人都完全明白目标是什么。为什么要写 怎么写。 端到端的参与
2020-12-11 - Dylan 👍（1） 💬（0）
大家都是有一致目标的：让一个产品活的更好，活得更久，所以产生对立的情况，是由于双方共享信息不够透明及时，信息不对称导致猜疑和矛盾。主动沟通，弥补对方的信息短板，市非常好的沟通法则。学习了，产品把“why”讲明白，是在讲，用户场景需求，工程师把相对通俗易懂的“how”讲懂，双方共同决定“what”的方向。
2018-06-27 - 以吻封笺 👍（0） 💬（0）
矛盾原因是产品和开发所处位置导致，两个位置上的角色思考点不同。产品经理设计产品，他的上游有客户、销售、成本、运营等多方要求，他的下游是开发。开发的上游是产品经理，基于PRD实现产品，考虑的是技术实现。而双方缺乏对方领域的知识和经验，没有换位思考，就容易导致冲突和不信任。
2024-12-13 - 陌兮 👍（0） 💬（0）
作为研发，最不喜欢的是那种文档写的不清楚的产品。很多需求都不写其价值，做过的需求也没有得到反馈。其实作为开发，很关心自己所做的需求背后的价值。
2023-02-15 - Geek_350811 👍（0） 💬（0）
我们做的不是产品，而是用户需求的定制开发，有时候用户提出各种减少自己操作系统又能完成业务工作是需求，然后设计好提交给开发的时候，开发总说做不到，具体原因也不说，就一直怼你们需求很傻逼、你们设计很反人类、你们根本就不懂需求啥的，有时候也很无奈；里外受气。
2021-09-29 - 老燕 👍（0） 💬（0）
作为产品经理需要多做项目前的沟通工作，和工程师说明为什么产品要做这样的功能，会产生什么样的意义；同时，换位思考，和工程师了解可行性的难度，共同探讨解决问题，形成合力。
2021-04-08