产品和程序员沟通的难点

㈠ 产品经理和程序员,如何避免矛盾

产品实现是你的目的，为了这个目的不必太讲究。

做了一阵子之后我有了自己对于与程序员相处的方法论，对这句话并不苟同，我还是倾向于把事做好的同时也能把话说好，虽然我现在也能深刻的领会到当时leader的核心意思是产品本身是第一位的。

接下来我就阐述下自己的一些心得：

• 产品经理与程序员最大的矛盾在于——改需求。这牵涉两个问题，一个是如何尽量地做足前期工作，尽量把需求细化，需求做的足够扎实就会大大减少改需求的次数，这是产品本职工作，不属于沟通问题；另一个问题就涉及如何沟通了，就是需求无论如何确实要改。这个时候有一点很重要就是努力与程序员（或者开发经理）达成共识，比如“我们的目的是要做最好的xxAPP”、“这个功能对于我们的目的来说是必不可少的”等，然后再来谈详细的需求点，程序员也就会逐步认可改需求这件事情。（还有一点很重要的就是，如果无论如何也达不成一致，也有必要反思这个需求是否真的有改的必要？）

• 用数据和客户来帮你增加底气。在谈论某项功能实现的时候，产品经理经常会碰见程序员消极被动不愿意做，或者质疑这么做有没有道理的时候，采取需求依据的数据和真实的客户需求是能有效推进的好办法。比如“80%的同类产品都有这个功能”、“每周都能收到几个客户对某某问题的反馈”，一般来说程序员是能够接受这种说服的。

• 试着多用询问的语气。让程序员感到他是专业的，他是能够解决这个问题的，要依仗他才能做的更好。这会无形中赋予他一种责任感（因为你把问题抛给了他，他就隐形中负有解决这个问题的责任），在传达出意愿的同时也避免了话语的生硬，让程序员感受到对其职业技能的尊重。

• 注重日常交往。日常生活中交个朋友，比如一起打球、打游戏，聊聊电影和漫画，实在是没有共同语言就经常冲他卖个萌、搅个基、撒个娇、讲个笑话。这样，大家都是朋友了，不看工作职责的那一半看交情的那一半，沟通起来也会顺畅很多。

总结：有很多时候产品的产生不完全是靠严格的流程和规章制度诞生的，也需要很多沟通的润滑。能够开开心心地把产品做出来最好，但是最终我们还是不能离开产品实现这个 标的物。

㈡ 为什么程序员普遍都比较难沟通

他们太古板了，天天就一套逻辑思维，无法沟通。

㈢ 程序员工作中的沟通小技巧

程序员，是互联网公司的一笔资产，也是产品经理等冲突的主要对象，如何提高与程序员之间的有效沟通，请看下文：

心态平和——程序员的内心世界是很丰富，在经历了各种需求修改、bug修复后，相对而言与人交流的能力要明显弱于与计算机的交流能力。因此一定要心态平和的与程序员进行沟通。

希望以上几点建议，能够帮助提升你与程序员之间的沟通效率。

㈣ 程序员做沟通协调的工作很困难吗

沟通能力欠佳，是程序员群体普遍存在的一个问题。只作为合格的程序员，在编码岗位，较差的沟通能力影响有限。那么，怎么提高自己解决问题的能力？沟通能力、对工作负责任的态度、对代码的追求，很大程度上由性格决定，除去性格因素，程序员沟通能力不好与工作性质有关系，编码工作要求程序员必须集中精力，且讨厌被打扰；在安静的环境下精力能高度集中，工作效率也会很高，这就是很多程序员喜欢晚上熬夜写代码的原因。久而久之，长期技术性思考和工作习惯导致程序员不太喜欢沟通，或者不太喜欢与非技术人员沟通，会给人留下木讷和沉默的印象

首先作为程序员要足够的重视沟通的作用，在日常工作中，经常会看到这样的情况项目由于各种原因需要一起讨论或开项目会议，程序员参加讨论的积极性不高或心不在焉，且心里想着 “扯那么多干嘛，这么长时间，我代码都写完了....”这种心态下急切的希望会议快快结束，也就没有沟通的欲望了。虽然说，讨论和会议多多少少会有低效率的问题，但沉默和拒绝沟通不是解决办法，而应该畅所欲言，尽快拿出解决问题的方案才是正道！所以，程序员必须要重视沟通！

最常见的就是在沟通需求时，虽然说所有的需求最终都要落实到技术实现，但在需求讨论和沟通阶段，则不需要考虑太细节的技术实现。比如就需求的合理性和必要性与程序员讨论时，程序员第一时间在脑子里考虑的是如何设计数据库，如何通过代码实现等等，而不是这个需求是否合理，是否有多余，或是否可以再细化再拆分等，而这一些都与习惯有关。

需要代码实现的是必要的需求，而不是所有的需求，所以在非技术性沟通时，可以暂时跳出技术思维。扩展到其他问题的沟通都是一样的，不能技术优先。

㈤ 为什么程序员都不喜欢和程序员沟通工作

第一，兴趣，兴趣是最好的老师，不感兴趣自然没有心思去理会，更别提实践了；
第二，部分程序员的工作内容相对枯燥，一些人经过尝试之后不愿意接受这种枯燥的生活；
第三，思维，做程序开发是需要有极强的逻辑思维能力的，很多人面对代码一团糟，觉得困难学不会，做不了程序员。

㈥ 产品经理如何有效沟通

一、凡事有回响

在职场沟通中，同事艾特你必须要回，哪怕忘了,也要事后回，并且给出解决方案，如果不是自己负责的事情，也要告诉对方谁负责。

如果答应对方的事情，就一定要做到，否则不轻易答应，最坏的情况下答应的事情解决不了，也要提前和对方沟通一起想解决办法，而不是等对方问的时候，才说出实情，这样印象分会大打折扣。

注意，这里要做到100%的回应。因为哪怕对方 问了10件事情，有一件事情没有回应，那么在对方心理你做事都不是很靠谱。

二、沟通技巧

在日常工作中，用star法则，能最准确最快的把问题说清楚，这招同时也适合面试的时候陈述自己的项目背景。

大家一定要重视沟通技巧，如何深入浅出把自己的想法传达给协作者，直接决定了自己方案的落地性。

三、精确输出

在工作中我们有输出的文档，比如日报、周报、月报、各个时间段的计划以及prd等。

要写的东西是如此之多，以至于很多人在输出时忽视了相应的标准。

比如日报和周报中，计划没有写，连下周做什么都不知道;

比如prd 中界面是过来的，还存在其它历史界面，存在误导开发的后果;

比如在做产品规划时候，措辞不准确，甚至用几个字就代替负责的方案，也不做具体的解释，让别人看不懂;

比如画流程图，线条过于复杂，没有做拆分，给相关人演示时把自己都绕晕了……

以上都是精确输出的反面案例，产品经理如果输出要么不做，要么就有一些标准，一定要做好。

㈦ 程序员如何解决沟通冲突，避免互撕大战

在一般情况下，程序猿可以和产品维护好日常关系，一起吃午饭，一起参加团建之类的，日常沟通顺畅了，沟通产品的时候相对也好沟通一些，和不懂技术的产品讲技术，对方可能也能听的进去一二，也就能避免互撕大战，大家捞的清闲了。
像那场惊天动地的程序猿暴打产品经理那场战事中，据说就是产品经理提出了要求，去实现客户端颜色适配用户手机壳，面对这样的需求，应下来就是给自己挖坑，因为这样的功能肯定没办法实现的呀。如果这位程序猿和产品经理平时关系相处的好一些，大家能坐下来好好沟通
“兄弟，你这个功能不好搞啊”
“咋不好搞？”
“我跟你讲啊，技术上，这样那样这样那样”
“噢，原来是这样，还是你专业，听你的，那就这个功能不要了”
沟通能解决的事情，这样的结果，皆大欢喜。

㈧ 好累，程序员听不懂产品经理提的需求，问多了，产品经理嫌烦。该怎么办

这个东西应该有一定经验积累会理解比较快，也是一个过程。只有多沟通，在沟通前想想沟通的目的，这次沟通要解决什么问题。用笔记下来。然后在实操，在实操过程中如果遇到问题先想一想，试着自己去解决一下。再去询问，至少让别人感受你是在用心做这件事。而且也是想做好这件事。其实你们的目的都是一致的。注意方式方法，不要让别人觉得你一个问题重复的问还没什么结果。大家都有自己的事情都会比较烦。

㈨ 产品经理怎样更好的和开发人员沟通

诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论，可能会对各不同角色的人之间进行换位起到一定的帮助作用，无疑，这是一件对各方都有积极意义的事情。 产品经理作为贯通各环节的中心节点，避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中，我将这些可能成为臭毛病的行为归纳为以下几种情况： 短时间内可以完全避免的：需求不清晰 ，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。 干预纯技术问题 ，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。 交付的方案不确定 ，开发人员讨厌其实这样也可以，要不就这样吧的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。 没有必要的预留时间 ,这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。 不能完全避免但短期内可以改善的：需求变更 ，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少；另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案B。 口交次数太多 ：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口（头）交（流）可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。 需要长期积累或锻炼才能改善的： 缺乏个人魅力 ：是的，缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西，确实很难在短期内得到改善。甚至，对于个人魅力的判断，不同的工程师会有不同的标准。 经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。 以上 ，以自勉。

㈩ 产品经理如何与RD（研发）沟通

导读 

上节课，我们提到，作为团队枢纽的产品经理，优秀的沟通能力，是必要的能力与品质。

之所以用“必要的能力与品质”的定义，是因为产品经理只要稍不留心（特别是产品新人），就容易与其它同事产生沟通障碍，发生沟通矛盾；特别是与RD（研发/工程师）之间的沟通，“沟”了没“通”几乎会成为常态。而因此引发的一切严重后果，都将由团队陪同产品经理一起买单。

1、产品经理和工程师有哪些沟通问题？

2、产品经理为什么会被工程师嫌弃？

3、产品经理应该如何与工程师沟通？

正文

作为产品经理，特别是产品新人，肯定/绝对/100%会遇到各种各样的沟通问题；与此同时，我们也更加需要学会找到导致问题的本质原因，根本解决问题并更好推动产品工作。

接下来，我们会对X小姐文章里7处具有典型代表的内容，进行解读，方便大家更好的理解。

一、产品经理和工程师有哪些沟通问题？

原文引用1：

最近有位刚做PM（产品经理）的小伙跑来跟我控诉，说公司技术部的RD们（工程师）个个不给力。需求过了千百遍还是理解错，或者就是简单回一句“做不了”，表情如死灰。

解读思考：

这是所有产品新人都会遇到的问题（我过去做产品，有时候也恨不得把工程师们给**），但本质原因不外乎有两个：

1、需求并没有按照工程师们的思维模式来表达，他们理解不了自然也就回复做不了（所以大部分时候他们说做不了真的不是在推诿骗你，而是他们真的没有理解清楚你在说什么）；

2、需求没有优先级，工程师们无法明确研发节奏；大部分时候一股脑无定级的瀑布式需求，自然会遭遇一股脑的无视（就像有时候同事找你做事，一股脑的给你提了很多需求，也不说轻重缓紧，你也会瞬间懵圈）。

原文引用2：

这位PM血气方刚，张牙舞爪，脑子里总有一千万个新产品需求的想法扑腾着。

解读思考：

这里需要打击一下，“脑子里想法创意万马奔腾，实际中能落地的几乎为零”，这是几乎是所有产品新人的通病。

产品新人在自身的能力还没有系统丰富的时候，对于需求的理解和认知，大部分时间都局限在一个点上，很难以点思面的思考问题（这并不是产品新人的错，事实上每一位优秀的产品经理，都需要这个成长的过程；要解决这个问题需要一定时间的业务经验与思维拓展历练，稳定心态很重要）；所以，在产品新人的大多数时期，不提需求比提需求更重要，执行好任务比天马行空更务实。

同时，发生这种情况的还有一个重要原因就是：被碎片化的文章或言论误导了，对产品经理没有系统客观的认识和理解。

过于理想化和抱怨，真心是产品经理沟通中的硬伤。

原文引用3：

面对他，我的心突然惆怅起来。几年前的自己也差不多是这个模样，懵懂如白纸……

身为一位女性PM，我至今为止并肩合作过的RD团队超过8组共200多人（动荡曲折的职业生涯啊）……

所谓人艰不拆，希望大家看完后能更理解彼此“都不容易”的立场。

解读思考：

产品经理是应该有个性的，但类似：自以为是、以自我为中心、随意放大自我感受……的“个性”，一定要尽早去掉，除非你不想做一个优秀的产品经理。

作为产品经理，一定要避免将自己陷入认识与情绪的局限里；包容与理解，会让你“产品经理“人设的人格魅力MAX！

毕竟不是人人都可以是乔布斯、张小龙……在生命的很长一段时间，我们与并肩奋斗的工程师、运营、设计等小伙伴们都一样是平凡人，我们都要一起面对生活与工作的不易；彼此真的“都不容易”，所以，理解万岁：）

原文引用4：

PM眼里的RD分成两种：能沟通的，和不能沟通的。后者占90％。

解读思考：

我也遇到过这种情况，当我踌躇满志，把一个产品勾勒得很美好的时候，突然发觉，为什么工程师们在用那种木讷的、毫无光亮的眼睛（眼神）看着我？他们不仅一点都不兴奋，还会问我：

1、这个功能为什么这么做？

2、你确定这样做没问题吗？

3、这个东西不是刚改过吗？

所以最开始，我也认为工程师是没法做朋友的（大致原因参考引用2的解读思考）。

原文引用5：

曾经有一个RD总监，在Kickoff会议上把我所有的需求都推翻了，让我差点在十几个老男人面前哭鼻子。

话说人在经历苦难后，要么变乖，要么变坏……于是我学会了通过非正规途径收买RD的心－－

比如请他们吃KFC啦，陪他们聊黄色笑话啦，穿低胸装秀黑丝大腿啦。

解读思考：

Kickoff（启动会议），基本可以理解成打仗前的誓师大会。已经要出征了，RD总监直接把X小姐的产品掰翻。

遭到打击后，X小姐的态度也很鲜明，强烈且迫切的心情想要让RD听命与她，于是决定通过非正规途径来搞定RD。

我觉得女生做产品经理一定要有掌控的欲望，要有一颗当女王的心；男生就更不用说了。

我最开始为了和工程师打成一片，也是什么事干：请人吃饭、帮人泡面、陪人加班、接人上下班（这个不要轻易效仿，毕竟一个成年男人每天刻意的去接另外一个成年男人上下班，而且时不时还要换不同的人，画面的确有些尴尬，也比较容易引起敏感话题 - -！）……通过不懈努力，我和工程师们的关系终于也改善了许多。

原文引用6：

正当我沾沾自喜，认为自己靠美胸美腿赢得了这场战役时，一个Ruby工程师幽幽的跟我说 “我好喜欢你的门牙” 。（鸦。。。你们果然是无法沟通的生物。。。）

解读思考：

真的是这样，我们可能永远也不了解工程师们的心，即使彼此的关系得以改善之后。

大多是时候，特别是产品新人们看工程师，总觉得别人傻傻的；与此同时，在工程师的眼里，我们可能更傻。

在我看来，发生这样的情况，大多数时候的本质原因，仅仅只是工程师们表达情感的方式质朴直白的表现；不能因为工程师们不会说话、不尽表达、不够“情商”就忽视了，大多数工程师的脑袋里，都有一个神奇美妙的世界，只是我们不懂的探索而已。

所以，有时候放下所谓的“说话艺术”、“情商”、“温柔”等定标性偏见，用最质朴直白的方式去理解工程师的表达，彼此都会轻松高效很多。

原文引用7：

RD眼里的PM也分成两种：有脑子的，和没脑子的；后者占90％。

没脑子的PM，RD们是打心底森森嫌弃你的。

解读思考：

其实，沟通更深层次的条件是相互的信任。

产品经理和工程师之间，如果没有建立好一种信任的关系，那彼此之间的合作就会不协调，也就会经常出问题。

但在大多数情况下，产品经理是很难获得工程师信任的，甚至被嫌弃。

为什么？

二、产品经理被工程师嫌弃的3个原因

现在我们来解读，X小姐从她的血泪史中总结的，产品经理被工程师嫌弃的3个原因。

1、没有自己的想法

解读思考：

如果我们经常说，“这个东西是老板说的”、“老板要这么做”，好像这个事情和你没关系，那工程师们在心里是不服你的。所以产品经理一定要有自己的主张，你可以这么说：“老板要求这么做，我觉得还是有一定道理，不如咱们试试吧。”

或者：“这个确实是老板要求做的，我感觉还是有点问题，怎么办？我们再沟通沟通，还是怎么着？”

我们要有自己的主张和独立的思考。这样，工程师们才会相信，你犯错的几率更少，把事情做成的几率更大。他们也才愿意协助你，助你更好地推动产品，对吧？

2、风花雪月没有逻辑

产品经理很讲究“感受度”；这也是我一直强调的，优秀的产品经理一定要通人性，感情丰富。

我们也说，产品经理要有理性的思考和感性的表达；理性的思考在背后，感性的表达在前面。

感性的表达简单理解就是：尽可能的用对方更容易接受和舒服的方式去传达自己的意思。

工程师们大多是逻辑思考能力很强的理科人才，在与他们的沟通协同时，如果思维不缜密严谨，或是呈现的事物缺乏逻辑经不起推敲，就可能被嫌弃。

3、不信任工程师的能力

如果我们不信任工程师，他们是能感觉到的；或者有时候我们问工程师研发一个功能大概需要多少时间，他们回复可能三五天；但最后你发现，其实只要半天或者两个小时。

这些问题，也会使大家平时的沟通产生障碍。所以X小姐提到：要让工程师觉得你很优秀（一定要让工程师觉得你很优秀）。而实现这种状态的前提是，我们先要学会去信任和肯定工程师们的能力。

所以，要做到良好的沟通，背后有很多需要我们去推进的事情，而不仅仅是所谓的沟通技巧和表达能力。

三、产品经理如何与工程师良性沟通？

文章最后，X小姐给出了7个建议，很有启发价值。

1、眼观四路，耳听八方。

“知识渊博，掌握行业内的各种动态，分析市场趋势……”要让工程师们觉得你是一个靠谱的人，什么都知道。

2、混对圈子，积攒几个牛逼人脉。

关于这点，我在后面的课程里会与大家讲到的：产品新人们一定要去混圈子。

拥有更多牛逼的人脉，既可以帮助产品有获得更多露脸的机会，也可以帮助招聘到更多优秀的工程师，也就能更好推动产品工作。

3、无论是口述的需求还是撰写的文档，文字和原型图的呈现都要有逻辑。

这是最重要的。

很多产品新人找到我说：“刘老师我觉得写文档很痛苦，我可以口述么？”。其实我接触的很多的产品团队，有很多也是不写文档直接口述的，但同时这对语言表达能力也有更好的要求。

其实无论是着重于文档的文字表达，还是着重口述的语言表达，本质上最重要的还是表达核心思想的逻辑。

就像X小姐说的，无论是口述，还是写文档，一定要有逻辑。“功能细节上的逻辑处理得无一遗漏，实乃RD们的心头好。”

4、在老板责问为什么还没上线的时候，冲上前去说，“都是我的错，前几天又改了个需求”。

当工程师们真的很努力去做了，却被老板指责的时候，如果你能主动帮他们挡刀，他们会觉得你是一个有担当的产品经理。

5、在RD们被各种部门的需求同时袭击的时候，为他们安排最合理的优先级，并承诺担起一切后果（包括被某部门主管批斗责骂等）。

6、招到漂亮的实习生妹子给RD们养眼（请一定投其所好）。

7、给他们加薪，给他们加薪，给他们加薪。

本课小结：

产品经理在推进日常工作时，经常会和工程师发生沟通问题，着其实是普遍存在想象。

遇到问题，我们不要一来就想改变工程师，而是要学会先分析和总结自己的问题。

除了学习沟通技巧和表达能力，更重要的是要深刻理解并协助团队小伙伴。产品经理要有自己的主张，有同理心，有理性的思考和感性的表达；这样，才能获得工程师的信任，更好推动产品工作。

当然，沟通问题只是抛砖引玉，沟通只是产品经理工作中常遇见的问题之一，产品经理在工作中还会遇到各种问题，譬如：长期被加班、顶雷专业户等。

所以，下一节课，我们就来全面解读一下作为一名产品经理，我们将会遇见怎样苦逼又有趣的工作与生活状态。 

备注鸣谢：

推荐文章：《如何与RD沟通，写给那些血气方刚的产品经理》

链接地址：http://36kr.com/p/212020.html

特别说明：

因为我与团队在日常工作中，更习惯喜欢称呼RD为工程师，所以为保障阅读体验，引用X小姐《如何与RD沟通，写给那些血气方刚的产品经理》原文内容中出现的“程序员”均替换为“工程师”。

 

关于《产品经理入门指南》精译版

《产品经理入门指南》原本是刘文智老师于2014年发布的，国内第一套系统的互联网产品经理入门方法论视频课程。课程历时9个月精心准备，收集了上千名产品新人的真实需求，参考了近百家产品团队的用人标准，汇聚了数十位产品大咖的专业意见。旨在：

1、教会：产品新人评估自己是否适合做产品；

2、帮助：产品新人找到契合的入门学习方法；

3、引导：产品新人走出入门困境和学习误区；

4、启发：产品新人化解学习难题与高效成长。

应众多同学的需求，现由刘文智老师携课司机团队，重新编译为图文版，限免发布。

关于作者刘文智老师

刘文智 Jason

连续成功创业者，天使投资人，创业投资顾问

80后，爱足球、爱电影、爱较真。

知名产品经理社群“产品壹佰”、IT在线职业教育品牌“美好学院”创始人兼CEO

互联网社群+IT职业教育成功商业模式的创新开拓者；

于2016年接受慧科教育科技集团全资并购邀约出任集团合伙人、开课吧CEO；

2017年末转做天使投资人，创业投资顾问。

中国首位发布系统互联网产品经理职业教育体系的老师

2012年起先后着有《产品经理入门指南》、《产品经理深入浅出》、《手把手教你做产品》等互联网产品经理线上、线下实战教学体系；课程全网学习频次超千万次，影响了包括美国、加拿大、澳大利亚、丹麦、新加坡等超过38个国家和地区，帮助13万互联网人获益；

中国最早推出以就业为导向的产品经理职业教育服务的老师，数万名学员广泛入职中国各大互联网企业以及知名互联网企业核心产品团队。

15年互联网、10年教育一线坚守与沉淀

曾任搜房、新浪两家上市企业产品与营销策划相关工作；

曾任电子科技大学千星计划互联网应用专业负责人。

温馨提示：

若需获得更多产品经理学习帮助，推荐关注刘文智老师的微信公众号（微信号：iamliuwen）。