“你不能在软件公司说‘同理心’这个词。没人会把你当回事。”
安德里亚。古利特简直不敢相信她所听到的。这个建议来自于她在培养团队时聘请的一位好意的顾问Corgibytes早在2009年。她曾想把同理心作为一种核心价值，但遇到了整个行业的误解，认为同理心和技术技能是不可调和的。
十年过去了，人们的态度似乎发生了转变。“当人们把同理心视为一个肮脏的词时，我们已经走过了很长一段路。实际上，我现在已经就这个话题做了一些主题演讲，工程师们对我要说的话越来越感兴趣。”
但在她眼里，对话才刚刚开始，还差得很远。“我们处在这个庆祝同理心并谈论它在工作中的重要性的时刻，这很好。但我们必须小心，不要让它变得太抽象或局限于表面层面的讨论。”“我看到的是，谈话往往停留在‘要更有同理心!’我们需要向前迈进一步，认识到同理心是一种可以学习和应用的技能。”
对于那些认为同理心属于模糊的多愁善感领域的人来说，这一结论似乎违反了直觉。但考虑到她的背景，古利特有独特的条件来建立联系。她的职业生涯是从广告文案开始的，这个角色依赖于理解和培养与读者的联系。当她转向工程并创立柯基贝斯公司时，她致力于通过重塑技术债务来积累技术财富她惊讶地发现，文案和代码编写这两种看似完全不同的技能竟然有惊人的相似之处。
“编码和文案比你想象的要相似得多。有一种误解，认为我们使用的编程语言只针对机器编写，”她说。“但我们不会用1和0来写代码，对吧?我们用编译语言编写代码，以便其他人能够阅读，不管是我们的团队还是未来的自己。编码是一种通信形式。沟通植根于同理心。因此，软件工程师从将同理心作为一种战术技能中获益良多。”
如今，这位联合创始人兼首席执行官很自豪地说，事实上，将同理心具体化为核心价值在Corgibytes。现在，凭借在自己的公司实现同理心的经验，她决心改变科技行业谈论这一关键技能的方式。
在这次独家采访中，古利特打破了阻碍工程师磨练他们的同理心专业知识的三个误区。她解释了为什么在代码中保留通信工件是一种移情练习，并介绍了移情驱动开发(empathy - driven Development)，这是一种将这一关键技能嵌入工程团队的高度程序化框架。无论你是刚刚踏上共情之路，还是希望将你的练习提高到一个新的水平，古利特提供了初学者的建议和高级策略的混合。最终，她要求企业家不要把同理心视为一种抽象概念或一种天生的才能，而是一种强大的、可操作的工具，属于每个工程师的工具箱。
首先，消除这些同理心神话
尽管同理心很重要的共识可能正在形成，但古利特担心，工程领域围绕这一关键技能的讨论正在把我们引入歧途。她说:“如果人们对同理心没有一个坚定的、技术性的理解，就很容易忽视它。”“他们可能会对它的含义做出假设，这最终会强化对它的刻板印象，甚至会让我们倒退。”
在这里，古利特拆解了关于共情的三个常见误区，以帮助创始人和技术主管理解和培养团队中的共情。
误解1:同理心只是一种感觉。
软件行业长期以来不愿接纳共情，根源在于对共情到底是什么存在根本性的误解。“大多数人认为同理心只是一种感觉，”她说。“它肯定涉及到感情然而，这种同理心的概念化确实有局限性。”
在寻找同理心的案例时，古利特偶然发现了英蒂年轻的实用的同理心作者是一名程序员出身的研究员，她在书中描述了不止一种，而是六种同理心。“这种小分类真的打动了我。我想，如果一个东西可以被分成六个子集，那么它一定是相当密集和技术性的，”古利特说。
Indi写道，同理心是一个名词——它是你在倾听别人并真正理解他们的观点后获得的东西。她还深入研究了其中一种叫做认知移情，这是一个理性的用来揭示另一个人的信仰、价值观、喜好和观点的过程。这个过程已经在市场营销人员、UX研究人员、作家、设计师，甚至许多前端工程师的工作中根深蒂固。”“我的目标是真正研究Indi的工作，它在用户体验社区中已经非常成熟，然后找到一种方法将其扩展到更多在后端操作的人。”
从杨的学术以及对布琳布朗博士， Goulet提出了一个适用于工程师的认知共情定义:“共情是主动的换位思考和解决问题。”
古利特清晰的定义使工程师能够投入到实现中去，把他们对不具备完成任务的能力的恐惧抛在一边。“如果你从事软件行业，你可能是一个出色的问题解决者。你已经赢得了战斗的一半，”她说。“一旦你理解了认知同理心，它就是理解其他亚型的丰富世界的关键。”
同理心并不是抽象的、形而上的谜。这是我们需要尊重的技能，也是我们需要锻炼的肌肉。
误解2:同理心与构建软件无关。
当大多数人想到成为一名有效的工程师所需要的技能时，同情可能不是第一个出现在脑海中的。古利特说:“我们需要处理对工程师和专业技能的错误误解。”“例如，我讨厌别人问我‘你是技术人员还是非技术人员?”的问题。这不是二进制。你可以是专业的，知道如何成为一个熟练的，同理心的沟通者。我认为如果你想成为一名优秀的工程师，你应该除了知道如何让机器按你期望的方式工作外，还要知道如何与人沟通。”
虽然移情被证明是有用的打造多元包容的团队而且为设计师赢得一席之地，古利特认为，同理心是工程师越来越必要的技能。
她说:“提交消息、拉请求、命名、测试、错误消息，这些都是从根本上与同理心沟通。”“如果有什么使用遗留代码教会了我，是那个吗代码不是在真空中编写的;它被不断地回顾和重新审视．你未来的读者可能是你的同事。也可能是六个月后的你自己。”
Goulet说:“如果你不通过清楚地交流你的推理来考虑到未来的读者，你就会创造出有问题的遗留代码。”一旦这种情况根深蒂固，代码库就很难重构了。没有同理心的工作直接与困扰工程团队的最大问题之一有关。所以不要告诉我这和你的日常工作无关。”
当然，工程师是优秀的问题解决者。但我认为有一点被忽视了，工程师也是天生的沟通者。编码就是把信息传递给人，也传递给机器。
此外，古利特认为，同理心可以帮助工程师避免未来的另一个问题:将偏见直接植入他们构建的软件中。她说:“我们已经过了假装人类编写的代码不受人类偏见影响的阶段。面部识别算法显示出种族偏见或者当机器学习软件复制时对妇女的偏见．
”多样性和包容性不仅仅是团队组成的问题．D&I是构建更好的产品、为所有人服务的关键因素——这是所有工程师都应该努力做到的。”“培训开发人员更深入地理解同理心是实现这一最终目标的关键第一步。”
误解3:同理心是无法教出来的。
“人们很容易说，‘学习如何编程，以下是你可以采取的步骤。’但有一种误解，认为同理心要么是你拥有的东西，要么是你没有的东西，它是无法培养的，”古利特说。
承认同理心是一种可训练的技能是提高它的第一步。”你很难将成长型思维模式应用到你认为固有的、固定的特质上。但通过对什么是同理心、如何应用它以及如何培养它的实际分解，就有了一条前进的道路，”她说。
古利特说:“虽然我们当然需要对那些可能难以表达同理心的人保持敏感和包容，但我认为我们需要挑战工程领域，以便做得更好。”“我们需要摒弃‘不擅长社交的工程师’这种极具破坏性和限制性的刻板印象。“这表明，仅仅因为某人碰巧擅长使用机器，他就不需要或没有能力学习对公司和产品建设至关重要的其他技能。”事实是，你有能力成为所有这些人。”
技术技能的差距可能是真实存在的，但考虑到硬币的另一面:大多数计算机科学专业的学生没有培养沟通和同理心的技能，他们需要合作和成功地开发出适合所有人的产品。
这是将同理心植入工程实践的入门工具包
就像学习编程语言或体育训练一样，培养同理心应该是持续练习的一部分。古利特分享了三条指导原则，当你开始磨砺自己的同理心时，你可以依靠:
1.为了荣誉而推卸责任。
工程师们可能对这种场景很熟悉:您重新访问完全不可理解的旧代码，找不到任何理由。这暗示了人们的挫败感。“通常的反应是，我的天，是谁这么蠢才决定这么做的？责备实际上是被烙进了我们的工具里，”Goulet说。“如果你想查看代码更改的历史，默认命令是命令行上的' git blame '。这种小小的认知启动会让开发者看不起前人的贡献。”
但是羞辱最初的开发者会浪费宝贵的时间和精力。“我们需要超越责任和耻辱。他们是徒劳的,同理心的反面”。古利特说。“相反,当您开始编写代码时，要尊重在您之前的人的工作。认为好吧，我想大家都尽力了。他们为什么选择这个解决方案?那时你会得到更有启发性的答案。”
Goulet建议考虑约束条件，以帮助你对过去的开发者产生更多同理心。”没有人一觉醒来就决定写最糟糕的代码。这根本说不通，”她说。“人们面临着影响代码质量的现实世界的约束——时间、预算、技术限制和不切实际的期望。遵循约束条件，您将发现代码库没有达到您的期望的更深层次的原因。”
如果没有同理心，你就无法开始解决问题，更不用说现代化整个代码库了。从另一个工程师的角度分析问题是一项艰难而复杂的工作，它植根于理解某人为什么做出了他们所做的选择。
2.把你的项目想象成考古挖掘。
当谈到构建同理心编码实践时，Goulet鼓励工程师将旧代码库想象成考古遗址。
“当考古学家研究一个古代遗址时，他们对当时的生活没有完整的了解。他们必须寻找文物:陶器、硬币，有时还有文字。”“同样，如果你离开沟通工件在您现在的代码中，它使未来的开发人员更容易解释您的代码。”
虽然她一直认为，当你重新构建遗留代码，从堆积如山的技术债务中解脱出来之后，古利特意识到，从本质上讲，创作它们的行为也是一种同理心的练习。
“是的，如果我留下交流工具，就会节省下一个人的时间。但我的这些想法也有双重目的，深深植根于同理心。这真的可以追溯到移情的定义，即积极的换位思考和解决问题。当我试着思考我能做些什么来帮助别人时，我是在锻炼对那些以后会来帮助我的人的同理心，”她说。“最终，这种同理心会在我自己、团队成员和未来读者之间建立信任，因为我们几乎都在互相照顾。”
许多软件界的杰出人物都援引了古老的“侦察”规则，他们说:“让代码比发现时更好。”当你练习同理心时，你就是在强化这句座右铭。
她确定了三个接触点，在那里工程师可以留下对代码产生影响的通信工件，并留下信任的遗产。
在你的代码评审中:合并请求和其他类似的在投入生产之前评审代码的邀请是工程师练习留下通信工件的理想场所。Goulet说:“记住，你的对话不仅仅是针对你的代码审查员。“想想大。你是在为未来的自己保留理性。对于在修复bug时需要与这段代码进行交互的开发人员来说。客户成功经理。听听他们的观点:什么对他们有用?怎样才能给他们提供语境?”
在提交消息中:“提交消息绝对是文档的最佳形式，因为它们与代码库紧密耦合，”她说。“人们经常忘记提交是由两个部分组成的:标题和消息。我的朋友,戴夫烈性黑啤酒也就是说，标题应该是一条短推文的长度，如果必要的话，描述应该是一篇博客文章的长度。”
在你的电子邮件和公司信息系统中:古利特说:“每当你与他人互动时，你就有机会留下一个沟通神器。”这可能是一封简短的电子邮件或Slack信息，用于通知、提问或征求反馈。不要只是删除一个没有上下文的链接或说，“这是我做的事情”，添加一些上下文，表明你已经倾听并愿意接受反馈。一个简单的句子，比如“这是我根据自己的理解得出的结论。”你的观点是什么?’对于建立信任和合作大有裨益。”
3.像文案一样思考。
鉴于写作可能是在工作场所传递同理心最常见的工具，工程师可以从文案界获得一些经验教训。古利特说:“作家需要在早期培养同理心，因为他们写作是为了与读者建立联系。”无论你是在撰写提交信息还是电子邮件，古利特都为工程师提供了她最好的写作建议:
保持你的语气随意和对话。许多人感到压力，在专业场合用夸张的行话或复杂的句法“装饰”他们的语言。抗拒的冲动。“最有效的语言是清晰、简洁和自然的，”古利特说。“好的写作就是简单的写作。”
永远不要低估第二人称主动语态的力量。“这是我做广告文案时得到的最重要的建议之一，”她说。快速复习一下语法:在第二人称中，作者直接称呼读者，使用“你”。主动语态表明读者正在执行这个动作。第二人称主动语态是被动语态的区别检测到一个错误。”更积极，更有同理心"抱歉，你遇到了bug，’”。古利特说．
不要假设。“不要以为每个读你文章的人都知道你在写什么，”古利特说。“如果你写的是一个深奥的概念，花点时间来解释它。如果你用的是首字母缩写词，在第一次使用的时候就把它拼出来。这样，你的作品更容易被那些与你有不同技能和优势的读者所理解。”
为了帮助她在实践中保持同理心，古利特依靠从她的一位导师那里得到的建议，山姆的角在她的文案生涯早期。古利特说:“山姆是一个出色的沟通者，他教会了我很多关于同理心和思维的东西。”“她总是告诉我，‘短铅笔胜过长记性。’”当你在工作的时候，不要忽略出现的想法，而是把它们写下来。然后，通过利用和分享你在日常工作中已经创建的沟通构件，找到将你的想法转化为行动的方法．”
关于如何改进流程，或如何为下一个人清理代码的同理心想法，往往会在日常需求的拥挤中丢失。在你工作的时候保持一个持续的想法日志，在你养成创造你的想法工件的习惯的同时，最大限度地减少上下文切换。古利特说:“随着时间的推移，当你发现模式并了解什么最有效时，创意产生和在哪里分享之间的联系将变得更加直观。”
为了帮助你的想法记录下来并运行起来，利用你已经在使用的工具，这样就可以减少记录想法的摩擦和上下文切换。她说:“如果你习惯使用命令行，快速搜索‘命令行日志’会给你提供大量可以尝试的工具。”或者，基于git的wiki，例如GitHubwiki和GitBook允许开发者使用文本编辑器和Git客户端记录想法和笔记。”
提升你的同理心:一个用于同理心驱动开发的高级框架
对于那些喜欢好的框架的工程师，古利特打破了认知共情的过程模型，创建了一种算法，团队可以将其集成到工作流程中。她称之为来自共鸣发展．
”测试驱动开发可以描述为红色，绿色，重构。同理心驱动开发也可以提炼为观众而且行动”。古利特说。“首先，考虑你的受众，即那些将与你的内容进行交互的人，这包括你的代码和你留下的沟通构件。然后,采取行动。想想怎样才能主动预测他们的需求。”
为了说明移情驱动开发的工作原理，Goulet举了一个你在小型初创公司开发人员可能会遇到的问题:“假设你的任务是为一个记账应用程序写一条错误信息。在这种情况下，你会如何利用移情?”在这种情况下，您将为您的观众留下一个主要的通信工件(错误消息)。
首先，考虑用户:
识别个人。“列出除了最终用户之外，你预计会遇到你的工作产品的个人。很有可能，你的受众包括各种各样的用户。”“在这个例子中，你的受众可能包括自由艺术家、公司的客户成功经理和未来的自己。”
考虑上下文。古利特说:“一旦你确定了每个人的身份，想想他们从哪里来，现在在哪里。”“艺术家使用手机上的应用程序;客户成功经理是在压力下响应支持票;六个月后，你未来的自己正在一边修复bug一边阅读自己的代码。”
定义他们的需求。最后，考虑每个人的挑战和需求。“痛点并不总是明显的。问问题，读文章——尽你所能去了解他们，”她说。“使用应用程序的用户和时间紧迫的客户成功经理需要你做什么?”未来的你需要什么?”
然后,采取行动:
最好的行动是什么?所以你已经收集了关于你的观众的有价值的信息。用这种新的理解来思考可以做些什么来提供帮助，”她说。您希望验证用户对错误消息的不满。对于客户成功经理，您需要在错误消息中编写一个简单的参考代码。为了未来的自己，你可能想现在就修复所有的错误。”
可行的是什么?“你不可能一直都能做到这一点最好的有帮助的东西，所以考虑一下你实际上可以做的。你有什么时间和资源去执行，让他们的生活更好一点?几乎都有某物你可以做。想想微小的原子。即使是最小的行动也会累积起来，”古利特说。
创建辅助构件。“一旦你创建了你的主要通信工件——一个伟大的、清晰的错误信息——你的工作就没有结束。在你的完成定义中包含次要工件，”Goulet说。“次级工件是你的想法、基本原理和约束条件的持久证据，这些都是在你致力于主要工件时出现的，并且可以采取多种形式。”她建议从上面的沟通工件图表中寻找灵感，甚至为你的项目创建一个象限来产生更多的想法。“在软件系统中，自然语言存在的地方太多了。这与繁琐的文档无关。而是用更大的意愿去做你已经在做的事。”
随着时间的推移，加上足够的练习，这些步骤开始变得直观。古利特认识到，这个过程一开始往往感觉缓慢和负担，但鼓励开发人员坚持下去。“与TDD一样，共情驱动开发一开始会感觉缓慢。此时，很容易认为留下一个通信工件是不重要的，或者您没有时间。但是，许多工件需要额外的30秒，最多几分钟，才能为未来的读者完成一个想法。定期留下通信工件所获得的边际收益最终远远超过短期的时间投资”。古利特说。
她说:“这就像你第一次学开车时核对的清单一样。”“一旦你有了足够的驾驶经验，检查所有的后视镜就成了你的第二天性。同理心驱动开发也是如此。一旦你养成了这个习惯，它就会变成一种健康的本能。”
另一方面，疏忽的影响是复合的，因为缺乏交流工件可能构成对未来读者不愉快的继承。古利特说:“这就是为什么软件维护起来如此困难的原因，因为未来的开发人员不得不重新开始。”“你已经在研究你的理论基础了。现在，在你继续前进之前，花点时间把它记录下来。”
练习同理心不会给你现有的工作流程增加太多时间，而且好处是深远的:今天一个明确的提交信息可以节省每个人的时间和未来的挫折。
超越代码扩展同理心
你的代码库并不是从同理心中受益的唯一东西——工程团队和整个公司也一样。从团队实践到文化范式转变，古利特分享了她提高共情的高级实践。
让你的团队阅读你的日记。
在代码中保留交流工件并不是在软件团队中锻炼同理心的唯一方法。除了Slack上的#大喊频道，古利特的团队还采用了保持的做法每天的日记．她说:“每个人都有一个Wiki页面，团队中的任何人都可以看到，我们每天都在记录和反思。”“每个人都有自己喜欢的记录这些微观决策的方式。有些人使用项目列表，有些人使用句子——任何适合每个作者的方法。”
与代码中的通信工件一样，花在日常日志上的时间最终会得到回报。古利特说:“在一天结束的时候，打字通常只需要不到15分钟。”“我有同事告诉我，他们能够节省很多时间，因为他们能够回顾半年前的想法，或者与正在遇到你已经遇到的挑战的同事分享。我在我的团队里经常看到这种情况。有人会寻求帮助，队友会提供一个链接，说‘几个月前我也遇到了同样的问题。这是我的杂志。3月7日开始。’写一篇日记并不需要大量的时间投入，但结果却具有变革性。”
把每个人都变成客户服务代表。
古利特认为，学习同理心作为一种技能的最快途径是通过客户服务当您真正必须理解和预测使用您的软件的人的需求时。古利特引用这本书说:“Zappos的文化给了我很大的启发。传递幸福在Zappos首席执行官托尼Hseih．“客户支持的价值被灌输到公司的每个人身上——我指的是律师、开发人员、每一个人．”
早期创业公司在开始融入一种同理心、以用户为中心的精神方面处于特别有利的地位。“初创企业生命周期的早期是开始将同理心融入企业文化的最佳时机。你可以建立每个人都可以在公司发展过程中采用的规范:我们将重视用户的反馈。我们会不断地问问题来理解他们。这是很大一部分精益创业行动——走出去，倾听客户的需求。不要把这事推给一个人或一个部门。把所有人都拉进来。”
移情和寻求理解客户是通常与面向用户的角色相关的技能。但当同理心成为从开发者到设计师的使命和文化的一部分时，它便真正让公司与众不同。
对于规模较大的公司，古利特建议进行全公司范围的同理心培训，比如Brené Brown的项目敢于领先．“有几个参加布朗博士培训的工程师对此表示怀疑，”她说。“但在培训结束后，怀疑论者往往对我表示，这些培训真的值得。因为我们为脆弱的对话留出了空间，我真的相信我的整个团队在这种经历的结果是更加相互信任，并提供了更好的工作。”
倾听别人的感受。
为了采取积极主动的换位思考的方法，古利特建议做东道主听会话的另一个概念英蒂年轻的工作．古利特说:“与随意的交谈不同，倾听的过程明显与理解另一个人的推理、反应和指导原则挂钩。”“它们的设计是为了帮助你摆脱猜测别人想要什么的危险习惯，而是使用定性数据来指导你的决策。”
如果你是一个编写函数的后端工程师，很容易把人从你的工作中抽离出来。你越想去理解别人，你就越容易在编写代码时考虑他们的观点。
首先，拿一本英迪的书或把她训练上面详细说明了如何进行听力练习。然后，让同事、朋友或搭档面试你。这会帮助你对面试产生同理心。”古利特说。“当你越来越适应的时候，可以扩大范围，去采访不同职位的人，或者了解你想要解决的问题的人。”
带着深深的敬意接近你的主题。“时间是别人能给你的最宝贵的东西。如果有人决定借给你时间，你要感激不尽。”
听力开始后，把你的判断留在门外。“记住，你是来收集数据的，而不是改变想法的。只是倾听，不要感到羞耻、期待或批评，”古利特说。“我们的目标是赢得说话者的信任，了解他们的情绪和逻辑，而这些都是肤浅的。”
开发人员可以利用倾听课程来加强他们的工程实践。“假设你是一名从事人工智能工作的开发人员。你读一个行业报告这种算法经常受到人为偏见的影响，这可能会对某些人群产生巨大的负面影响。同理心可以帮助你掌控这个问题，”她说。
与其把它当成别人的责任，什么都不做，不如积极地换位思考。好奇的。听。是开放的。然后，有了定性数据，你就可以采取行动，把你解决问题的能力发挥到极致。”“这可能需要停下来考虑你是否在用一个真正具有代表性的数据样本训练你的深度学习算法，或者向你的产品负责人提出一个问题，用一个新功能解决可访问性问题。”
结论与信任裂变:同理心如何适应公司的未来
尽管科技已经在接纳同理心作为一种价值方面取得了长足进展，但古利特还是向初创公司提出了挑战，要求他们下一步将同理心作为一种技术技能来对待。
对于那些想要锻炼同理心的工程师们来说，要从打破长久以来的神话开始。投入时间创建通信构件，为您的代码的未来读者指明道路。使用移情驱动开发来主动地理解你的用户，然后解决他们的需求。最后，通过与您的团队共享日志和建立您自己对产品运行的更广泛的生态系统的认识来提升您的工作。
一旦团队和公司将同理心视为一种技能和习惯，他们就会开始经历不可思议的文化和技术收益的滚雪球效应。Goulet将这种效果称为信任裂变:来自和谐运作的团队带来的复合、加速、指数级增长的效益。
“人们总是说，最重要的事情是建立并加速团队间的信任．信任是同理心的产物。当我们试图创造一种信任的文化时，同理心是我们可以优化的”。古利特说。
信任裂变的文化为团队成员提供了一条途径，让他们发挥更多的能动性，成为领导者。“因为我们花了时间通过同理心来建立信任，我的团队总是走在前面，预测我自己的行动。我会提出一个想法，然后我团队中的某个人会说，‘你完全正确。我已经想过了。这就是我们取得的进展，’”古利特说。“这是同理心的最终目标:培养一种每个人都主动发问的文化，‘我能做些什么，让下一个来的人的情况变得更好一点吗?’”
图片来源:XtockImages / Getty Images图表由Andrea Goulet提供。
