程序员工作中沟通的 必要性，有效性，技巧性

作为一个刚工作一年多的新手程序员，谈这个话题似乎有点关公门前耍大刀的嫌疑，但沟通是普遍存在于各行各业的，只要是人和人的合作，就需要有效的沟通来使各自的工作成果能有效的结合，所以基本社会中的每个人只要对自己过往的工作经历认真思考，都应该能得到关于如何与人有效沟通的经验。我在做程序员之前做过房地产公司的施工员，工作中和各种工程队的队长，技术员，民工，以及监理方，甲方人员都有广泛的沟通，内容涉及从施工规范到安全培训，从项目文件备案到各个项目承包商资源，场地，车辆机械的协调，可以说是和各色人等交流各种问题，也算积累了一些沟通经验，尤其是和非专业人员讲解专业知识的经验。

对于程序员来说，沟通的含义相对纯粹，因为我认为程序员之间的沟通不会包含一些所谓公关的技巧，我们的目的不是通过什么谈话技巧，思维引导术，委婉的，或诡辩的使别人接受自己的想法，屈服于自己的意志。我们的目标很简单，就是能清楚明白的说清楚自己的想法，自己的设计，自己的意见，自己的建议。程序员的沟通主要是清楚的表达自己的意思，因为我们工作中要解决的问题都比较复杂，而工作的过程就是大家都清楚的陈列自己的想法，相互检查，一起思考，群策群力，最终得到一个共同认可的可行方案，然后开始实施。

所以很难得但是很必要的一点要求就是：保持客观！因为通常来说，被证明自己是错误的之前，每个人都会固执的认为自己是对的。让思维不带有个人情绪或主观意见是一个很难达到的境界。 但是任何人都无权指责一个坚持己见的人，不论他的想法对于错。我对这一点也没什么好说的，但还是希望，团队中的每个人心态平和一些，如果大家共同商讨一个问题，那么就是每个人挖掘出自己能挖掘到的信息，每个人提出自己构思的方案，如果能力强的更可以提出自己翔实的解决方案。但尽量不要有唯我独尊，非我莫属的想法，
确实在软件开发中，有时候会有多个可行方案，而且哪个更好哪个更坏，业界都没有统一的标准，这是就是个人主义开始抬头的危险边缘。虽然通常一个人没有能力左右团队的决策，但是如果大家各自为政，一盘散沙，团队可能很快会陷入困境，总之一句话，坚持己见没有错误，但看问题一定要客观，自己错了要承认，别人正确了也要承认，不要因为坚持己见而变得看问题主观，偏激。

沟通的首要前提是认真的听别人的陈述，沟通是一个过程，听者 和 说者不断的互换角色，交流彼此的信息，最终实现本次沟通的具体目标，比如：请求帮助解决一个问题，请求了解一些情况，一起讨论决定一个方案，教授一些知识\技巧。在这些过程中，主要的责任都是在说者身上，听者唯一要做的就是调动自己的积极性，注意听，认真想，仔细领会说者的内容。因为沟通的对象智力，经验，专业技能，可能并不是非常优秀，所以，要想实现有效的沟通，主要的责任确实都是在说者身上，听者只要认真听就可以了。

人的理解能力，知识，经验都是有高低的，同一个问题对不同的人有不同的解释方法，优秀的演说者，会洞察这种差别并做相应的调整，如果你懂相对论，跟街道的大妈也可以讲的通，她肯定不懂什么高深理论复杂公式，但思辨的过程是共通的，你总能在他的世界观中找到类似的过程，向他陈述一个类似的比喻，让他有一个概念上的认识，从今以后，她就多了一种思考问题的方式，就像是给cpu添加了一个指令集一样，CPU不会知道你用这个指令集来干什么，但他确实多了一种算法，可以解决更多的问题，拥有更高的效率。我们沟通的是思维方式，指令集，而不是数据，数据每个人都可以自己获得，就是信息，思维方式是占用很低，但价值很高，数据通过沟通来获取是低效的，所以说沟通的核心就是告诉对方：我是怎么想
”我们正在谈论的这个问题“ 的， 你用各种比喻，描述技巧说清楚这个，对方会理解，学习，并评价你的思维方式，这就是沟通的价值，相互促进和提高。

实际上我们也要信息数据上的沟通，而且非常重要！要清楚的表达自己的想法，要有足够的上下文（问题所在的环境描述）， 这也是为何程序沟通成本较高的原因，当有一个问题自己解决不了，向别人请教时，被请教的人需要完整的理解整个上下文才能得出正确的结论，通常你遇到一个问题，或许是因为你的思维僵化，无法跳出圈子，或者就是你疏漏了某个关键条件，如果你迅速的描述了你所掌握的核心条件，那么对方可以立刻按照自己的思维方式开始分析问题，那么他可能很快的得出自己的结论或者发现你的条件中有重要的项目缺失。否则，对方需要首先花一样的精力去了解你之前获得的信息，然后才能开始思辨过程，相当于他完整的解决了这个问题，那还不如直接将工作移交给他来处理。所以说，提供足够的上下文信息，会使参与交流者尽快大发挥其思辨作用，提高沟通的效率。

沟通要突出重点，首先能简明的描述自己的核心逻辑，框架设计，问题要点，这样，在你陈述细节时，对方可以开始思考，不会被某个突然出现的细节导致思维停顿，而跟不上你的思维，如果你一开始，没有一个提纲来强调主线，而直接进入正文，并充斥大量细节内容，听者很快就会迷失，因为他不知道什么重要，什么不重要，他必须努力记住全部细节，或自己实时分析归纳，简单的问题还可以，复杂的问题，对方很快就会晕头转向，记住新细节，忘掉旧细节，无法调动自己的大脑开始思考。当然除非他非常有经验，解决过类似问题，否则，他只是被拉进细节的泥潭，不知到该听什么，记什么，完全无法思考，进入了听不懂的状态！

说话注意语气，这是一种技巧，但却有必要性，在重要的线索上加重语气，可以达到更好的效果，人毕竟是动物，有情绪反应的本能， 保持一个语调的演说通常会让人昏昏欲睡，而抑扬顿挫，有轻重缓急的语调，能暗示对方某些东西重要，某些东西次要，这种隐性的 ”注解“ 能力，对沟通有极大帮助！

无论多么有沟通经验和技巧，在软件行业，有的问题是很难用语言一次说清楚的，有的也是说不清楚的，有的即使说清了也很难听懂，我们的目标是让对方听懂，所以不管用什么方式，哪怕荒诞的方式，滑稽的方式，目标是让对方听懂，而不是只要自己讲清楚了，就推托责任，或者干脆指责对方笨，这都是极大的错误！首先要建立正确的心态，非常复杂的东西，不要指望说一遍，对方就能听懂，理解，并记住所有细节，这是不太现实的。所以反复的沟通，交流，确认，核对，最终达成共识的沟通过程在程序开发过程中是会经常出现的，心平气和的完成这个过程才是成熟理性的表现。

如何检查沟通的效果， 最简单的办法就是让听者复述说者的内容，复述核心概念、核心逻辑、核心思路，让说者听对不对，先确保对方清楚自己的意思，这就是基本的成功，然后两个人开始就这个话题展开讨论，其中的任何碰撞，火花，都是这次沟通的收获。

最后，沟通要主动，发现问题要及时沟通，不要懒惰