本次访谈中，麦肯锡的 Vito Di Leo 采访了荷兰 ING 银行 IT 基础设施部门负责人 René Visser。他向我们解释了为什么银行会选择打造敏捷基础设施，这项举措带来了什么样的转型，以及银行是如何攻破“拦路虎”的。

Q1：为什么荷兰 ING 银行会进行 IT 基础架构的转型？

A1：在 ING 内部，无论是业务还是应用交付，都无一不采用了敏捷方法。但IT基础设施在这方面却乏善可陈，因此运营效率较低。

举例来说，一旦开发人员要交付新的应用程序，他们首先要联系基础设施团队，建立虚拟化基础设施。接下来的每一步，无论是程序交付，还是运营和维护，都会由于种种原因触碰到基础设施，导致了大量的运营需求和服务请求。这是我们当时亟需解决的问题。

同时，IT 部门的其他团队也会令该问题愈加复杂。开发团队构建的应用程序并不总是易于运营。因此，我们必须做更多的工作才能避免故障发生。

Q2：敏捷转型是如何解决这些问题的？

A2：基础设施的敏捷转型需要双管齐下。一方面，它意味着将基础设施看作是一个产品，不仅有核心基础设施，还有全方位的运营方式。如此一来，应用程序的开发人员就可以根据自己的计划自主操作。另一方面，它意味着改变我们提供产品化服务的方式，这又回到了软件开发。

这样的转型是完全可能实现的，因为我们的基础设施团队主要提供软件，而非硬件，而敏捷方法就恰好适用于软件开发。当我还在应用程序部门的时候，我就学会了如何应用敏捷方法，这已经成为了在基础设施之外 IT 管理的主流方法。如何让基础设施与 IT 其他团队的工作方式保持协调至关重要。

如果我们能够让应用程序团队自己部署程序并维护底层基础设施，那么我们将更接近 DevOps模型，并可以更快地采用云服务，这恰恰是我们 IT 战略的两个核心要素。

Q3：启动这样的转型，你的团队当时知道前路挑战重重吗？

A3：我们确实考虑到转型会让一些人感到不安。IT 基础架构的目的发生了转变，从之前主要构建和运营个性化解决方案，转变为为开发人员创建工具，帮助他们自行部署标准化基础架构。

虽然我们有一些工程人才，但不是每个人都拥有高超的技能或热衷工程工作，我们还需要避免各职能各自为政，让大家能够跨职能运作。

应用程序团队作为基础设施的“消费者”，必须适应自助服务。虽然他们是 DevOps 团队，但他们中的许多人仍然需要了解基础设施的操作。

Q4：你是如何让大家齐心协力推动转型的？

A4：转型并不容易，但我们也知道，改变对于员工也大有裨益。在新架构中，我们将简化流程，减少转手环节，并更多致力于IT的整体交付和敏捷性。此外，新的组织和角色也将创造新的机会和职业道路。

接下来的几个月中，我们定期与员工进行开诚布公的沟通。我经常邀请团队的同事和我进行交流，有时我们就站在办公室的咖啡机旁随意的交谈。

这样的“咖啡角”我们每周举行一到两次。大家可以直截了当地向我提问，我也尽我所能地回答。有的时候很多人来参加这个活动，我们不得不换一个能容下所有人的开放空间。

另外，我还花了很多时间与应用程序团队的主管说明新的愿景，并听取他们的想法，从而帮我们决定基础设施应该提供哪些服务，以及如何提供这些服务。

Q5：在此之后你们还采取了哪些举措？

A5：我们对基础设施部门的组织架构进行了两个关键调整，重新设计了每个团队的角色。

第一，我们从以服务请求为基础的单职能团队变成了以开发基础设施产品和服务为目标的跨职能工程小组。例如，Linux 小分队设计一个兼容的操作系统和工具，帮助应用程序设计团队可以次日交付的 APP。我们还设立了特别小组来为专业基础设施技术（如大型主机或数据湖）开发产品。

第二，我们大大精简了职能岗位，只设立了约 10 个工程岗位。我们取消了项目，服务和业务关系管理等职能。如今，最常见的职能是工程师，产品负责人，小分队负责人，敏捷教练和架构师。这两个转变大大简化了组织，缩减了规模。

Q6：基础设施团队的领导层是如何为每个职能和敏捷小组选择合适的人才的？

A6：在新组织中，我们要求每个人最多只能申请三个岗位，申请收到之后，我们投入了大量精力评估人员。这是 ING 荷兰在重组过程中采用的标准方法。

我们认为要推出新的产品，需要团队拥有新的态度和软件工程技能。我们把这个标准说得很清楚，很早就发布了新的岗位要求，并向所有人公开。

不仅如此，我们还通过一套非常严谨的流程来评估人员的工程技能和思维模式。在 ING, 我们称之为“橙色代码”。除此之外，我们还要求申请者参加编程考试。综合这些举措，我们充分了解了每个人的意愿和能力能否在新组织中取得成功。

每个申请者都至少经历过两轮面试，一次是评估技术专业知识，另一次则评估敏捷思维和工作方式。在短短十周内，我们就面试了数百名员工，因为我们希望尽可能为他们减少不确定性。

Q7：这项工作听起来非常艰巨，那是谁负责执行呢？

A7：对于我们来说，面试所有员工的工作量确实是超负荷的，以至于到后来我要求应用程序团队的同事也来帮忙。

幸运的是，很多的人愿意挺身而出。让应用程序团队的主管们来参与面试，不仅减轻了我们的负担，也让两个团队凝聚在一起，双方更好地了解将来的合作方式。

这也是非常有价值的，因为我们不仅要改变基础设施的组织架构，还要改变基础设施和开发团队之间的协作模式。

Q8：重组设计完成后，新结构是如何付诸实践的？

A8：我们力求创新，为了让新的小组凝聚在一起，我们让同一组的成员戴上相同颜色的帽子，使得他们能够找到彼此进行面对面交谈。

仅在一天之内，我们就从旧架构切换到新架构。另外，我们还要求新的产品负责人重新设计座位区域，以便更好地鼓励小组成员进行互动。

为了能够顺利转型，我们建立了临时工作组来执行 IT 服务请求，以便新的团队有时间自动化基础设施服务并为开发人员建立新工具。

因为临时工作组终有一天会被解散，我们使用了外部承包商。自2016 年 11 月新的基础设施组织架构启动以来，我们已经解散了50％以上的临时工作组。

Q9：敏捷小组成功的秘诀是什么？

A9：我们用新兵训练营的方式来管理敏捷小组。

起初，我们给每个小组设定了目标，然后他们会不断精进自己的目标。在敏捷教练的帮助下，他们还共同开发了第一个产品路线图和第一批工作清单。为了让新的小组保持工作节奏，教练会帮助他们协调与其他小组的步调，并进行个人辅导，帮助他们实现新目标。

同时，我认为最好的学习方法就是身体力行。放手去做，不要害怕犯错误。犯了错误，我们也不会慌张，而是争取从每一个错误中吸取教训，并在下次更上一层楼。

Q10：随着时间的推移，基础设施各个小组现在发展得如何？

A10：敏捷小组的发展情况不尽相同，有些小组从一开始就做得很好，但也有一些人难以适应敏捷方法，没有找到合适的工作节奏。

我们对每个小组的发展前景有着执着的目标，因此，我们也尝试用不同的方法和角度来处理事情，比如更换敏捷教练。

我们予以团队很大的空间和自由，让他们找到自己的发展方式。一年之后，大多数团队都状态良好。回想起来，我认为我们应该在一开始就引导每个小组采用相同的工作方法。

起初，教练们有很大的自由度来决定每个小组需要什么样的辅导，而有些教练会更多地关注个人沟通或工作方式。半年后，一些团队在敏捷方法上已经小有成效，而有些团队仍在努力解决问题。

因此，转型领导团队决定让所有辅导工作变得更加统一。我们希望敏捷小组采用 DevOps 的方法，并形成更加一致的工作方式。

Q11：ING 的应用程序开发人员对新的基础设施模型接受程度如何？

A11：表现最好的敏捷小组会尝试了解开发人员的处境，并花时间向他们解释新的工具，让开发团队能够更好地使用新的自助服务工具。

但有些小组则只是告诉开发团队他们有什么工具，而这些工具是他们仅有的选择，这就不是一个很好的沟通方法。

总的来说，开发团队很快就接受了自助服务模式。如此一来，他们可以更快，更灵活地工作。举个例子，开发人员可以使用自助服务工具随时修补应用程序的基础设施。

Q12：敏捷转型对于IT环境的修复力有什么影响?

A12：开发人员的工作是开发和部署性能良好的应用程序，而最终使应用程序顺利运行的责任却落到了基础设施团队头上。因此，应用程序团队在开发时并不会考虑程序的后期运维。

比方说，我们可能开发出一个应用程序，如果基础设施中断2毫秒，它就会崩溃，但是我们都知道基础设施是无法完全阻止中断的。

现在，我们的基础设施变得更加稳定，不仅因为基础设施得到了提升，应用交付团队也功不可没。正所谓一个巴掌拍不响，跨部门的通力合作大大提高了我们IT 环境的弹性。全天可用的基础设施固然重要，一个良好的应用程序架构也不可或缺。

我们在荷兰的首席信息官 Peter Jacobs 也是敏捷转型的大力支持者。他说，如果应用程序崩溃，那么开发人员就要修复它们，不能只寄望于基础设施防止出错。

基于这个原则，我们要求应用团队对程序的运维负责，从而系统性地减少了一级和二级集中支持功能。开发团队领会了这个宗旨后，也让应用程序变得更加稳定了。短短数月，荷兰 ING 的整个 IT 环境变得比以往更加强大。

Q13：整个 IT 团队还取得了哪些进步？

A13：我们的开发团队现在拥有了运营应用程序的工具，也负起了运营维护基础设施的责任。这与云运营模式非常相似。我们的开发团队也因此获得了在云运营模式下管理基础设施的经验，未来要采用云技术也就变得更加容易和自然了。

从技术角度来看，我们也向前迈进了一步。例如，我们升级了数据中心，并改善了连接通道，使我们的环境更符合云架构的要求。

此外，敏捷转型也改善了大多数运营领域。我们大大减少了计划中断、基础设施引起的事故和周末加班。

现在，我们能够在常规工作时间内完成所有工作，效率大幅提升。我们在减少用人数量的情况下，通过工程设计和自动化提高了交付水平。

Q14：对于其他正在进行相似转型的公司，您有什么建议？

A14：首先，不要只尝试修复基础设施方面的问题。你肯定需要应用程序团队从一而终地参与进来。这意味着在转型设计阶段，尽早与他们互动，从他们的反馈中吸取建议，并让他们参与到交付过程中来。

当初战告捷时，也要与他们分享这个好消息。比方说，在白天维护软件这种有违常理的事竟然实现了，你们就应该好好庆祝一番。