改变从内部开始：开发者与管理者的协作

在GOTO柏林2015大会上，Skyscanner工程部高级副总裁Bryan Dove谈了如何从组织内部开始改变，开发者和管理者如何协作来了解和采用现代软件工程实践。\

InfoQ就过去10年中主要技术的发展以及它们对我们创建软件产品的方式的影响采访了他。InfoQ还问了这样的问题，就是管理者和开发者可以做些什么来探索和发现更好的协作方式，他们如何互相支持，让自己和企业取得更大的成功。\

InfoQ：在过去的10里，我们看到的新技术发展主要有哪些？\

\

Dove：过去的10年见证了技术商品化的巨大进步，以前，只有世界上最大的软件公司才拥有这样的技术。这种商品化让新公司更容易快速交付价值，以及拥有可以轻松扩展到消费互联网需求规模的技术，而且成本更低。今天，一家全新创业公司所依赖的软件栈，其中的几乎每个组件在过去的10年中都已经创建了出来，而且是作为开源项目。Hadoop/MapReduce是受Google的Map-Reduce论文所启发，然后是Yahoo的实现及后续的开源。NoSQL引擎是受Amazon的Dynamo论文所启发，例如，由Facebook构建和开源的Cassandra。还有其他常见的构建块，如Docker、Mesos、MongoDB等等。所有这些都是在过去10年中创建和发布的，已经将创建和扩展技术平台的工作量降低了一个数量级，甚至更多。\

除了软件外，我们还见证了公有云的出现，这始于2006年推出的AWS。这种巨大的变化已经将规模经济带给了大众，随着向公有云硬件经济的转型，资本部署已经从昂贵的数据中心和硬件转移，几乎全部集中到了员工身上，用以资助IP创建和支付。

InfoQ：这些发展对我们创建软件产品的方式有什么影响？\

\

Dove：类似于我上面提到的，基本的影响是创建为客户提供价值的产品比以往任何时候都更简单更快捷。以前，公司需要从头开始构建所有技术，而从头开始针对互联网规模进行构建真得很困难。今天，任何公司都可以选取一整套开源技术，以最小的努力实现庞大的规模。在Skyscanner，我是工程部的高级副总裁，我们为创业公司提供了API的免费入门版本，在github.com/skyscanner上开源了多个内部项目，我们内部也使用了多项开源技术。

InfoQ：您在演讲中举了一个例子，您做了一些很棒的工作，但没有告诉管理者。您能详细描述下发生了什么吗？您学到了什么？\

\

Dove：我提到的场景是这样的，我正在做一些我认为对公司最有利的工作。在微软工作的时候，我同SQL Server领导团队建立了内部合作关系，共同构建一些新的分析软件，用于消费互联网规模的大数据系统。我觉得自己正在做的工作，对于团队、我的业务和公司而言都是正确的。\

我犯的错误是，我没有考虑我将管理者置于了怎样的位置。他们不知道有关进展或同SQL领导团队的合作关系的细节，因为这是由我直接管理的。这让他们面临着一个风险，就是有人可能会问他们，我们的业务如何协同，而他们并不了解细节。\

关于经验教训，我得出了两个重要的结论，它们影响了我此后的思维。一是选择了过度沟通和彻底透明。以前，我在我的团队里这样做了，但现在，我在组织里所有的方向（例如，管理者、同事、团队）上都以这种方式操作。二是我现在在简化同同事和管理者的沟通上投入了更多的精力。由于我的同事和管理者每天都会从许多数据源收到大量的信息，我设法为他们提供关键事项的小标题，然后期待他们问更多信息，如果他们想的话。如果他们询问所有细节，我当然会分享，但我会等着他们问，而不是预先就同他们分享，以此帮助他们首先专注于关键事项。如果你为人们提供了标题、结论和建议，那么他们总会询问更多的细节，如果他们需要的话。在Skyscanner，我们使用“消息片段（snippet）”机制来分享信息，以防止信息过量。

InfoQ：您展示了开发者如何创建一个管理者待办事项列表，他们可以将希望管理者帮忙的事项列在上面。您能举几个在您待办事项列表上的事项作为例子吗？您的管理者是如何帮助您的？\

\

Dove：这里有一个很好的例子，就是当我领导Skype数据方面的工作时，我们需要构建一个现代化的试验系统。虽然同那些过去从事过现代试验系统研发的人交流很简单，但我需要在组织内获得更广泛的支持，以便让这项工作能得到资助，继续推进，这让我陷入了挣扎。我的管理者和我都认为这样做是正确的，因此，我请求我的管理者承担起争取恰当支持、让新的团队和服务获得批准的任务。例如，我的管理者花时间同微软其他地方的独立组织取得了联系，使用那些团队的经验作为一种外部验证。外部验证在证实新工作的合理性方面总是非常有用，因为那个团体没有以任何方式成为你的团队成果的既得利益者。时至今日，我们设想的系统已经构建出来，并成为企业内大量团队的主要试验引擎。

InfoQ：管理者如何帮助开发者更好地工作？\

\

Dove：我认为，作为一名管理者，你对工程团队的职责是围绕少数几个原则展开的。首先，我发现Daniel Pink的著作《驱动力》中的三个原则非常适合工程师——自主、专精、目的。我几乎每天都会考虑这三个原则，挑战自我，向团队授予更多的权限，让他们有更大的自主权，而不是最初那种可能让我感觉舒适的程度。在我看来，分布式自主是扩展大型团队最重要的因素，这也是Skyscanner所重视的东西。\

下一个原则是彻底透明。关于分布式自主，其中一个常见的、让人纠结的逻辑是，担心个体无法作出正确的决定。开始的时候要相信，我团队中的每个人都是聪明、能干、理智的，然后我的工作就是为他们提供他们需要的所有信息，让他们能够作出对企业而言最好的决定。任何担心某个人不能作出正确决定的迹象都应该立即引发这样一种想法，就是我没有向他们提供足够的信息，让他们能够作出最好的决定。我个人倾向于彻底透明（比如，分享一切，只要它不是违法的，而且是我分享的信息），因为这样，我就可以少做一些用于筛选同团队分享的信息的决定。现在，我的团队拥有了同我一样的情境，处于一种更有利的位置，不需要请求批准就可以作出对企业而言最好的决定。\

再下一个原则是了解细节及复杂性。工程师需要相信，他们的管理者了解他们正在做什么，并且了解那有多难。花费时间和精力获取这种知识让管理者能更好地掌握团队中正在发生的事情，同他们的工程师建立信任关系，让他们相信管理者完全能够恰当地评价他们的贡献。\

最后一个我认为对管理着至关重要的原则是公开错误。我们从失败中学到的东西远比从成功中学到的多，这已被人们反复引用重申。不过，作为一名领导者，你需要创造一个环境，人们欢迎错误，将其视为学习机会，而不是应该谴责的东西。关于这件事，我发现了一项特别有用的技术，就是把一个我在领导者岗位上所犯的错误，尽最大可能公开地向我的团队描述。然后每次我犯了错误都会重复这样做。作为一名领导者，暴露那种程度的弱点需要很大的勇气，但是如果你不愿意这样做，你怎么能期望你的团队那样做？通常，我要么会通过邮件更新、博客来做，要么会在职工会议上讨论它，分享我犯的错误，为什么那是一个错误，我学到了什么，以及我会做什么来避免再次犯同样的错误。通过这样一次又一次的反复做，强化了这样一个概念，错误正是学习的机会，有弱点，犯错误，并从中学习，不用为此不安。\

在Skyscanner，我们有辨别失败并在整个企业内分享经验教训的程序。这帮助我们创建了一种公司文化，对于什么有效、什么无效、如何从错误中学习并进一步推进，我们持开放和诚实的态度。我们将这称为“反败为胜”，这个概念基于这样一种理念，就是没有错误就无法学习，因此就无法进步。这种失败理念可能会让一些人不舒服——更不用说在真正遭遇失败时分享经验。不过，在Skyscanner，我们相信，我们需要接受失败，如果我们想继续取得成功。这样的失败案例为我们提供了重要的经验教训，让我们距离成功更近了一步；它们是影响重大决策的风险、测试和试验的结果，进一步推动我们走向成功。

InfoQ：开发者能做些什么帮助他们的老板取得成功？那如何帮到他们自己？\

\

Dove：为了帮助他们的老板取得成功，工程师有几件可以做的事。首先，了解老板的目标很重要。就像你作为工程师有目标一样，你的老板有一系列衡量其工作的目标。其次，愿意分享荣誉。Harry Truman说过，“如果你不在乎谁获得荣誉，那么你获得的成就会让你吃惊”，当你是团队的一部分时，尤其如此。如果你关注你已经交付了什么以及为用户带去的价值，那么谁获得荣誉就不重要了。一个将这些内容记在心里的工程师可以通过这样的方式帮助他的老板，比如将工程师新构建的东西的细节给老板讲解，让他们的老板在公开场合做简报，或者发送他们的邮件。他们的管理者因为向企业交付了同他们的目标一致的价值而获得认可，而团队作为一个整体就可以庆祝成功了。\

在Skyscanner，我们使用“目标和主要成果（Objectives and Key Results，缩写为OKR）”流程来确保我们的目标在整个公司内都是一致的，并以公司内任何人都容易发现的方式发布出来。这很重要，可以确保整个公司内正在开展的工作保持完全透明。

关于受访者

Bryan Dove是Skyscanner的高级副总裁。他的职责是在全球十个规模正在加速增长的办事处中领导并推动Skyscanner工程团队的发展。Bryan为Skyscanner带去了超过15年的工程领导经验。在加入Skyscanner之前，Bryan是Amazon Web Service S3的工程部总监，他在那里领导团队推出了多个面向客户的新特性，包括S3事件通知和S3跨区域复制。再之前，Bryan在微软担任多个角色，作为Skype数据工程的负责人，他建立并领导了一个全球分布式团队，构建Skype的实时大数据架构。

查看英文原文：Change from Within: Developers and Managers Working Together