1 前情提要
2 前言
让我静静，我只想写代码
化用《我的团长我的团》里面，孟烦了父亲的一句话：
为何诺大的公司，放不下一张能安静写代码的书桌？
在我此前的固有认知里，所谓的软件工程师就应该安安静静地写代码，但为何我总是求而不得呢？
但事实是，在软件开发的大部分时间里，我们都是在与「人」交流，而非与「计算机」交流。
即使我们编写代码，首先也是让「人」去理解，其次才是让机器来执行，否则直接写二进制代码即可。
而在程序优化中，有一条金科玉律：「针对热点代码进行优化」，因为那是性价比最高的优化策略。
既然软件开发中，大部分时间都是与人交流，那么如果能提高与人交流的效率，那么我们的开发效率也会相应地大幅提高。
3 原则
3.1 尊重
与人相处时，最重要的概念之一（可能没有之一），就是尊重他人，每个人心底都是渴望被尊重的。
所谓的尊重体现在各种的细节里面，例如：
尊重他人的观点和言论，留意倾听，眼神放在对方身上，不随意打断别人。
尊重他人的时间，不迟到。
尊重他人的成果和工作，引用时注意作者与链接等。
尊重别人的空间，不在工位附近大声开会，尽量找个会议室。
被尊重是每个人最基本的需要，也是很容易忽略的地方。
我自己也会在心急时，直接把别人的话打断掉，所以自己在这方面还有很大的改善空间。
3.2 不随意批评
因为国内普遍存在的各种上下级等级关系和官本位思想。
遇到阻碍或者问题时，很容易通过「批评」来推动和开展工作，甚至很容易出现所谓的「PUA」话术：
其实，我对你是有一些失望的。当初给你定级px，是高于你面试时的水平的。
我是希望进来后，你能够拼一把，快速成长起来的。
px这个层级，不是把事情做好就可以的
你的产出，和同层级比，是有些单薄的，马上要到年底了，加把劲儿。
什么，这个事情排期要2周，1周就可以了，没有多少工作的。
我自己也亲耳听过类似的话，心情着实是难受。
事实上，如果真的把「尊重」这个基本原则考虑在内，鼓励与赞扬是比批评更有用的工具。
我现在的 manager 是个白人，他就很喜欢夸人，我私下喊他做「夸夸群群主」。
我和组员刚来的时候，可能他担心我们不适宜，或者是不干活，我们做了一些工作之后，总是在换着法子在夸我们：
Thanks you for help to our team, your work makes a great difference.
You are doing a great job, I am impressed by the way you tackled the problems.
You will be successful in Amazon, I am pretty confident about that.
虽然知道老板目的还是想让我们干活，但是被人夸的感觉肯定比被人用鞭子抽打的感觉要好。
见贤思其焉，所以我也学老板多夸人。
有一次和舍友去一家韩餐餐馆吃饭，炸鸡很好吃，其他菜也不错。
上完菜后，韩国小姐姐过来问我们还有需要，我就说，「all foods are delicious, especially the fried chinken」。
小姐姐开心得拍起了小手。
身为中国人，可能从小被教育要内敛和矜持，但我们大可不必太高冷，不要吝啬自己的溢美之词。
3.3 换位思考
高效沟通的另外一个要点就是换位思考，从别人的角度，而不是自己的角度来思考问题。
在沟通对话中，什么对于他们来说是重要的？他们想要的是什么？
最好的方案是一个共赢的方案，可以把多方的诉求都包括在内。
一个非常有效的技巧就是，在开始你自己的观点，先重复一次别人的观点，这样就给对方一个明确的信号，我是真的考虑过你的观点的。
举个例子，前段时间发了一个 Amazon Canada 招聘的文章，有朋友闻讯而来，给我发简历，让我内推到系统中。
只是他没有预料到的是，发送完简历后，马上就收到一封笔试邮件，要求在一周内完成笔试。
朋友觉得时间太紧，没有准备好，于是邮件告知我准备放弃。
我思索片刻之后，决定与recruiter 沟通下，询问能否推迟笔试截止时间。
因为对于朋友而言，他的诉求肯定是有充足的时间来准备；
而对于recruiter 而言，她们办这个event ，也是希望有尽量多的候选人参加，有尽量多的候选人通过。
所以推迟笔试时间，以便朋友参与笔试，是一个符合多方诉求的方案，最后recruiter 的回复也是可以推迟时间：
3.4 充分的上下文
高效沟通和决策的前提是，提供足够的，充分的信息。
也就是说，在你提问题或者沟通的时候，把问题的上下文信息给提供清楚。
以前经常会遇到的一种情形是，在企业微信被人拉到一个群里，然后被@, 「xx哥，帮忙看下这个问题」。
我也很想帮忙，但是我连问题是什么都不清楚，我是没有办法解决的。
一个群几十上百条信息，我是没有精力去逐条翻聊天纪录的。
然后，很快就会有人打电话过来，让我解决这个xx问题。
如果想要我快速解决问题的话，麻烦首先要给出定义，问题是什么？然后再给出问题的上下文，这样我才能方便排查问题。
但这还不是最佳的咨询姿势，我推崇的咨询方式是所谓的 STAR 方法或者叫「Search before Asking」。
4 STAR 方法：高效提问
所谓的STAR method, 是四个单词的首字母缩写，分别是: Situation(场景), Task(任务), Action(行动)，Result(结果)。即：
- situation: 描述问题的背景，这个问题是什么，以及你为什么需要做这个事情
- task: 你具体的任务是什么，你需要做什么
- action: 你做了什么事情？你的行动是什么.
- result: 结果如何，你得出的结论是什么?
前面提到过，尊重是与人交流的基本原则, 尊重自然包括尊重别人的时间，不做伸手党。
在咨询别人问题的时候，不仅要把问题说清楚，还需要把自己的调查和排查结果告诉别人，即所谓的「search before asking」，这样给人的印象是我尝试自己来解决，但解决无果才来请教你。
既表现出对别人能力的尊重，也显示出自己是经过调查才发问的，避免询问一些低级，Google 就能找到答案的问题。
没有人喜欢伸手党，你直接拿个问题，不经自己思考去询问别人，这就不是交流沟通，是「空手套方案」了。
别人没有这样的义务来给你提供解决方案。
所以我向别人求助，无论是企业微信，邮件，还是当面求教，流程一般是：
- 我现在尝试解决xx问题，我要去解决这个问题的原因是yyy
- 我尝试了解法1, 解法2，都无法解决，这是我的日志
- 尝试这几种解法都不能解决问题，不能你能否根据你的经验，给我提供点思路呢？或者是我漏了什么关键步骤么?
或者是.
- 我现在尝试解决xx问题，我要去解决这个问题的原因是yyy
- 我尝试了方案a xxxx, 得出的结果是xx, 然后我再尝试了方案b xxx, 得出的结果是xxx.
- 我个人感觉这两种方案各有优劣，分别是xxx, 我倾向方案a, 原因是xxx.
- 想请教下，你的看法是觉得哪个方案更优，或者你有什么建议么？
提供足够的信息和选项给别人做选择题，让不是提供个空白问卷让别人做主观题。
毕竟大多数人都喜欢做选择题，省时省力。
—
关于如何提问，《How to ask questions the smart way》一文已经把要点给掰碎讲清楚了，推荐阅读。
5 云雨伞: 有效提建议
来源于日本知名咨询师大石哲之的著作《靠谱：顶尖咨询师教你的工作基本功》，简单有效，原理概括起来就一句话：
天上出现乌云，眼看要下雨，带上伞比较好。
其中的「云」代表通过观察得到的客观事实；「快要下雨」，是从客观事实得出的分析；「带上伞」这个是根据分析给出的建议。
这就所谓的「云雨伞」模型的来源，运用「云雨伞」模型提建议，有理有据有方案，能让对方更愿意接受。
青史留名，给老板提建议（画饼）的名篇《隆中对》，也运用了「云雨伞」模型：
亮答曰：“自董卓以来，豪杰并起，跨州连郡者不可胜数。
…
荆州北据汉、沔，利尽南海，东连吴会，西通巴、蜀，（描述「云」，表达事实）
此用武之国，而其主不能守，此殆天所以资将军，（推测「雨」，即分析利弊）
将军岂有意乎？（带上「伞」，即提出建议）
益州险塞，沃野千里，天府之土，高祖因之以成帝业。（描述「云」，表达事实）
刘璋暗弱，张鲁在北，民殷国富而不知存恤，智能之士思得明君。
将军既帝室之胄，信义著于四海，总揽英雄，思贤如渴，若跨有荆、益，保其岩阻，西和诸戎，南抚夷越，外结好孙权，内修政理；
（推测「雨」，即分析利弊）天下有变，则命一上将将荆州之军以向宛、洛，将军身率益州之众出于秦川，百姓孰敢不箪食壶浆以迎将军者乎？
诚如是，则霸业可成，汉室可兴矣。（带上「伞」，即提出建议）
这一番结合「云雨伞」的建议（画饼），让老板直呼，「孤之有孔明，犹鱼之有水也」
6 总结
所谓的「Skill = knowledge + practice」，知道一项知识，如果不运用，没有办法修炼成技能的。
毕竟「纸上得来终觉浅，绝知此事要躬行」。
要多实践才能提高沟通能力。
推荐几本读过的，关于沟通，心理学与咨询的好书，推荐度由高至低：
- 《非暴力沟通》, 豆瓣评分：8.7(当然，评分只是一个参考项)
- 《社会性动物》，豆瓣评分：9.0
- 《靠谱》：豆瓣评分：7.6
- 《QBQ!問題背後的問題》，豆瓣评分：7.4
软技能系列的下一篇是：
- 软件工程师的软技能指北（四）：简历篇