03丨沟通：程序员为什么应该爱上交流？
2020-05-22 臧萌
职场求生攻略
进入课程
讲述：臧萌
时长12:41大小11.62M
程序员这个群体最开始被社会认知的时候，标签之一就是不善交流。慢慢地，“喜欢玩电脑，不喜欢和人交流”成了大家对程序员的一个刻板印象。作为程序员，我发现工作的时间越久，承担的责任越大，那么交流是一个越来越重要的能力。
在这一讲里，我们就来聊聊程序员如何进行高质量的交流。当然了，你可能会想，我不喜欢交流照样工作得很顺利，可是，交流带来的好处也就体会不到了。
当然了，在开始前，让我们先想想，为什么我们会不爱交流呢？
为什么程序员普遍不喜欢交流？
其实，是不是喜欢和人交流绝大部分是由性格决定的，和职业无关。可能程序员这个行业，相比其他行业，吸引了更多的不喜欢交流的人吧。但是除了性格之外，确实有些客观因素影响了交流的积极性。
工作被打断严重影响效率
我觉得这个绝对应该是排在第一条的。和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
而所有的程序员，都非常讨厌自己的工作被打断。
交流不能直接帮程序员完成工作
网上有个段子，说程序员和产品经理在开会，讨论到下班才结束。产品经理一看正好到点了，就欢欢喜喜地闪了，留下程序员拿着需求挑灯加班。
会议结束之后，程序员的工作才算真正开始，从利益的角度来说，也难免我们会抵触这种不能帮自己直接完成工作的交流了。
程序员其实只是交流中的“利益受损者”，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费”。
当然，面对面的交流只是一个例子，其实写文档、回邮件、做演示等等都一样，都让程序员感觉是“浪费时间”。
简单来说，没有无缘无故的讨厌。别管程序员嘴里怎么说，心里其实明白，归根结底，还是因为我们觉得这些事情影响了自己的“利益”。
爱上的第一步：正视和人的交流
如果交流有损程序员的利益，那为什么我们还要交流呢？我就写我的代码，写完下班不是挺好的吗？其实这就涉及到一个长期利益和短期利益的问题了。短期来看，少参加一个会，少和人聊两句业务，少被人打断几次，从一个星期的维度看，可能工作确实完成得更快了，加班更少了。
但是从长期发展来看，缺少交流的程序员，很难发展为公司的骨干，升职加薪可能都会被排在后面。我们的工作，真的不止眼前的程序。
在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
我认为，交流的好处可以从两个方面来说，一个是输入，一个是输出。
输入
我们都说要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
机会都是自己争取的，这句话看似鸡汤，但是背后的道理一定要明白。没有哪个创新是空中楼阁，在现代社会闭门造车也很难成功。只有足够的信息可以在脑子里碰撞，创新的火花才更有可能出现。在外人看来的灵光一闪，背后可能有很深的积累。
输出
现在已经不是一个酒香不怕巷子深的时代了。自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
养成主动交流的好习惯
当我们意识到交流的重要性之后，就应该慢慢养成主动交流的好习惯。
交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
当然了，我们也可以通过分享会的形式，进行正式演示。这种演示一方面可以展示自己的工作成果，另一方面也可以听取别人的意见，看看自己的工作如何能给更多的人带来价值。
前面说到的交流多偏向于信息交换。其实日常工作中还有很多交流都是为了解决具体的问题。从技巧上而言，这两种类型的交流并没有什么区别。
程序员交流的技巧
换位思考，注意受众
其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
所以我们在交流的时候，首先要进行快速的角色转换，找到对方和自己认知的“最大公约数”，英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍，比如系统特点，专有名词的介绍等等，避免受众一路带着问号听你说，最后对话变成了“鸡同鸭讲”。
举个例子。如果我们发现上游的订单数据有问题，那么我们可能需要找同组的人帮忙看。这时候，我们可以找组内相关的同事说，帮忙看看订单的数据是不是有问题。组内的同事对系统都是很熟悉的，不需要交代太多上下文。
如果我们发现确实是上游的数据有问题，有些字段缺失了，需要上游系统配合帮忙查找问题。这时候可以发邮件给上游系统。我给出两个邮件标题，你觉得哪个更好呢？
订单数据在 OrderProcessor 引起异常
从 3 月 15 日起，来自 Kafka 的订单数据，缺失了 OrderingTime，OrderName 字段
第一个标题，明显没有分清交流对象。OrderProcessor 是自己组内项目的代码，这明显不是两个组的责任交界。数据在进入 OrderProcessor 之前，还有很多步骤，不能确定是上游发的数据的问题。难道你想让上游的组去看你的代码，帮你找自己代码的问题吗？
第二个标题，很清晰明确。上游数据发到 Kafka，这是大家责任的交界处。时间，问题也都交代得很清楚。上游的组完全可以以此为起点，向后查找自己的问题。
简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。
交流要带有足够的信息
我们来看一个教科书般的交流失败的例子：
A 问：“订单信息数据在 HDFS 上有吗？”
B 说：“有。”
B 的回答没错，但是也没啥用。A 的问题明显是想知道订单信息在 HDFS 的具体位置，而非只是有或者没有。B 如果知道具体在那里，就应该一并告诉 A；B 如果不知道，也应该回答“有，但是我不知道在那里。”如果 B 知道谁可能会知道，那么应该一并告诉 A。这样，一次交流，基本就可以结束了。
再以上面订单数据的问题举例。使用了正确的邮件标题，内容也要足够翔实。邮件内容应该包含如下信息：
证明订单信息并非一直缺失这部分数据，并拿出数据，附带数据的详细来源。
证明现在的订单数据并非所有的消息都缺失这部分数据，并找出缺失数据的消息 ID 和没有缺失数据的消息 ID、时间等追踪信息，以便对方定位问题。
用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。
先说重点和结论
这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是 PPT 类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
这样不仅可以让对方马上抓到重点，而且还可以让对方在有疑问的时候，可以带着疑问去阅读后续的细节。
总结
程序员的工作就像是产品。好的交流就像是包装，广告，公关和营销。有了好的产品，还要有好的包装，突出产品特点的广告，及时的公关和合适的的营销，才能赢得市场。没有这些，别人可能根本就不知道你有这么个产品，不知道这个产品能干什么，有什么特点等等。
这里再总结一下，从输入这个角度来说，交流的好处可以分为以下几点：
获取更多的信息；
理解公司的业务；
加深对行业的理解；
发现新的机会。
如果在交流中能够输出自己的内容，长期来看，给自己带来如下好处：
赢得自己的声誉；
树立自己的影响力；
赢得同事和经理的信任，承担更大的责任。
充分的交流，并不是“就知道动嘴”，而是一个获取信息，加工信息，给出信息的过程。只有交流了，我们才能知道对方的想法，自己认为的好，可能并不是大家认为的好，自己没有想到的好处，别人可能想到了。我们在日常工作中应该多注意自己交流技巧的培养，养成喜欢和人交流的习惯。工作越久，交流在工作中的地位也就越重要。
思考题
你是一个喜欢交流的程序员吗？你有因为擅长交流而获得什么惊喜吗？欢迎你在留言区留言，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起讨论一下吧！
© 加微信：642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。
上一篇
02丨沟通：邮件那么重要，你还在轻视邮件吗？
下一篇
04丨主观能动性：为什么程序员，需要发挥主观能动性？
写留言
1716 143665 拼课微信(16)
2020-05-22的确, 平时的工作很不喜欢被人打断, 尤其是写代码状态很好的时候, 好不容易清楚了的逻辑, 万一被打断, 思路可能就断了, 后来工作越来越多的时候, 被打断是很难免的, 我就学会了todo list, 每周末根据事情的优先级安排下周工作, 并保留1天左右的buffer(处理突发事件或者应对临时需求插入); 每天根据任务完成情况, 动态调整第二天的任务或者加加班(流泪....), 保证周任务或者项目级别的准时性; 同时也学会了拒绝, 不合理的需求尽可能的拒绝; 更重要的可能是trade off, 代码的最优不一定是项目的最优, 当下的最优不一定是全局的最优, 项目是需要先机的, 或许我们应该不止是coding, 还应该关注整个项目的计划, 可能delay的不是项目的排期, 而是项目的生命....展开作者回复: 说的太好了！
我还喜欢用即时贴，做完之后撕碎即时贴的感觉贼啦爽。比在JIRA上拖story爽多了。 3 5
2020-05-22我是一名运维…我们是轮流值班制，在我不值班的时间，总有开发喜欢过来问一句在吗，就没有下文…即使我工作签名改成我在请直接说问题，还是依然如此，我想问一下老师怎么处理这个情况作者回复: 这个确实非常烦。。。我觉得没有好办法。。。很多人就是喜欢ping以下就不说话了。。。或者给聊天软件来个自动回复？
不过我现在也看开了，既然对方不说话，也就说明事情不急，等看到消息就回一句，等他再来找呗。
你的羊竟然会眨眼睛！ 5
2020-05-23可能是自己性格内向的原因，之前不怎么爱主动与他人交流的习惯，埋头做好自己手头的事，看了老师的文章，认识到主动交流长远来看还是对自己很有帮助，针对性格内向的情况，有什么好的建议，养成主动交流的习惯呢？展开作者回复: 我觉得我们挺像的。我给出一些我自己的建议吧。
首先还是态度上的转变，把交流沟通当作做事情的第一步，而不是把做具体的事情作为做事的第一步。现在我把和人交流放在比做具体的事情更高的优先级上。也就是说，不把事情弄清楚，不开始做具体的事。这样一方面是为了把事情做对，另一方面来说，对于写了那么多年程序的人来说，在知道怎么做的前提下，做事本身没有什么挑战了。而弄清事情的前因后果，弄清要解决的核心问题，才是更有挑战的工作内容。
其次，我在直播里也提到过，对于内向的人来说，可能很难一下转变的可以跟谁都聊的很无拘无束。没关系，可以在经常合作的部门里，每个里面找一个或者两个固定的人交流，作为起点。比如自己组里，可以是经理，架构师，以及比较熟悉组里情况的同事。别的组里，也可以是一些资深的员工或者架构师等职位的人。不要觉得对方和自己交流是耽误对方的时间。我的感觉是，大部分的架构师，经理以及资深的员工，都非常愿意和人交流。当然，如果有那种不愿意和人交流的，那你下次换个人就是了。
最后，别和人张口就是工作，没事儿可以和别人打个照面，打声招呼，随便聊聊别的事情，游戏，生活，键盘，电视剧，八卦，军事，耳机，音乐，运动什么都可以，只要是双方都感兴趣的。这样非常有利于拉近彼此的距离，减少陌生感。
个人建议，仅供参考～ 2 2
2020-05-23我工作中的交流分三类：开发组内，客户，跨部门。前两个都没太大问题，能看的到好处是做之前讨论比较充分了，不至于跑偏，成果也能及时跟客户迭代。倒是跨部门（实施）交流效率不高，主要在两点：一是同样的事情反复说，微信里文字截图看了记不住，为避免零碎整理出的文档也不细看，喜欢直接来问你；二是计划经常变（理由是别的项目怎样怎样），为了推进进度我倒是帮着想主意，但是开发人员的时间又怎么经得起陷入和第三方对接打烂仗呢！老师有啥建议能启发我一下吗？展开作者回复: 对方不给力，这个确实没办法。如果是我，我会看看对方有没有给力的，尽量换个对接的人。或者说，每次把事情跟这个人交代清楚，让他作为自己在对方部门唯一的接口人。接口人来问，立刻马上放下手里的事情帮你解决，回答你问题。对方部门如果有人再问，直接让他去找这个脑子清爽的接口人。
计划变，这个只能让经理出马。大家要协调好规则。不能说变就变，没有任何代价。不打到身上不知道疼，不让他负责他可以一秒钟有一个想法。变可以，变带来的延期和工期增加的后果，对方得承担。让他们知道自己要对变负责，自然会在提需求之前想清楚，变的可能也就更小一点。 2
2020-05-22总结下~
长期发展来看，缺少交流，很难发展为公司骨干，升值加薪可能都会被排在后面，工作真的不仅仅是眼前的程序。多交流，多沟通，对自己的发展很有好处，同事，领导都更愿意和你合作，让你承担更多的责任。交流要带有足够的信息，先说重点和结论，这样可以让对方马上get到重要的point，而且你还可以顺势去帮忙解读对方的疑问甚至细节。展开作者回复: ✅，以我的经验来说，如果对事情的目标、前因后果等都了解清楚，可以得出更好的方案，作出更能适应需求变化的设计。
2
2020-05-22关于交流有一点心得:在华为工作时，通过邮件交流是非常普遍的一种形式。我曾在与人的邮件沟通中犯过如下错误:
1.逻辑不清晰，邮件中不描述背景和上下文，有被高层主管在邮件中直接怼过
2.爱加戏，分析一个攻关问题，突出的是自己定位的思路，而不是把问题的结论和下一步计划放到最突出，最容易呈现的地方。浪费了邮件相关收件人的阅读时间？
后来我的老板给我提了标准邮件的两个要求:
1.邮件发出来以后，不需要让别人再费劲的问你相关信息。这个要求我的邮件尽量的逻辑清晰和内容详实
2.邮件要尽可能的节约别人和你交流的时间。在这点上要注意那些是交流的收件人哪些是抄送；要扣邮件的细节，要注意自己交流和沟通的目的，方法；要明确自己沟通交流后想获取的结果。展开作者回复: 👍，内容要翔实，但是结论要清晰+突出。
2
2020-05-24写好邮件标题很难展开作者回复: 邮件标题就是针对收件人给出一个内容总结。有时候是挺难的
1
2020-05-23对于换位思考的那一节,比较有共鸣.
就同一个项目,app前端与服务后端交流时,也会有类似的问题.
曾经在项目中就遇到过这样的情况.
前端反馈问题就是:
"你们的api接口有问题!"
连api接口的完整url地址都不提供的.
后来反复沟通了很多次后,终于把url带过来了,一看根本就不是我们服务的域名.
"你们的数据未推送过来!"
我习惯在相当于网关的地方添加完整的日志,这相当于是我的责任边界.
我提供的相关日志表明数据已经推送过去了.
而前端坚持,他加的断点未被触发,消息肯定没收到,让我去看他们的代码.
后来,还是因为他们的逻辑问题,未触发他的那一段代码.展开作者回复:
描写太过真实😭 1
2020-05-23没错了，之前看到过一个ABCD的说法：你想的是A说出来是B，听的人听到了C他脑子里想象到的是D。交流都会有很多误解，不交流就更没办法确认目标了。展开作者回复: ✅，这也是需要多交流沟通的原因。
1
2020-05-23总计下：交流确实会导致工作被打断，影响工作效率，但是从长期发展来看，交流带来的好处更多，交流是一个输入输出的过程，让我们获取的信息更多，加深对公司业务和行业的理解并且可以从中发展机会，同时也会提高个人的团队影响力。交流的方式多种多样，闲聊时，吃饭时或者是一次简单的沟通。展开作者回复: 👍，先多听，再多说。
1
2020-05-22大家都喜欢和易于交流的同事一起工作。更多的交流可以同步信息，避免造成吭哧吭哧干半天，最后活白干，干错的结果。展开作者回复: ✅👍
1
2020-05-22我觉得“交流要带有足够的信息” 那段，是那个问问题的人的问题，而不是回答问题的人有问题，只有清晰的提出了自己想要问的问题，回答方才能准确无误的给出提问者需要的答案，若不是猜提问者他想要知道的真正东西展开作者回复: 嗯呐，你这个点也很对，从例子上讲，问问题的人也只是给出了一个模糊的问题。
站在问问题的角度，我们把自己的问题都说清楚，把自己心里最想问的问题问出来，而不是旁敲侧击，。
站在回答问题的角度，我们给出最合理的推测，把用户可能想要的信息给出来。 1
2020-05-22老师您好，“养成主动交流的好习惯“那一节中间部分的那一句“不要让自己做一个小透明”没看懂，能讲解下吗展开作者回复: 意思就是，
不要让自己做的事情别人都不知道，不要只知道做，不知道说。自己做的事情，要说出来。
不要只听别人告诉自己干嘛，自己也要做想为什么这么做，多问问别人是不是和自己想的一样。 1- 2020-05-30我是看了作者对列举了邮件在工作的几个场景后，决定买这个课程，原因是这是需要补充的部分，也契合课程的标题 职场求生攻略。
我个人不是特别爱交流的人，当然也不反感，对于有质量的交流，对于我来说还是有意义的。
我个人也是朝着增强表达能力方向努力着，这里面最主要的内在动力是 提升自己的价值，参与到更重要的事情上面，而不是重复去做边角料的琐碎事情，这些都需要很好的沟通能力。展开作者回复: 是的，只有你知道自己中的粮食是怎么一步步卖到工厂，加工成面粉，做成面包/蛋糕/小饼干的，才更能让自己做的事情更进一层。而这个过程就少不了交流。
我也是个不大爱交流的人，这么多年工作下来，说实话还是因为这个吃过亏的，希望我能把这些事情说出来，让大家能早点行动起来，停止吃亏，哈哈。
这个课程还包含很多我自己总结的职场生存法则，希望对你也有所帮助～ 
2020-05-26工作能力强的人不需要怎么交流沟通，也能做好事情，这种人如同一只老虎，但拥有良好的沟通交流能力，则是如虎添翼，如果这只老虎要觅食，安装了双翼的老虎，将能大大缩短觅食时间，提高觅食效率，程序员也是一样，能力强的程序员虽然不需要怎么沟通也能将事情办好，但要是加上良好的沟通能力，则会缩短将事情办好的时间，提高工作效率！这有点像杀鸡，同样是杀鸡，拿普通的刀跟宰牛的刀杀鸡，都是杀鸡，杀几只可能看不出来区别，但是杀成百上千只，那区别就出来了，宰牛刀凭借着其更为锋利的特性，在杀了n多只鸡后，依然锋利如初，而普通的刀在杀了n多鸡后，逐渐变钝，既然如此，为何杀鸡不用宰牛刀呢？是吧！展开作者回复: ✅，再猛的发动机，也不应该让机油拖了自己的后腿。用了好的机油更猛呢！
2020-05-26程序员沟通是个大问题，大都不善于沟通，总喜欢自己想，最后弄出来的东西跟本来设计想的差的好远。遇到问题了，也不善于沟通，总喜欢自己找解决方案，有时候可能都有解决方案了，只是自己不知道而已，折腾半天弄出来了，把问题变得超级复杂。展开作者回复: 是的，不要自己想自己做，要自己想，说给客户听，听取客户的反馈，再决定怎么做👍
