编辑导语：似乎在互联网行业，产品经理和技术经理互掐是一个常见现象，二者是天然对立关系。这篇文章作者详细介绍了产品经理与技术经理沟通要领，感兴趣的小伙伴一起来看看吧。

如果你身在在互联网行业，就一定会经常听说产品经理与技术经理互掐的事情，甚至连脱口秀演员编段子都会用到产品与技术对立的梗，这类事情听多了就会产生一种错觉，似乎产品和技术天生就是不能和睦相处的，外人看来这两种职业的人更是成了一种天然对立的符号。

作为一个产品，我可以负责任的说前面提到的这种情况明显是跟实际情况不符的，虽然有些时候产品和技术的确是会有一些意见上的争论，但也完全没必要演变成对立关系。

相反，在实际工作中产品和技术其实是最紧密的合作关系。之所以会流传出上面提到的那些相互对立的传说，是因为他们的之间需要沟通和探讨的东西实在太多了，稍微有几次谈不好的就会被别人当做热点事件传播。

从传播学角度讲，这些负面内容更容易吸引大众的注意力，所以有一千次良好沟通不会有外人知道，有一次不好的沟通就能传很久。

我们没办法改变传播学的规律，但可以改变自己的沟通方式，让那一次可能产生负面传播的沟通永远不发生。这也就是我们今天想要展开聊聊的内容，关于产品经理与技术经理沟通时的一些重要事项。

一、认知方面

想要做好什么具体的事情，首先要建立一些最基本的认知。好的认知就像是一个灯塔，能在你偏离航线的时候及时提醒你回归正确的航向，所以我们在聊具体的沟通细节之前也要先说一下关于产品与技术技术沟通的基本认知。

1. 是协作不是对立

这是一个大前提，很基础但同时也很容易被忽略。产品和技术作为互联网产品生产的两个重要岗位，是完成一个产品必不可少的两个角色。

在这样的背景下不难看出他们的目标其实是一致的，就是要完成最终的那个作品。也就是说产品和技术从来就不是对立的关系，而是协作关系，是一条生产线上两个不同的环节而已。

记住这一点，在未来沟通过程中遇到分歧时优先去思考如何去更好地达成结果，而不是一味地坚持自己的观点，往往能够消解矛盾进而找到那个对结果更有利的路径。

当两个人为了同一个结果去探讨什么内容的时候，他们能够达成共识的概率一定会比“他们为各自目标努力”更高。

把这一条作为“灯塔”中的第一条就是希望在后面每次遇到阻力的时候，我们都可以想到它，当你能看到更远的目标时就不会拘泥于眼前的路到底该怎么走。

2. 合理安排沟通频次

对于完成一项工作来说，沟通只是其中一个环节，虽然重要，但从来都不应该是主线环节。它就像是润滑油，你不能没有它，但也不能只有它。

它只应该出现在真正需要它的时候，出现在需要它的地方。沟通太少或者沟通太多都会影响工作目标的达成，所以我们在将沟通之前先要学会把握沟通的节奏。

沟通节奏正常情况下应当依据所要处理事项的具体细节来判定，可能会产生影响的细节有：事情的重要程度、事情的紧急程度、里程碑时间安排、对关联事件的影响程度等。

这里大致可以分为两种类型的沟通，一种是有规划有目的的沟通，比如例行的需求评审、立项评审等在里程碑节点上比较重要的沟通。另一种是遇到突发事件时需要组织的临时性小规模的沟通。

第一种类型往往有更强的计划性，沟通几次在什么时候沟通，往往都是在项目规划的安排下有序进行的，所要实现的沟通目标也都是比较清晰的。这部分的沟通次数和时间都应当是在公司维度或者项目组维度规定好的。一般情况下形成一定惯例就很少调整。

第二种类型的随机性就比较大了，往往发生在产品或技术其中一方发现某些可能影响结果的偏离事件时，比如产品发现某个细节的实现逻辑有错误，或者技术发现某个流程实现时存在技术障碍等，这时就要根据前面提到的一些具体影响细节来判定是否需要发起沟通，以及沟通的范围需要多大。

基本原则是重要且紧急的优先安排沟通，重要但不紧急的可以积累多个统一安排沟通，紧急不重要的可小范围沟通，不重要不紧急的有空余时间再沟通，或者可以选择性忽略。

控制好沟通频次是提高沟通效率很重要的一个部分，过多琐碎的沟通会让对方觉得你遇事抓不住重点，沟通太少又会留下隐藏的风险。所以在合适的时间通过沟通解决重要的问题才是这个事情中应该重点关注的部分。

二、前期准备

工欲善其事必先利其器，想要达成良好的沟通效果就必须要做好充分的前期准备。前期准备是在沟通开始之前所需要提前完成的一些工作，主要目的是梳理沟通思路，确保沟通过程中可以言之有物，有明确可依靠的内容或材料作为共同讨论的主线。

1. 达成目标共识

有一个共同的工作目标是良好沟通的大前提，可以根据沟通事项大小来确定共识内容。目标共识一般情况下要比所要沟通的内容有更高的高度，这个共同目标不是用来限制沟通的，而是用来指导沟通工作的。

一个明确的目标共识可以让沟通双方在遇到困难时更快找到核心主线，而不是一直在无关紧要的细致末节上耗费时间和精力。

这个目标可以是项目成立之初确定的项目目标，后续一切工作以完成项目目标为宗旨。也可以是当前阶段需要解决的一个小目标，在不影响大目标的前提下，重点关注小目标的完成情况。

必要情况下可以要求团队先完成目标，再考虑完成的质量怎么样。确定目标后需要谨记目标是必达项，如果影响到目标达成那其他内容均可稍作让步。

2. 完善产品规划框架

产品规划框架就像是一个攻城拔寨的战略地图，是产品设计开发工作中非常重要又容易被忽略的环节，重要性自不必说，而被忽略则是因为产品规划框架并不影响产品开发工程实施，即便没有这个框架，只要有具体的产品设计文档，开发工作也是可以正常推进实施的。

这是一个在产品设计初期经常被讨论的内容，但是后面一旦确定了这个产品要做，开始落实到具体实施阶段的时候它出现的频率就逐渐减少了。

作为一个产品经理，需要时刻记着产品规划框架对产品发展演变是一个十分重要的东西。产品需要熟知产品未来规划，这样才好去判断哪些功能是当前必须要做的，哪些功能是暂时不做长远规划要有的。

一个好的规划框架应当是在稳定基本内容的前提下不断变化的，要随着项目推进和行业发展时刻去反思原有的框架是否还是最合适的，并且适时作出调整变更。

就像战略地图，不仅要知道我们要攻下哪些城池，也要随时关注战局变化往战事吃紧的地方加派兵力，以确保能够全面地完成战略目标。而今天这里之所以把规划框作为沟通的一个重要前提，是因为它可以起到一个战略指导的作用。

哪些事要做哪些事不要做，不能空口无凭拍脑袋乱说，根据这份战略规划来，可以让团队更好地完成当前的工作。

3. 确保产品逻辑清晰

在进行具体内容沟通之前，一定要确保所要沟通的部分逻辑是清晰的。不论沟通事项大小，你想要对方了解的信息，你自己一定要先很熟悉。

沟通的过程中可能会遇到一些质疑和提问，一般情况下对方只是为了通过这种方式来搞清楚你的真实意图，那就需要我们自己对所阐述的内容有足够清楚的了解和认知。只有这样才能在别人提问时稳定地输出明确可参考的信息。

尤其是在跟技术人员针对一些具体的产品细节展开讨论时，明确清晰的逻辑显得尤为重要。

技术开发人员在写代码时尤其会关注产品的逻辑，逻辑的正确与否直接关系到产品最终的成败，而且他们常常会结合他们自己的经验对某些地方的具体内容提出质疑，如果产品经理对产品逻辑不够清晰的话很容易被带到技术人员的思考路径上来，进而会因此产生一些不可预见的结果偏差。

所以产品一定要提前熟悉沟通中可能涉及到的产品逻辑内容，在遇到问题时能确保在产品自己的思考路径上应对和解决问题。

三、沟通技巧

做好充分的准备，接下来就是正式的沟通环节了。这个部分我们就来拆解一些比较简单容易时间的沟通技巧。只要能恰当地加以应用就可以在短时间内提高你的沟通效率，让你的沟通更加畅通。当然，具体场景还需要具体分析，这里只是提供一个可行性方案，切忌盲目套用。

1. 罗列沟通要点

很多人在沟通过程中会遇到这样的问题，本来打算今天要跟对方沟通8个事，最后结束发现只聊了5个，剩下的3个要么就是没时间聊，要么就是在沟通的过程中遗忘了。如何有效防止这种状况发生，就是在沟通开始之前罗列沟通要点。

有一个清晰的沟通要点列表，一方面可以让对方快速了解你所要讲的大体内容，也好提前做好相关准备。

另一方面也可以根据要点沟通进度合理安排沟通时间，如果在某一项耗费太长时间还没得到结论时可以选择先跳过这一点讲其他内容，等所有事项都聊完以后再回过头来解决前面搁置的问题，不至于让某一项内容影响整体沟通效果。当然，最主要的还是可以确保关键项都能被提及，而不至于在沟通过程中遗忘。

除此之外，罗列沟通要点还可以起到提前梳理思路的作用，开始之前梳理思路可以提前发现沟通内容中是否有缺漏，或者不同要点之间是否有重复的内容。确保要聊的事情都是必须要讲的，不讲多余废话也不遗漏重点，是对自己负责也是对对方的尊重。

2. 统一沟通语境

什么是沟通语境不同呢，举个例子，产品拿着产品需求文档去找技术聊产品逻辑，技术却对着产品文档将技术实现的困难。

这就是语境不同，两个人的诉求明显是不一样的，产品需要确认的是当前产出的内容在产品层面是否存在问题，而技术反馈的却是如果要实现这样的产品构想有哪些技术困难。这个问题不是不能讲，但很明显不是在这个阶段。

在产品成型过程中，有些沟通是为了确保产品做的对不对的，有些沟通是用来确认产品具体怎么做的，还有些沟通是用来解决团队遇到的困难的，虽然相互之间有关联，但也不能完全混在一起谈，总得有个先后顺序，不然事情可能永远被卡在第一步无法往前推进。

所以，这就需要在沟通时约定好当下的沟通是在哪种语境下进行的。偏离语境的内容要及时停止，不然双方聊半天说的都不是一个事必然会浪费很多精力。

3. 抓住主线内容

众所周知，会议时间最大的杀手就会那些会议过程中的衍生话题，本来主线内容预计三十分钟就能聊完的，但是由于在沟通过程中思维发散将沟通内容带到了其他相关的非主线内容中，一旦开始发散就很容易消耗大量的沟通时间，所以在我们的沟通会议上最常听到的一句话大概就是“这个我们先不发散”。

于是，抓住沟通的主线内容就成了一次成功沟通的重点。沟通双方都应该要有这样的意识，要清楚本次沟通的核心内容是什么，然后还要在沟通过程中时刻关注沟通内容是否还在主线上，一旦发现有偏离主线的趋势，双方都有义务指出问题促使沟通重点再次回归主线。只要大家将这种意识培养成一个习惯，那对于团队整体的沟通效率就一定会有一个非常大的提升。

4. 跳出纠纷不做无谓争执

就像我们开头时候提到的，只要有沟通，就总是难免会有双方观点僵持不下的情况。如果这个时候双方各执一词坚持要让对方认同自己的观点，结果往往会陷入一个大家都不愿意看到的局面。

其实当双方观点僵持不下的时候，就该停一下了，停止向对方输出观点，给大家一个思考缓冲地带，去想想对方观点的是不是真的跟自己的内容完全不能融合，去考虑一下有没有可以兼容双方意见的折中做法，要知道观点不同时不是谁的嗓门大谁就能占上风的，我们沟通的目的是结局问题，是要达成那个大家一致认可的目标，各执一词很明显是不能达成这样的结果的。

如果真的没有折中的办法也不需要一直纠结在一个问题上，把无法达成一致意见的部分先放一放，先去完成其他沟通要点。等把能解决的问题都解决了，再回过头来看当时遗留的这个问题能不能解决。

5. 扩大沟通范围让更多人参与决策

上面一条的问题，如果回头看还是不能有一个双方都认同的解决方案，那就可以使用这一条技巧了，扩大沟通范围让更多人参与决策。

一个项目的推进往往不会只有产品和技术两个角色，还会涉及到项目经理或者测试人员，所以当产品和技术讨论不出来确定观点的时候不妨也听取一下他们的意见。

一般情况下，当出现双方谁也无法说服对方的时候，应该是两种方案都可行，就看哪种更合适。所以对于这种没有绝对标准的问题，可以采取更加民主的方式，让参与项目的各方共同决定最终的选择。

正常到这一步就肯定会有一个确定的结论了，实在不行就只能再把范围扩大一下了。

把最终的决策权给到项目总负责人或者双方共同的领导，由更高一级的人来最终拍板该怎么做。只要最终能达成结果，中间选择什么路径其实不是最重要的，不要让这个不重要的东西阻塞的项目目标的达成。

6. 公示明确的沟通结论

判断沟通是否完成的标准，就是关于一个沟通要点是否已经有了一个明确的沟通结论。产品经理可以有意识地记录每个沟通要点对应的结论，这个结论一定要是明确清晰的，要有明确可量化的目标，有具体的事项负责人，有计划的达成时间等等。

而且不管小范围临时性的沟通，还是专门组织会议的正式沟通，达成共识的沟通结论最好都专门公示一下。小范围的可以在大家共同的群里公示，有组织会议的最好发个会议纪要的邮件抄送相关人员。

结果公示一方面是对沟通成果的梳理，可以确保我们想要解决的问题都已经通过沟通得到了可以进一步执行的明确结论。另一方面也可以通过文字记录的形式为大家留下一个可查询的依据，后面执行过程中有不清楚的地方时还可以翻看记录找到对应的内容，减少重复沟通同一个问题的可能性。

四、相关原则

1. 哪些部分要听技术的

由于产品和技术本身的知识体系基础不同，双方都会有一些认知盲区存在。当遇到技术的认知盲区是产品有义务将相关的内容尽可能阐述清楚，一些逻辑性的或者涉及用户使用场景的东西都可以大致归为此类。

同时，产品也应当能够判断，哪些东西是技术占主导的内容，算是在自己的认知盲区内的东西。比如技术实现方式、不同技术实现方案的选择、技术实现的成本等。

在遇到这些技术更了解的内容时，产品是应该多去听技术同事的观点。千万不要不懂装懂在自己不擅长的领域过多地增加自己的干预意见，可能会影响技术同事的工作节奏。

而且属于外行指导内行，本来也是不合理的事情，我们的日常工作中应当尽可能避免这种情况出现。大家各自做好自己擅长的工作，整体的工作效率才会提高。

2. 没有明确结论的内容宁可不做

在项目推进过程中，会出现一些暂时没有达成统一意见的内容。如果是涉及到功能开发的话，这种不明确的内容是不可以贸然进入开发阶段的，不明确的部分宁可暂时不做，等后面事情讨论清楚了，结论明确了以后再做开发工作。这种情况即便提前做了也可能会在后期出现返工重做的可能，影响可能会更大。

五、其他约定

1. 建立常规细节共识

在长期合作的产品和技术之间，会有很多常见的重复内容。比如页面打开时默认的用户识别规则，登录后持续在线时长，页面跳转时是覆盖原页面还是打开新的标签页，或者一些页面上常用的细节内容。这些都可以汇总成一套标准化的细节共识文档，所有在文档中约定好的细节都直接按照文档中的标准来执行。

这样做一方面可以减少在细节上的反复沟通，减少沟通成本；另一方面也可以促进产品在细节上的标准化程度；除此之外有这样的共识文档也会方便相同体系下的不同产品统一产品风格，有助于形成比较整齐的对外展示风格。

作者：多云转晴，公众号：互联网从业笔记

本文由 @多云转晴 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。