经验总结｜产品经理和研发沟通的七个要点

沟通各方的磨合是必然的过程，只是磨合的久还是磨合的短，磨合的轻还是磨合的重。所以，沟通是一门艺术，产品经理需要慢慢领悟，才能与研发和谐相处。

从某个角度上讲产品经理的工作内容可以概括为两类：

1. 驱动自我规划需求。例如：输出原型框架图、PRD等。

2. 推动团队实现需求。例如：协调运营、研发等实现需求。

在所需要推动去实现需求的团队中，研发几乎是产品经理最为普遍头疼的、又是需求落地最为关键的团队。和研发沟通到什么程度，直接影响着需求能实现到预期的什么程度。

和研发的沟通已经是产品经理职业技能之一了，以我个人总结来看，沟通应该会有非常专业的技能点。本文将从个人的经验来看，挑几个重要的详细描述下，也快速的罗列些其他的要点。

1、沟通的要点

从整体的工作角度看，沟通的目的是为了能够让需求信息更好的传达给技术去实现。所以，本质上沟通解决的还是信息问题。

既然是信息的传达，那么理性的、客观的讲，就要以下几个信息传达的要素：

降低成本，提高效率

什么量的、什么类的信息通过什么方式表达出来才会让收听信息的人更好的接收，这就是降低传达成本的思路。这里的量、类指的是信息的内容量，信息的类别。

例如：

1. 内容量大的信息，肯定是当面无法沟通而奏效的，需要构调理清晰的落实到文档，对方反复查看，最终才会起到信息被接收、被有效处理。

2. 有些内容量可能不太大，但绕来绕去，不妨通过流程图、结构框架图等来表达这类信息。这就是对于不同量、不同类的信息采用不同的处理方式，来降低信息的传达成本，提高信息的传达效率。

很多初入职场者，有时会在传达信息时，该用文档的却使用了QQ、微信，或者当面去沟通非常多的信息量，造成结果还得再落实到文档、邮件。而完全可以通过当面几句话说清楚的白话文，反而使用了文档、邮件方式。有时一张图再加点注释就是完整的表述，却使用了各种的“如果”“当”“假如”等等列举case、描述跳转流程。这些都是没有去理性的去考虑降低信息传达的成本。

明确目的，强有依据

其实，理性地讲，每次的沟通都是一次工作事项。产品经理在传达信息时，都要有目的去开展传达。和研发碰需求时，双方争论具体的细节时，产品经理有时被牵着走，争论着争论着，不知所云了。其实，这时就是忽略了信息的目的。当所有的争论不休止时，乱套时，不妨回归一下目的在哪里。

具体到某个需求内容来讲，这个需求的目的是什么，为什么要达到这个目的，依据在哪里？这些要思考清晰，给研发讲解时，把这些牢记，不管对方提出什么各种异常，都不要忘记自己的出发立场、目的，不被牵制。阐明产品经理的需求目标。

这对于和研发沟通经验不充足的产品经理而言，尤其要注意信息的目的是什么，是说服对方做新的需求，还是说服对方按产品经理的交互来实现，还是改变产品方向。以及去验证自己的目的的正确性的依据是什么。

事宜周祥，把握时机

有时沟通是为了协调一些事项，那么最好是能在沟通之前，将事宜的来龙去脉都梳理清楚，什么时候开始，谁来做什么，多久才能达到什么目的或程度等，下一步做什么，各方人员如何密切关联、相互依赖等等。想要周祥，沟通前就要做好功课。

另外，这些事宜在沟通时，要在正确的时间范围内。例如：需要提前的说明的，需要及时安排的，需要其他配合的，很久之后才做，那么届时再沟通也不迟，提前反而容易被忽略。把握时机，沟通恰在好时，给人的印象是做事能把握节奏感，跟进好进度。

2、注重研发人员的理解角度

我觉着这个可能很多产品经理在最初时都遇到过，要解决这个问题，需要的是：先试探倾听，再找到规律，最后对症下药。

倾听：当产品经理先简单的描述完事情后，给出研发人员反馈的时间，让对方提出疑问。对方提出问题的过程，就是产品经理了解对方思路的过程，总结下来，就明白怎么沟通会导致对方歧义，又怎么沟通能让对方理解到位。不同沟通内容，都需要先倾听，尤其对于初入职场者。例如：沟通一个页面的交互，可能用产品的术语，对方吸收不了，那么可以采用类举的方法，拿出大众产品予以类比。或者，画出原型，以图示意。有些前后台数据调取，状态变化，不妨从操作场景、流程的角度予以说明到哪一步，到什么时候，会有什么变化，让研发有一个联想相关的线索，从而找到产品经理想要的。

找到规律：规律的形成，需要的就是总结，把倾听的反馈，要反复摸索。而且，没有通用的规律可以解决一切。规律会根据不同工作内容，工作对象而变化。例如：后台的产品往往沟通起来倾向底层，数据表都会涉及。前段的产品往往侧重场景，和研发沟通起来，需要注意对方对场景、对页面交互的理解度。

3、把握当面沟通的技巧

当面沟通，对于一些琐碎的、及时性要求高的事情处理是非常好的方式。排除各种主观、具体的情况，客观的概括角度来讲，当面沟通这种方式需要做到：阐明事宜状况、目的，需要哪些人做什么，参与方全部确定结果。

另外，当面沟通如果不是在会议形式下，应当简短利落，能快就快，也要注意沟通后的落实情况，例如：邮件、文档。如果不能简短处理，不妨停一下，准备会议。

当面沟通也会出现各种状态、情面、性格等各种复杂因素，产品经理沟通中，尽量避免个人的情绪在其中，也不要太多顾虑对方的情绪、性格，越是难以沟通时，越要保持理性、客观。快速、有效的解决问题，就是对自己最好的结果。

还有就是节奏，上面说到要先阐明事宜情况，再表明或确定下哪些人需要做什么，最后参与方全部确定结果，大家无异议。具体到工作当中时，各种性格、理解力、立场、角色的人交杂一起时，难免会有各种撕，产品经理要把握住沟通进展、方向，hold柱场面，是需求的问题，那么产品经理有依据就讲，无依据就退一步，整理完后再讲；是技术或者其他问题，则更多引导其他人内部确定，各自的问题各自去处理。

4、沟通无歧义

用双方一听就很确定的词汇沟通，表现出专业度，表现出确定性。避免歧义。

想要达到这种无歧义，其实需要产品经理自己首先保持清晰的思路。例如：目的是什么；通过什么依据判断出什么方式才是合适的方式去解决问题。整个过程，可以用词不准确，但整体的含义要清晰、确定。

如果要讨论一个问题，产品经理自身也不确定，那么需要的就是明确问题是什么，产品经理要确定什么，一步步有顺序的、有逻辑的去描述问题，讨论问题，直到解决。

5、沟通要站在双方都有责任的基础上

产品经理需要和技术统一战线，不是请对方来做什么，产品一味卑躬屈膝。而是要共同完成，流水线式的工作。产品经理应当避免情绪上的问题，好的沟通态度是当然好的，但不能太过好人，要体现出有逻辑的立场，体现出共同责任的立场。

我个人也见过有些公司的技术地位非常高，导致产品的沟通很难进行。怎么说呢？早日离开吧。

6、有套路的拉近关系

虽说是工作，但工作中也并非全部是工作。技术和产品也不妨找找共同点、找找共同话题，随意一点的沟通，其实可以不和职业化相悖。套路嘛，日久自然有。（哈哈~）

7、打铁还得自身硬

其实，在以上文中，我也在反复的强调：目的、依据、逻辑、理性、客观。这些恰恰都和自身相关。

另外，所有的沟通，其实都还是要看个人的，虽然有些经验分享，有些实际案例，还是需要根据自己的性格、思维来的。

沟通各方的磨合是必然的过程，只是磨合的久还是磨合的短，磨合的轻还是磨合的重。

其实我个人也是在不断的经历中去实践、总结，再去实践再去总结。各位共勉~