如何完善自我

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

为了切实推进软件的开发和大规模构建，人们必须要审视自身所存在的盲点，并学会与人打交道（当然，其中也包括你自己）。文化的构建与技术的使用是同等重要的。相比起高绩效的工程团队，低绩效团队在生产力和质量上存在数个数量级的差别。采用何种做事方式，与具体做什么事情是同等重要的。

在 QCon 伦敦 2018 大会上，Google 的工程经理 Andy Walker 做了一次演讲，介绍了他在 Google 开发和指导团队的一些经验。InfoQ 以问答、展示、总结和文章覆盖了本次大会。

InfoQ 采访了 Walker。采访内容涉及如何构建高性能团队，以及如何为工程蓬勃发展创造条件。

InfoQ：在您看来，构建高绩效团队中的主要挑战是什么？

Andy Walker：在当前这样一个每个人都要成为英雄的时代，我们需要做到面面俱到。实际上，编写能良好工作的代码并不会使人获得成功。在你的主要工作是编写代码的期间，你只能去编写大量的代码。参与编码的人越多，你就越需要关注自己的做事方式，而非仅是关注自己在做什么。

如果你真的想要取得进步，尤其是当你和他人共事于同一家大型企业时，那么你就要学会如何与他人打交道。没有人会告诉你如何与他人打交道。我们只是希望在一定程度上弄清楚应如何取得进步。如果你打算投入一些时间，那么我认为正如 Dale Carnegie 所说的，在任何人的技术职业生涯中，85％的成功归功于和人打交道的能力，而只有 15％归结于技术技能。这多少有些耸人听闻。

我意识到自己必须去掌握所有的技能，必须弄清楚什么是适用于自己的系统。否则，我真的无法开展工作。原有的技能已经足以应付。我在 Google 花了大量时间促成人们间的互相交流。

我们出于便利考虑做了出一些事情和行为，但它们从长远来看真的对我们是不利的。事实上，我们宁愿选择向对方发送短信或电子邮件，而不是实际与他们交谈，这并不是一种真正的沟通方式。在交流想法中，语言并非十分有效，尤其是通过文本而非面对面交流的情况下。

因此，问题是我们的应激反应（fight-flight）将会如何触发。这常常归结为如何摸清楚我们日常生活中那些习以为常的行为。这些行为循环模式非常难以摸清，因为甚至我们自身都不清楚具体的内容。

在你的脑海中萦绕着一些盲点。这些盲点在你看来一切正常，但事实上并非如此。一旦你着手去检查自身的盲点所在，就可以对他人做出更好的反应，了解人们对你的反应情况，并知道如何更好地去处理这些盲点。

InfoQ：我们应如何处理自身的不足？

Walker：从了解盲点着手。我们需要去了解一些模型，知悉为什么人们会具有这些盲点，并认识到大脑中的某些部分对思维能力具有超出我们认识之外的强大影响力。

其中一个有用的模型就是“三重脑”（Triune Brain）模型，它表示了人们的意识是如何发展的。即在我们大脑的意识部分之下，存在着两个动物层，大致可看成是一条鳄鱼（爬虫脑）和一匹马（哺乳动物脑）。大脑的动物部分分别具有一些特定的动机。例如，爬虫脑关注的是食物、安全、温暖和如何生成小爬虫等生物技能。哺乳动物脑关注的是社会接受度和社会地位等。血液从大脑的动物部分流向意识部分。大脑的动物部分具有对不满意想法的否决权，并具有提升想法去符合目标的能力。因此，我们可能在并未意识到的情况下，使用动物大脑去描述一些情境化事物。广告商对此应深有体会。

举个例子，对于一名 45 岁的法拉利销售商，如果爬虫脑认为购买这款车会有机会制造更多的小爬虫，那么这款车是否很酷并不重要。然后人们突然对这个思路产生了大量赞同。另一方面，如果我走到一座高楼的边缘并想跳下去，那么爬虫脑就会给出反对意见，并切断向大脑相应部分的供血。这也发生在“迎难而上还是逃走”（fight-flight）的应激反应期间，因为爬虫脑将血液转移给了它认为与生存条件更相关的肌肉。这实际上阻止了你的理性大脑。如果你想建立一种健康的人际关系，那么就不应让人们进入“迎难而上”（fight）情境。

InfoQ：我们应如何为工程的蓬勃发展创造条件？

Walker： 我们需要接受，所建立的文化与所使用的技术是同等重要的。每个人都应该能够为此做出贡献，这有助于我们从各种各样的想法和观点中得到一个最佳的解决方案。要做到这一点，我们需要了解大局，从中寻找我们未预先具备的技能和知识。从我们自身着手，理解自身的错误，并以此作为理解同行和用户的一条途径。然后理解如何让人们合力做事，而非相互牵制。其中领导者需要发挥非常重要的作用，应采取一种服务型的领导模式，去帮助团队做事，而非颐指气使。领导者的工作在于帮助人们理解做事的原因所在，然后帮助每个人改进企业的运作方式。我很少具体指导他人如何编写一段代码。

这里不仅仅涉及软件的编写，还包括工作环境、决策能力、委派、从错误中学习、想法的分享和发展等。相比起高绩效工程团队，低绩效工程团队在生产力和质量上存在着数个数量级的差异。如果我们想要构建超越自我的企业规模，就需要采纳这样的旅程。

下面给出一些例子：

• 一个有效的做法是，让人们了解用电子邮件为交流工具的效果很差。一条强规则是，在疲倦、脾气暴躁或是对电子邮件有情绪时，绝对不应回复电子邮件。我们可能会出写出一封突兀的随笔，并导致误解。最好与人当面交谈，理解人们的意思，而不是马上回应邮件。无论如何，邮件不可能表达出你的感受。
• 鼓励人们多进行面对面的交流。人们身处同一个房间所建立的融洽关系，要比通过电子邮件与另一端的人交流更易于受到重视。
• 鼓励人们对积极行为表示出公开认可。研究表明，如果你对他人的努力表示感谢或者欣赏，将来人们帮助你的可能性会增加两倍。你认可到积极行为越多，你所能看到的积极行为也就越多。
• 告诉别人可以对我提出否定意见，也可以互相提出。每个人都应该知道我们做事的原因，想要解决什么问题。如果我不能解释原因，那么我们可能做错了什么。另外，我也可能是错的。我愿意当着他人的面承认这一点。
• 关注重要之处。我告诉人们，让他们自己选择如何支配时间。如果一个会议毫无价值，那么大可不必参加。通常，会议数量的增长是资源消耗的主要源头。减少会议，去做更多有用的事情。
• 减少中断。这样你可以让人们进入一种动起来的状态。这一灵感来自多年前 Joel Spolsky 的一篇关于场景转换方面的文章。
• 每个人都必须能够成功和成长。这里我借用 Dan Pink 关于动机的一次演讲，作为对人们的一种简单试金石测试。即如果人们感觉不到自主感、目的或学习 / 成长的机会，那么他们就不会参与其中。
• 关注结果，而非可交付结果。我们常会迷失于功能列表和错误之中，而无法看清大局。我们需要建立一个环境，使团队中的所有人都有所顿悟，并创造卓越。如果成功被视为“交付 X 特征”，那么我们忽略了我们正试图解决的问题。
• 关注结果，而非一种唯一的方法。条条大路通罗马。我们深陷于框架、语言、设计模式的圣战中……随你怎么说。我们所耗费的精力，无助于我们试图去解决的真实问题。最终，人们还是要诉诸于软件工程。这时，人们会发现关注目的的重要性。

查看英文原文： Dealing With the Broken Human Machine