【文章摘要】但出来混总是要还的，研发的兄弟们在实现产品的时候，这些细节闭环一个都免不了，否则他就不可能完成产品的自测。所以，这些问题如果在前期产品经理没有发现，那么到后期就会涌现。
在和研发的沟通中，产品经理们应该如何保持一个怎样的沟通姿态，都需要特别注意哪些问题？在这篇文章中，龙哥将向大家分享自己在这个话题上的部分心得和经验，以供各位产品经理们参考。
在产品经理的日常工作中，研发筒子们是个必须要打交道的角色，因为他们在产品每次从规划到落地中起到的作用是产品经理无法忽视的。
那么，在和研发的沟通中，产品经理们应该如何保持一个怎样的沟通姿态，都需要特别注意哪些问题？在这篇文章中，龙哥将向大家分享自己在这个话题上的部分心得和经验，以供各位产品经理们参考。
龙哥将从以下六个方面进行展开说明：
一、产品细节流程要闭环
很多产品经理，包括以前的龙哥，都犯过这样的错误。
产品终于规划完了，大致一看主流程是通的，但其实仔细分析的话，是可以发现有一些细节流程是没有闭环的。因为这些细节流程比较多、杂，很考验产品经理的耐性，比较容易出现漏检查的情况，尤其是交付研发时间比较紧的时候。
但出来混总是要还的，研发的兄弟们在实现产品的时候，这些细节闭环一个都免不了，否则他就不可能完成产品的自测。所以，这些问题如果在前期产品经理没有发现，那么到后期就会涌现。
一个合格的产品经理应该极力避免这种情况，因为一旦这种现象集中发生，你会比较尴尬，这感觉就像城门四面失火，刚扑灭了东门的火，西门那边又闹起来了。不但自己会受到影响，而且会让研发筒子们的心情变得焦躁：你这个PM是怎么干活的？即使他们嘴上不说，心理也难免会。
所以，在真正交付研发之前，产品经理要根据产品主流程补充细节流程，然后检查原型页面是否需要补充，保证产品在细节流程上的闭环。虽然说不能万无一失，但只要这样做了，就会极大降低出现这种问题的概率。
二、避免频繁变更需求
软件工程之所以出现的一个基础原因就是为了限制变化，因为变化会造成研发的工作量的增加，更可怕的是，有些变化可能会让之前研发的工作付诸东流，需推倒重来，所以，研发对于需求的变化这种事情一般都是not pleasure的。
而在产品经理和研发的工作交流中，据龙哥了解的情况以及自己的亲身经历，在交付研发后，这种来自产品经理的需求变动经常发生：今天要增加一个这个，明天又要增加一个那个，最让研发筒子们受不了的是昨天还说要做成这个样子，结果第二天早上一来又说这个样子不对，要换成另一个样子。
于是，也就有了下面这张让人忍俊不禁的、经典的图片：
其实，根据龙哥的分析和总结，这种来自产品经理的需求的频繁变动，由外界客观因素（比如市场情况发生变化，公司在这个产品上的战略发生重大调整等）所引发的虽然有，但总体来说比例极低，而因为产品经理思虑不周，乱拍脑门引起的占了大多数，大约在90%以上。
所以，为了不让研发的同学们发牢骚，好好干活，享受干活，作为产品经理的你应该在前期把该考虑的事情考虑完整，尤其是面对一个新问题的时候，不要急于做出决定，你完全可以告诉研发：
这个问题我现在有些想法，但感觉不是很完整，今天下午我想想，明天给你答复。
一个稍微迟来的正确的决定，比起一个及时到来但却错误的决定要有用的多。通过三思而后行这种做法，就能有效地避免思虑不周，匆忙之中做出一个漏洞百出决定的情况，从而有效地控制由产品经理自身引起的需求变化。
三、别偷懒，能写出来的就写出来
在和研发进行产品沟通的时候，产品经理不应该偷懒，对于研发和自己觉得有必要解释的地方，不要觉得口头给研发说清楚就可以高枕无忧了，否则，在实际的项目经历中你一定不会错过这样经历：
一个问题你给研发前两天说的清清楚楚的，结果这家伙今天又过来问你同样的问题。
然后你就会觉得有些不爽，就会有些抱怨：这个问题不是前两天才说过吗？
此时，如果对方是个比较厚道的同志，他可能会腼腆地承认自己忘了，但如果你运气不好，遇上那种死要面子的坑神，那一场不愉快几乎无法避免，而且，不愉快之后，该解释的问题还是要解释的。
所以，龙哥的建议是：产品经理对这种需要解释的地方，能写多明确就写多明确，不要嫌麻烦，不要觉得是体力活，你要知道这些工作如果做了，你会避免很多次重复的口头解释，避免很多内心的暗暗不爽，避免很多不必要的细节沟通上的扯皮，而且还能锻炼自己对产品细节的把控力，性价比其实挺高的。
四、适时跟进产品研发进展
很多产品经理在产品交付研发之后，就松了一口气，感觉终于不用那么辛苦地忙活了，这个时候很自然地产生一个想法：我的任务已经完成了，研发的工作是研发要负责的事情，我只要等着产品上线就可以了。
从工作分工上来说，这样的想法无可厚非，道理上是讲得通的，但龙哥想告诫大家的是：在生活中，很多事情不是说逻辑通就能运用通的，为了达到最终的结果，往往需要你往前再多走那么一两步，甚至三四步也有可能。
回到这个问题上来说，产品经理将产品交付给研发之后，不能做甩手掌柜，要舒适地、有节奏地跟进产品研发的进度和实际状况，这样一来对产品的上线时间有个准确估计，二来对于产品研发中存在的问题也能提早发现、提早解决。
对于第二点，龙哥稍微解释下：研发毕竟不是产品，他理解的产品往往跟你多多少少是有那么有些出入的，再加上研发同学在实现功能过程中主观或客观的一些困难、限制，最终都会让产品的结果跟产品经理的预期发生一定的偏差。而这样的偏差，产品经理是很容易发现的。所以，为了保证最终产品的结果正确，产品经理要多往研发这个方向走这么一两步。
五、尊重研发同学的价值
虽说产品经理是产品的负责人，但没有研发同学的努力，那么再好的产品最多只是个梦想。在产品从0到1的过程中，产品经理的心血不可否认，但研发同学的价值同样值得尊重，这一点对于产品经理，尤其是技术出身或者对于技术比较感兴趣的产品经来说，这一点值得强调。
具体来说，有以下几个情况需要注意；
产品经理在规划产品的时候，要及时跟研发团队沟通技术实现的可行性，以及实现的时间成本。不能觉得这个产品要做成什么样子，什么时候上线这些跟产品密切相关的事情都是产品经理说了算的，因为每个研发团队都有自己的技术客观事实，都有自己的能力边界，如果一个功能研发团队现阶段实现起来很困难或者周期很长，那就需要产品经理对相应功能进行取舍或者改变产品设计，而不能霸王硬上弓。这样不仅伤害研发同学的感情，而且也得不到自己想要的产品结果。
研发的同学们在研发的过程中，对于某些产品设计会从一个普通用户的角度提出自己的一些建议，如果这些建议产品经理之前没有考虑到，那就应该鼓励和赞赏这种建设性的行动，并且根据这些建议将产品进一步进行完善。而不应该觉得研发没有资格对自己的产品设计提出质疑，死要面子不承认或者无视，其实这样的情况受损失的其实最终是产品经理自己，因为只要对产品结果有帮助的，就一定是对产品经理的结果有帮助的。
六、留有余地
产品经理不是神（虽然每个产品经理都希望成为神）。有些时候，产品的某些地方，或许是流程，或许是细节，终归会因为各种各样的原因自己会想的不是那么确定。这个时候，留有余地就是发挥作用的时候了。
在交付研发的时候，要提前将这些地方进行说明，而且不能只说明这些地方的情况，要将自己的思考过程清晰地表达出来的，让研发的同学们知道你不是懒，也不是不用心，而是的确有些特殊的、可以值得他们理解的情况，然后在这些地方才有些不确定。
同时，你要给出一个大致的解决这个不确定的计划，让研发同学们大致有个底，然后竭尽全力保证这个计划最终实现，这样当你提出变动的时候，研发就不会像没有打招呼那样反应强烈，会比较配合和理解地去帮你实现这个变化。
以上就是龙哥关于产品和研发沟通这个话题的总结和分析，其中有自己的经验和思考，也很多经是跟其他产品经理日常沟通后的心得。
总体上来看，文中所列的几种情况还是有一定的典型性的，希望这篇分享能让做为产品经理的你，在日后跟研发沟通的道路上走的比较惬意、比较洒脱。
