有效的沟通，如忍者的最后一击！

《神经漫游者》——在这部同时获得“雨果奖”、“星云奖”和“菲利普·狄克奖”三大奖项的科幻作品之中，威廉·吉布森塑造了一位冷酷而性感的刀锋女战士——莫利。她出手迅捷，装备精良，几乎无所畏惧。然而，令她真正有所忌惮的，却是周身散发着冷静气息的忍者杀手。

作者借莫利之口讲了一个小故事：

我小时候住在贫民窟里边。在哈得孙河旁边，那里的耗子，因为化学毒素的影响，天，真是够大，跟我差不多个头了。有天晚上，一只耗子一直在地板下面掏来掏去。天亮的时候，有人找来了一个老头......

......

他低着头，双臂抱在胸前，来来回回地踱步，好像完全忘记了自己有枪。他专心倾听耗子的动静，我们一口气都不敢出。老头走一步，耗子就动一动。耗子动一动，他再走一步。就这么过了一个小时，他好像突然想起了自己的枪，把枪指向地板，笑了一笑，扣动扳机。然后他就又卷起包袱走了。

后来我爬到下面去看过，那耗子双眼之间有个窟窿。

故事中的这位老人，就有着忍者的典型特质：冷静而不张扬，深思熟虑后一击必中。

我们在平常的团队合作中，每每见到技术高手之间的交流，就与此类似。技术人员往往善谈者少，口若悬河滔滔不绝者少之又少，但一旦讨论起技术问题来，沉思片刻，三言两语，却总能句句切中要害。

在不同的时候，不同的项目中，我们经常会与不同的人展开合作。当我们感到与合作的人交流起来得心应手、爽快利落的时候，我们总不免与对方互相钦佩，引为知音。相反，也总有一些人，我们与其沟通起来总像中间隔着点什么东西，貌似懂了又好像没懂，从而丢失了重要的信息。

类似的感觉在面试的场景中也比较常见。我们与表达清晰的应聘者，虽然是第一次见面，却能如同老友一样讨论问题，恨不得立即成为同事。而另一些人说话却总是抓不到重点，整个沟通的过程就像在玩捉迷藏的游戏，双方的思维总也碰不到一块，最终造成没办法把问题讨论到足够深入。正所谓话不投机。

是什么造成了这些不同呢？下面我们就从几个方面分析一下。

表达须遵循逻辑

无论是实现技术细节，还是设计产品功能，又或者是制定公司战略，都有逻辑可循。逻辑不够清晰的决定，很可能便是错误的决定。

逻辑存在于思维之中，而表达是思维中逻辑的对外延伸。也因此，在某些郑重的场合下，我们可以通过与一个人的简单对话来窥见其思维的缜密程度。要理解这种感受，只需要想想我们加入的某些微信或QQ技术群，根据每个人在群中的发言，即使彼此素未谋面，是不是我们也能根据这些只言片语对每个人的思维特点能有个大概的了解呢？

只要遵循思维的逻辑，凡事定有一个答案。有些问题可能有不同的解决思路，比如设计系统架构或软件架构，很多选择有赖于经验，但不同选择之间的优缺点，却是全然可以依赖逻辑进行分析和理解的。碰到问题，我们应该首先将它交给逻辑去做一个全面的剖析，然后再就剖析的关键节点与他人进行沟通，而不是胡乱地将问题抛给别人。

对逻辑的认识和态度是个形而上的问题，无疑它是所有事情中最重要的因素，但不得不说，要真正清晰地表达其重要性，却是个困难的话题。

沟通中的互补和交叉模式

当多个人合作一个较大的项目时，不可能每个人对整个项目的所有信息都了如指掌。根据分工，通常每个人只能了解到自己负责的那部分信息。这样，在分工的边界上，就存在沟通的需求，分工的边界也就成为沟通的边界。

以两个合作成员之间的关系为例，我们理想中的情况是下面这样的（互补模式）。外层长方形表示所有相关的信息。两个人掌握的信息恰好是互补的，在他们之间的分工边界上，沟通也恰到好处，没有造成任何信息的遗漏。

但真实情况往往不是如此，而是下面这样的，在沟通中存在信息遗漏（灰色区域）。这些遗漏的信息在项目后期有可能造成糟糕的后果。

而在真正长于合作与沟通的人之间，情况则如下图所示（交叉模式）。这也是我们所提倡的方式。

在这种交叉模式中，合作的双方除了要掌握自己的那一部分信息之外，还需要超越分工边界向外扩展，尽量扩大自己掌握的信息域。这样，双方围绕分工的边界就掌握了一部分重合的信息，沟通起来就没有障碍，而且大大降低了信息遗漏的风险。

技术交流中的同理心

同理心（Empathy），是人际交往中重要的心理学原则，它要求我们站在对方的立场上去思考问题，继而与人交流。类似于换位思考，将心比心。

对于技术人员之间的交流来说，同理心原则要求我们要使用对方的词汇，或者双方认可的词汇进行沟通。这与前面我们提到的沟通中的“交叉模式”有一定的关系。只有当我们在沟通的边界上了解到了足够的信息，从而涉足到对方的认知领域之后，才有可能以对方的词汇与之交流。

在正式的场合，这里沟通的边界是可以被严格定义的，通常以文档或API接口的形式呈现。比如开放平台或者开源项目对外提供的技术服务。在这种情况下，文档和API接口是官方与开发者（服务使用者）沟通的主要组成部分，自然应该站在开发者的角度上以尽量友好的方式提供。

然而，在我们平常接触到的众多开放API和其它技术服务当中，能提供一份好文档的可以说绝无仅有。我们经常碰到的情况是，我们不得不面对一份不成体系且十分凌乱的文档，这迫使开发者们不得不通过其它方式从官方获取帮助，比如技术客服。而有些开放平台的技术客服缺乏训练，在沟通中缺乏同理心。他们甚至连自己的官方文档都没有读过，导致在沟通中并不使用双方都认可的词汇，而是采用内部词汇。这让开发者更加迷惑。

相反，在开发者的一方，同理心在沟通中同样有效。我们经常能看到开发者在问问题的时候分不清沟通的边界，只是简单地贴出自己碰到的一些异常，或者很模糊地描述自己的问题，导致回答者得不到足够的信息。所以有些技术专家会建议工程师在碰到问题后向社区提问，比如通过Stack Overflow，或者向开源项目提issue的方式，而不是以非正式的方式在QQ群里进行讨论。这是因为向社区的提问方式会逼迫你跳出自我的思维逻辑，按照大家一致认可的方式和词汇进行表达。会提问题本身，也是一种不凡的能力。

而在另外更多的非正式的场合，沟通的边界不一定有那么严格的定义，但所有这些沟通的原则，同理心，使用双方认可的词汇，开放接口式的思维，它们仍然可以被借鉴。比如公司内部部门之间，应该以做开放API或开源项目的姿态，来对外提供服务和进行沟通。

这些道理缩小到个人身上也同样适用，长期训练，它会让你在与人沟通的时候迅速摸清沟通边界上的关键节点，从而在表达上能够一语中的。

---

程序员，是一个比较特殊的职业，每天要花费大量的时间在逻辑和内心的思考上面。而越复杂的工作，也越是会让人沉浸在“我”的状态中跳不出来，这与一些沟通原则，比如同理心，是背道而驰的。这使得针对沟通这一话题的探讨是必要而有意义的。

然而，沟通是个很大的话题，它涉及到的内容也远远不是本文短小的篇幅所能承载的。因此，本文将关注的重点集中在技术人员的沟通问题上，将我内心一些细小的想法记录下来，希望能与你产生共鸣。

（完）

其它精选文章：

• 技术的成长曲线
• 互联网风雨十年，我所经历的技术变迁
• 技术的正宗与野路子
• 程序员的宇宙时间线
• 论人生之转折
• Redis 中的集合类型是怎么实现的？
• 小白的数据进阶之路
• 你需要了解深度学习和神经网络这项技术吗？
• 程序员的那些反模式