打破同理心谬论，一文get创企生存绝技

【猎云网（微信号：）】5月27日报道（编译：商纣）

“你不能在一家软件公司说出‘同理心’这个词，没有人会认真对待你的。”

Andrea Goulet简直不敢相信自己听到了什么。这一建议来自于2009年她在科吉比茨培养团队时雇佣的一位好心的顾问。她曾想将同理心作为一个核心价值观，但却遇到了来自全行业的误解，也就是所谓的“同理心”和“技术技能”是无法兼容的。

很快，十年过去了，人们的态度似乎发生了转变。“我们已经走了很长的一段路，回头看看，那个时候人们把‘同理心’这个词看成是一句脏话。事实上上，我已经就这个话题做了几次主题演讲，技术工程师们对这个我必须要说的观点越来越感兴趣，” Goulet说道。

但在她看来，这种变化才刚刚开始，且远远不够。“此时，我们为行业逐渐认可同理心而庆祝，同时探讨它在工作中的重要性，这是一个很好的征兆。但是我们必须要谨慎小心，切勿过分抽象，也不要流于表面。我们需要向前迈出一大步，认识到同理心是一种可以学习并加以应用的技能。”

对于那些认为同理心属于感性的模糊领域的人来说，这个结论似乎有违直觉。但考虑到Goulet的背景，她具备独特的能力来描绘这种联系。她的职业生涯是从做文案开始的，这个角色依赖于理解和培养与读者之间的联系。后来，她转投工程专业，创立Corgibytes时，她惊讶地发现， 在看似完全不同的文案写作和代码编写之间存在惊人的相似之处。

“写代码和写文案比你想象的更相似。业界存在一种误解，认为我们使用的编程语言只是为机器编写的。但是我们并不是用1和0来写代码对吧？我们用编译过的语言写代码，这样其他人就能读懂。 编码是一种交流方式，而沟通扎根于同理心。 因此，如果软件工程师能够将同理心作为一种战术技能，就可以获得很多好处。”

今天，Corgibytes的联合创始人兼首席执行官Goulet可以很自豪地说出上面的一段话，因为她确实已经将“同理心”具体化为corgibytes的核心价值观。如今，凭借自身的创业经验，她决心改变科技行业对这一关键技能——“同理心”——的看法。

在这次独家采访中，Goulet打破了三个谬论，这三个谬论阻止了技术工程师们形成自己的同理心技能。Goulet解释了为什么在写代码的过程中保留传播构件是一种同理心练习方法，而且她介绍了一种同理心驱动发展（Empathy-Driven Development）的高级框架，这是一种能够将同理心技能嵌入到技术工程团队的高度程序化框架。无论你是在学习同理心的道路上刚刚起步，还是想把你的同理心练习提升到一个新的水平，Goulet提供的这款框架是初学者的技巧和高级策略的完美结合。最后，她向创业者们发出呼吁，千万不要把同理心看作是一种抽象的情感或者是天生的才能，而是要 把同理心看作是一种强大的、可操作性的工具，每一个工程师的 工具 箱里都应该拥有这款工具。

一、打破同理心谬论

尽管人们可能正在形成这样的一种共识，认为同理心很重要，但Goulet担心：技术工程界围绕这一关键技能展开的讨论可能会使人们误入歧途。如果人们对同理心没有一个坚定的、源自技术上的理解，就很容易轻易忽略它。他们可能会对它的含义做出假设，这最终会强化人们对同理心的刻板印象，甚至让我们已经做出的努力付诸东流。

在本文中，Goulet打破了关于同理心的三个常见谬论，以帮助创始人和技术负责人理解并发展他们团队内的同理心文化。

谬论1：同理心只是一种感觉

软件行业长期以来不愿接受同理心的根源在于对什么是同理心有着本质上的误解。大多数人认为同理心只是一种感觉。不错，同理心中绝对包含感情因素，但是单纯地将同理心理解成一种感觉绝对是不够的。

有一次，Goulet在查找与同理心相关的案例时，偶然打开了一本由杨英迪（Indi Young）撰写的《实用同理心手册（Practical Empathy）》，杨英迪最初是一位编程人员，后来成为了一名研究者。在她的研究中，同理心包括六种类型。“她对同理心的分类真的让我感到很震惊，我想如果某个概念可以划分为六个子集，那么这一概念一定是非常密集且具有技术性的。”Goulet说道。

杨英迪在书中写道，同理心是一个名词， 它是个体在倾听他人、并真正理解他们的观点之后所获得的东西。 她还深入探讨了其中一种同理心类型，即认知同理心（cognitive empathy），这是一个理性的过程，用来揭示他人的信仰、价值观、偏好和观点。这个过程已经根深蒂固地存在于营销人员、用户体验研究人员、作家、设计师甚至许多前端工程师的工作中。我的目标是真正地对杨英迪的研究进行学习探索，在UX社区中这种学习氛围已经很好地建立起来了。然后我希望找到一种方法来扩展它，让更多的人在后端进行操作。

Goulet从杨英迪的学术研究以及Brene Brown博士的研究中获得了灵感，然后她给出了一个面向技术工程师的认知同理心的操作化定义：“同理心是前瞻性的换位思考，以及解决问题的实际能力。”

Goulet对于同理心的清晰定义使得技术工程师们能够将其深入运用到现实之中，并将他们对不具备完成任务的能力的恐惧放在一边。Goulet说道：“如果你身处软件行业，你很可能是一个出色的问题解决者。你已经赢了一半，然而一旦你理解了认知同理心，它就是你理解其他同理心类型的关键。”

同理心不是一个抽象的、形而上学的迷，而是一种我们需要尊重的技能，也是一种需要我们不断练习的技能。

谬论2：同理心与软件建构毫不相关

一般来说，大多数人想到成为一名高质量软件工程师所需要的技能时，首先想到的一定不会是同理心。“我们需要改变这种对工程师专业技能的错误理解，”Goulet补充说道。“例如，我讨厌类似于‘你是技术人员还是非技术人员？这样的问题。这个问题不是一个二元对立的问题，你既可以是一个技术型的人才，也可以是一个熟练的、有同理心的沟通者。我想说的是，如果你想成为一名优秀的软件工程师，除了要知道如何让一台机器按照你期望的方式工作之外，还应该知道如何沟通。”

事实证明， 培养同理心对建立多元化、包容性的团队以及为设计师赢得一席之地都很有用 ，但Goulet认为，同理心对软件工程师来说是一种越来越必要的技能。

Goulet认为，提交信息、拉请求、命名、测试、寻找错误消息等等，这些都是与同理心沟通的基本要素。如果说之前的写代码经历教会了我什么，那就是代码不是在真空中编写的，它会不断地被审查和重新访问。也许六个月之后，你的读者可能是你的同事，也可能是你自己。

如果你没有通过清晰的逻辑表达来为你未来的读者考虑，那么你就在创建有问题的遗留代码。一旦这种观念根深蒂固，基础代码就会很难重构。缺乏同理心的工作会在日后不断地困扰工程团队，所以千万不要告诉我这和你们的日常工作不相关。

当然了，工程师一定是善于解决问题的人。但我认为被忽视的是， 工程师本身也是沟通者，编码就是把信息在人和机器之间传递。

此外，同理心可以帮助工程师避免另一个未来可能会发生的问题：将偏见直接灌注到他们所建构的软件之中。我们已经不再假装人类编写的代码会不受人类偏见的影响。”比如，人脸识别算法会显示出种族偏见，或者机器学习软件重现了对女性的偏见。

多样性和包容性不只是团队组成的问题。D&I是为每个人打造更好产品的关键因素，这是所有工程师都应该努力去做的事情，培训开发人员更深入地理解同理心是实现最终目标的关键第一步。

谬论3：同理心是无法进行教学的

人们会很自然地说：“学习如何编码，你可以采取以下步骤。”但有一种谬论是，同理心如果不是你天生就拥有的，那么你就永远无法拥有，因为同理心是无法进行学习的。

承认同理心是一种可以训练学习的技能，是提高同理心的第一步。Goulet说：“是的，确实很难把成长型思维模式应用到你认为固有的特质之上。但是，随着什么是同理心、如何运用同理心以及如何培养同理心的具体步骤愈发详细，我们就有了前进的道路。”

我们当然需要对那些可能难以表达同理心的人保持敏感和包容，但我认为我们需要挑战工程技术领域，让他们做得更好。我们需要摒弃“社交无能的工程师”，这一令人难以置信的破坏性及限制性的刻板印象。这表明，我们不能仅仅因为有人恰好擅长使用机器，就认为他们不再需要或没有能力学习那些对公司和产品建设至关重要的其他技能。事实上，他们是有能力做到所有这些事情的。

技术技能的差距很可能是真实存在的，但要考虑到另一个方面：大多数计算机科学专业的学生们并没有开发出他们所需要的沟通和同理心技能，而这些技能是他们协作并成功构建出适合所有人的产品时所需要的。

二、将“同理心”放入工程技术入门工具包

就像学习一门编程语言或为一项运动展开训练一样，培养同理心应该是一项持续不断的实践行为。Goulet分享了三条提高同理心能力的指导原则：

1. 摒弃责备

工程师可能很熟悉这种场景：重新访问一个完全不可理解的旧代码，但没有找到任何理由。通常的反应是，我的上帝，哪个白痴做出这个决定的？责备确实是工程师的日常。如果你想查看代码更改的历史记录，那么命令行上的默认命令是“git blame”。这种小小的认知启动条件使开发人员看不起前人所做的贡献。

但对原始开发者的羞辱浪费了工程师们宝贵的时间和精力。我们要做的是摒弃责备，他们毫无益处，相反，当你处理代码时，要尊重前人的工作。思考他们为什么选择这个解决方案？那时候你会得到更具启发性的答案。

Goulet建议通过考虑约束条件，提高对前人的同理心。没有人是故意写出那些糟糕的代码的， 人们面临着现实世界中影响代码质量的各种限制——时间、预算、技术限制和不切实际的期望。 思考这些限制条件，你会发现代码库不符合期望的深层原因。

如果没有同理心，你就无法开始解决问题，更不用说更新整个代码库了。从其他 程序员 的角度来分析问题是一项艰巨的、复杂的工作，它植根于对他人行为的深层理解。

2. 尝试做一个考古学者

当谈到利用同理心写代码时，Goulet鼓励工程师们将旧的代码库想象成一个考古遗址。

当考古学家研究一个古老的遗址时，他们并不了解当时的生活情况。他们必须去寻找一些手工艺品：陶器、硬币、文字等等，类似地，如果你现在有意识地将传播构件留在代码中，这将使未来的开发人员更容易解释代码。

确实，如果我忽略传播构件，就能节省我个人的时间。但我的这些想法也有双重目的，深深植根于同理心，即主动换位思考和解决问题。当我试着思考我能做些什么来提供帮助时，我是在对那些即将接替我的人考虑。最终，这种同理心在我自己、团队成员和未来的用户之间建立了信任，因为这几乎就像是我们都在为彼此着想。

许多软件巨头都信奉一句真理： 让代码比你看到它时变得更好。 当你不断练习同理心时，你是在践行这一真理。

Goulet总结了三个重要的方式帮助工程师留下能够对代码产生影响的传播构件。

（1）代码审查：在代码投入使用之前，进行合并请求及代码审查是留下传播构件的理想场所。请记住，你所保留的对话不仅仅是为了应付你的代码审查员，还是为了在未来给予他人理解你的可能。这些人有可能是帮助你修复bug的程序员，也有可能是产品客户经理。请站在他们的立场上思考一下：什么内容能够帮助他们更好地理解语境？

（2）Commit 消息：Commit消息绝对是最好的文档形式，因为它们与代码库紧密耦合。人们经常忘记Commit是由标题和消息两个部分组成的，标题应该是一条短推文的长度，描述则应该是一篇博客文章的长度。

（3）邮件及公司信息系统：每当你和别人交流时，都可以留下一个传播构件，可能是一封简短的电子邮件，或者是一条简单的消息，用于通知、提出问题或征求反馈。同时加注一些上下文帮助他人理解，例如“这是我根据自己的理解想出的，你的观点是什么呢？我们在建立信任和有效协作的方面还有很长的路要走。

3. 像文案工作者一样思考

鉴于写作可能是在工作场所传递同理心最常见的方式，工程师们可以从文案写作者的世界中汲取一些经验。写手们需要在早期磨练同理心，因为他们的写作是为了与受众沟通。无论是编写commit消息还是电子邮件，Goulet都为工程师提供了一些写作技巧：

保持轻松口吻。很多人认为在专业场合就应当使用一些夸张的行话或者复杂的语法，事实上，这种表达会令人感到抗拒。最有效的语言是清晰、简洁和自然的语言，优秀的写作就是简单的写作。

常用第二人称。Goulet认为这是她的写作生涯最重要的秘诀，通过使用第二人称，作者能够直接与读者对话。例如，相对于“检测到一个bug”来说，“对不起，你遇到了一个bug”更能够培养同理心。

不要做假设。不要以为所有阅读你作品的人都知道你所写的一切，如果你在写一个深奥的概念，花点时间来解释它。如果你使用的是首字母缩写词，请在第一次使用时把每个单词拼出来。这样，你的写作就更容易被那些有着与你不同文化背景的读者所接受。”

除此之外，要记住 好记性不如烂笔头。 在你工作的时候，不要忽视那些一闪而过的灵感，把它们记录下来，然后通过那些在工作中共享的传播构件，找到想法并付诸实践。长此以往，你会发现你和他人的效率都得到了提升。

为了帮助你的想法有效运行，你要 学会利用一些工具。 如果你习惯使用命令行，你可以快速搜索一下“命令行日志”。此外，GitHub的wiki和GitBook允许开发人员使用文本编辑器和Git客户机记录想法和笔记。

三、提升同理心：共情驱动发展的高级框架

对于那些喜欢框架的工程师来说，Goulet打破了认知同理心的程序模型，创建了一种团队可以直接集成到工作流程之中的算法，她称之为“同理心驱动发展”（Empathy-Driven Development）。

测试驱动的发展（Test-Driven Development）可以描述为红色、绿色以及重构。同样，同理心驱动的发展可以提炼为受众和行动。首先，考虑你的用户，即那些将要与你的内容进行交互的人，包括你的代码和你留下的传播构件。然后，采取行动，思考如何主动预测他们的需求。

为了说明同理心驱动的开发在工作中的实际作用，Goulet举了一个例子：假设你的任务是为bookkeeping app编写一条错误消息。在这种情况下，你该如何利用同理心，并留下一个传播构件？

首先，考虑受众：

（1）识别个体。列出除了最终用户之外，可能会使用到你的工作产品的人。你的受众很可能包括了各种各样的用户，在这个案例中，你的受众可能包括一个自由职业艺术家、你公司的客户经理以及未来的你。

（2）考虑上下文。一旦你确定了这些人的身份，你就要开始思考他们的背景，以及他们可能的应用场景。艺术家是在手机上使用这个应用程序；客户经理在重压之下谋求肯定的答复；六个月后，未来的你正在阅读自己的代码、同时修复一个bug。

（3）定义需求。最后，思考每个个体的需求。痛点并不总是显而易见的，你可以通过问问题、读文章，总之尽你所能去了解他们。使用应用程序的人和时间紧迫的客户经理需要你做什么？未来的你又需要什么？

然后，采取行动：

（1）最好采取何种行动？你已经收集了关于受众的宝贵信息，尝试去思考可以做些什么来帮助他们。

（2）什么是可行的？你不可能满足所有人的要求，所以你要考虑一下你实际上能做的是什么？

（3）创建辅助项目。你创建了你的主要传播构件，一条清晰的错误信息，但你的工作还没有结束。你需要创建一些辅助项目，采取多种形式来进行表达，帮助你的内容更容易被理解。

随着时间的推移，加上足够的练习，这些步骤会变得直观起来。当然一开始你会感到缓慢和繁重，但是Goulet鼓励开发人员坚持下去，为未来的读者考虑一下，最后你会发现效率有很大的提高。这就像你刚刚学开车的时候，一上车总是各种检查，但有了足够的驾驶经验，看后视镜就成了自然而然的习惯。同理心驱动的发展也是如此，一旦你养成了习惯，它就会变成一种优秀的本能。另一方面，你要知道，缺乏沟通的不断累加终会带来不良的后果，最直接的后果就是使得代码的维护变得更加的困难。培养同理心不会给你现有的工作流程带来多大的负担，但益处一定是深远的，今天的一个信息能够在未来节约大笔的时间和失败感。

四、超越代码拓展同理心

写代码并不是唯一一个能从同理心技能培养中受益的东西，工程团队和整个公司都能够从同理心文化中获益良多。以下，Goulet分享了自己的同理心提升IRL实践。

团队互读日志

将传播构件留在代码中并不是在软件团队中进行同理心训练的唯一方法，Goulet团队还想出一个每日互读日志的方法。每个人都有一个网页，可以在自己的网页上同团队里的所有人分享自己的日志，日志的内容就是你每天的思考和记录。

与代码中的传播构件一样，花费在日志上的时间最终会给予回报。每天大约花费15分钟来回顾当天的工作内容，能够帮助员工在6个月之后清晰地了解自己当时的想法。我的团队成员也通过日志互读的活动提高了协作能力，如果你在日志中提到了自己遇到的一个问题、或者自己的想法，别的同事就会尽他们的所能来帮助你，或者分享他们的经验。

每个人都是客服代表

学习同理心的最快途径是通过客户服务。因为只有当你真正了解用户的需求时，你才明白你需要做什么。客户服务的概念被灌输到我们团队的每一个人身上，包括律师、程序员和所有的工作人员。

早期初创企业在整合同理心、培养以用户为中心的企业文化方面处于特别有利的位置，初创企业的早期阶段是将同理心融入企业文化的最佳时机。你可以建立一个标准，让每个人随着公司的发展而不断优化，学会重视用户的反馈。教会员工：走出去，倾听客户的需求。而对于更大的公司来说，Goulet建议进行全公司的同理心培训。

倾听他人的心声

为了更进一步采取积极主动的观点，Goulet建议举办倾听会议，这是从杨英迪哪里借用的另一个概念。与随意的谈话不同，倾听过程明确地要求你理解他人的推理、反应。倾听的目的是帮助你摆脱以己度人的危险习惯，学会用理性指导决策。

一旦开始倾听，你就要把你的判断彻底摒弃。记住，你是为了收集数据，而不是为了改变他人主意。倾听的目标是赢得演讲者的信任，了解他们的情感和行为原因。

五、信任裂变：同理心就是创企的未来

尽管目前人们已经愈发接受同理心作为一种实用技能，但Goulet仍旧希望创业公司能够将同理心作为一种专业技能来认真对待。

对于那些想要培养同理心的工程师们来说，首先要破除长期存在的谬论。投入时间来创建传播构件，为未来的代码读者照亮道路。利用同理心驱动的发展来主动了解你的受众，然后满足他们的需求。最后，通过与团队共享日志和建立自己对产品运行的广泛生态系统来提高工作水平。

一旦团队和创业公司将同理心视为一种技能和习惯，他们就可以开始体验不可思议的同理心文化和技术收益带来的雪球效应。Goulet将这种效应称为信任裂变：和谐运作的团队会带来的复合、加速、成倍增长的好处。

人们总是说，最重要的是建立对团队的信任。然而，信任就是同理心的产物。当我们试图创造一种信任的企业文化时，同理心是我们可以运用的有效武器。

信任裂变的文化为团队成员行使更多的权力和成为领导者铺平了道路，而同理心培养的最终目标则是团队内所有成员都会主动去问：我能做些什么帮助后来者变得更好？