身为PM的你，是否也在为日常与开发沟通的不顺利而感到痛苦？与其埋怨上火，不如尝试一下改变。

最近看到很多小伙伴在讨论产品和开发之间的恩恩怨怨，这个被外界戏虐为“相爱相杀”的两个角色，分分钟会由一个战壕的兄弟变成对立方，但事实是我们又不能大干一架之后甩手走人，工作还要做下去，日子还得过下去，那么，如何在保证友好的前提下顺利达到预期目标呢

有句话叫“谁痛苦，谁改变”，也许你会说，为什么是我改变，因为谁改变，谁受益。

作为PM，如果感觉到了日常与开发沟通的痛苦，不妨从以下几方面做一些尝试：

一、大局观

大局观之所以放在第一位，是因为它是我们聚在一起的原因，也是我们解决所有问题的导向。

当产品与开发为了某个细小问题进行争执时，不是为了谁输谁赢，而是为了实现目标把事情做得更好，秉承这个理念会让你的视野更加宽广，也许你为了一个争执气得想愤然离职，但你一定要清楚，开发的同学之所以提出来想法，也是有自己的担心和顾虑的（故意挑衅的除外）。

我个人的经历是在一个新的开发同事入职不久，跳过我和技术经理，直接去向部门负责人沟通了心中的顾虑，感觉日常问题没有人商量，担心做出来的东西会被认为很差很不好。

在我最开始得知这个消息时也是很吃惊的，因为技术经理和我们不在一个办公地点，可能技术上支持较少，但也并不是全无支持。另外产品与技术对接的时候，并未察觉到他的困惑和无助，只是感觉到了他本人的日常表现有些懈怠。另外大家平时工作都很忙，并不会太细微感知到个人情绪，而且男生的情绪一般也不外露，所以我的上级在跟我说此事的时候我一方面有些自责团队工作没做好，另一方面觉得如何维系整体的团结一致迫在眉睫。

那时候团队刚刚组建，很多人员并未到岗，随着后期团队的健全，我们形成了定期定时的沟通机制，并且以OKR为导向一起分享阶段性的目标和关键任务，工作之余也会有一些日常的交流，让大家在这个群体渐渐感受到归属感，放下了最初的戒备和不适，慢慢变得越来越团结，越来越有凝聚力。

每一次的爱恨纠缠其实谁对谁错并不是最重要的，心里始终有一根弦，那就是我们都为了共同的目标，在这个大背景下去解决问题，会少一些个人恩怨，多一些整体协作。

二、同理心

有时候即使一个岗位之差，也会有隔行如隔山的感觉，作为产品你关心的是需求有没有被实现，而开发更看重的可能是自己的代码成本以及整体质量。

同理心说白了就是能不能站在对方角度感受到对方的处境，善解人意。在和开发沟通的时候，或者开发对你的需求提出质疑的时候，也许并非是对你需求的不满，而是技术实现上真的存在不便和困难，这时候不妨坐下来好好沟通，语气柔缓的了解他们的担心顾虑，一起想办法来解决堵在他们前面的困境。

我记得在前几年做一个产品的时候，市面上并没有同类可参照和分析，我和技术总监针对需求进行梳理后，进行了创新式的产品设计，交付开发同学的时候，对方是个技术骨干，觉得产品设计略显新颖，是否可以参照一些成熟的范例。其实他的本意是这样，但说出来的话容易让产品觉得是在质疑和怀疑，在我意识到他的话语背后可能是针对创新设计开发的担忧之后，跟他讲述了具体的需求情况，并说明这套设计方案是和技术总监一起商议出来的，他才放心的去进行开发。

而后几年，当初的那套创新式设计陆续在我后续的产品中不断被借鉴和完善，我也特别欣慰当时敢于创新和尝试，让设计日趋成熟，也让我日渐成长。

如果秉着一个目标为原则，在现有状况下更合理的利用资源以达成目标，减少试错之外不必要的浪费，尊重开发同学的时间和工作，或许会得到更多的理解和认可。

三、谦虚态

也许是因为自身不懂技术的原因，让我在和开发沟通时一直很谦虚，除了普适性的方案，在涉及复杂情况时我总会耐心询问其中的困境，看看能不能提供一些跳出技术思维的方案和解决思路。

产品经理是否需要懂技术，这是个普遍性的问题，很多人觉得必须懂，很多人觉得懂点更好，还有人觉得不必懂，其实各有道理。

原则上来说有技术背景的产品经理或许道路更宽广，而懂一点之后更利于和开发沟通，全然不懂的也并非没有生存之路。

记得有一次前后端两个同学在讨论如何将一个还未创建的集成跳转加在代码中实现暂时性的页面跳转，商议之后问我的意见，我说后台不是提供了添加URL的地方，直接把页面URL填进去就可以啦。他们恍然大悟。

另外随着工作经验的丰富，对于技术可行性会越来越熟知，同时打开“检查”选项，也能根据页面内容看懂一些代码逻辑。

其实不管是技术型产品，还是纯粹的产品，当PM在与开发沟通时都该保持一种谦虚的态度，术业有专攻，若不是产品负责人，PM与开发并无直接上下级关系，你不是团队成员的老板，所以做事务必保持谦虚和谨慎。

四、勤跟进

当需求交予开发实现的时候，产品经理会从一个引领者更多的变成一个服务者，这时候就是项目管理的重要阶段。

刚开始做产品的时候，我总觉得给技术讲完一遍原型，他们就都懂了，剩下的就是做了。可现实情况往往不是这样的。

因为你是设计者，所以你很清晰，即使不看页面，脑海中也能记得每一个功能按钮在哪里，流程逻辑是怎样，但对于开发来说，他们脑中的思维并非产品表面看到的那样，所以从产品实现上要实时跟进，确保开发理解的一致性，而从进度把控上更是需要产品来操心的地方。

勤跟进的好处一方面当发现开发与设计不一致时，可以随时沟通，并且了解他们的困境，免得全都做完的时候才看到是个面目全非的东西。另外若真有困境，可以产品和开发一起来商议解决，是更换表现形式还是完善逻辑流程，这又说到了开头的第一点，以实现共同目标为主，在大局观的前提下做调整，并不意味着谁战胜了谁。

勤跟进的另一大好处就是任务细分拆解后，每个人可明确每一天的具体目标。网上有个段子是说现在上班每天有效工作时长也就2-4小时，其他时间不是在准备状态就是在休息调整。

当今环境下提升效率是每个公司共同的需求，其实大家并不是没动力，有可能就是目标不清晰，加之人性本来的拖延，导致进度滞后。作为产品经理，对于推进整个的执行过程，是漫长而艰难的，每个人都是被动的，如果你主动，你就会与众不同。

五、善交流

善交流其实可以体现在上述的每一方面，那么什么样才算善交流呢，我觉得可以算作沟通的艺术。你说出的每句话是否包含敌意，能否让人接得住，否定性的话语能否换个方式去说，利于大家去接受。

作为产品经理，其实单纯写需求画原型并不难，难的更多在与人交流和沟通，除了上述的大局观、同理心、谦虚态、勤跟进之外，良好的沟通交流能力会让你在工作中更加游刃有余，当然所谓的“善交流”并不是说处事圆滑，尤其对于产品技术人员来说，还是实干型的人多一些，那么在最初的阶段，不要想一些旁门左道，踏踏实实以一颗真诚的心待人，那么别人也会真诚待你。

我时常会看一些老的电视剧，《大宅门》中斯琴高娃老师饰演的“二奶奶”在艰难中重整家业，总是能给我一些鼓励，她说“退一步并不是忍让，而是为了在将来更进一步”。

想想工作中又何尝不是呢，身在职场，谁没遇到过焦头烂额的时候，但实力是获得尊重的前提，打铁还需自身硬，以谦虚的心态面对一切，以大局为重，善解人意设身处地为他人着想，踏踏实实做好自身工作，用自己的能力得到认可和尊重。

结语

最近看到一段个人感悟：年轻的时候，总是会想「为什么这件事情要发生在我的身上」。现在则会想「这件事情来到我的生命中是想教会我什么呢」。角度的不一样，格局就完全不一样了。

产品和开发除了“相爱相杀”，还可以愉快的玩耍，大家共勉！

#专栏作家#

慕斯姑娘，微信号：musiguniang，公众号：产品那些年，人人都是产品经理专栏作家。关注金融科技和大数据领域，擅长产品规划和落地。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议