跨越业务与技术间的鸿沟：与 UBS、LBG 和 ITV 人士的对话

在今年的 DevOps Enterprise Summit 伦敦大会召开之前，InfoQ 主办了一次由 IT Revolution 赞助的视频研讨会。研讨会特邀了三位 DevOps Enterprise Summit 的演讲者，分别是： UBS 的 Jelena Laketic 、 Lloyds Banking Group 的 Mark Howell 和 ITV 的 Tom Clark 。下面给出研讨会发言情况的总结。

InfoQ： Target 、 Alaska Air 和 Domino’s Pizza 等一些组织站出来宣称自己是一家科技企业。各位是否认为自身所在的企业也是科技企业。

Mark Howell：我们（即 UBS）虽然以英国零售银行的品牌而闻名，但却聚焦于技术。企业近期更多地聚焦于工程品牌。在刚刚完成的战略重组中，企业具有了一个以工程为品牌的工程功能。在当前的环境下，技术正在吞噬世界，我们必须全力以赴地保持领先。对于 Monzo 和 Facebook 等企业而言，我们所具有的 250 年品牌历史毫无意义，它们想要从我们这里分一杯羹。

Jelena Laketic：瑞士已有多家银行实现了相当程度的数字化，我们（即 Lloyds Banking Group）一直在努力做得比同行更好，保持在全球业务中的领先地位。当前，技术是我们唯一的依靠方式。对于我这样一位软件工程师当然如此，但是能看到技术变得如此重要，这依然是一件十分美妙的事情。为了在未来占有一席之地，即便是那些并不被人们看成是科技企业的公司，也必须成为一家技术企业。

Tom Clark：ITV 很早就经历了金融危机。对我们来说，那是一个非常困难的时期。因为在当时，我们 95％的收入来自于电视广告。金融危机期间，那些打广告的企业收紧了预算，因此我们不得不做出一些非常艰难的决定，即部分裁减和缩支。为了挽救公司，我们的确削减了系统中的一些松懈和不实之处。现在我们挺了过来，比以往任何时候都更强大。由于采取了一些精简措施，企业得以在同等收入下增大了利润。但我认为，我们在这个过程所失去的是那些松懈之处，以及那些可以停下脚步考虑未来五年发展的空间。如果你不做自我反省，那么别人就会令你反省。

自 1955 年成立以来，ITV 一直是一家广受欢迎的商业广播公司和制作企业。但是我在 ITV 工作期间，Netflix 已经从一家 DVD 提供商成长为世界上最大的媒体制作商和流媒体服务公司之一。ITV 存在很多遗留系统，很多业务正在慢慢消亡，但这些新兴技术企业却没有这样的问题。我认为这就是为什么我们要谈论 DevOps、谈论敏捷性的原因所在。我们谈论这些技术的好处在于，这意味着当一些新兴技术企业出现时，我们实际上可以推动我们的业务，并说：“好吧，我们需要转向，我们需要这样做，我们需要更好地做到这一点“。

InfoQ：各位在时间和预算上是否达成了业务所需的承诺，或是正在推进中？

Howell：我们是一家大型组织，我们力图转向于此。我们正试图为经营权继续提供资金。因此，我们将在某个地区投资部分资金、获取部分价值，并收益更多的资金。在这样的推进过程中，我们需要对第一笔用于做实事的资金有一点信心，但在投资中必须确保这笔资金将为企业带来价值。这对企业来说是真实的，因为它要回答“这究竟对我有什么用？”的问题。最终，一旦这个问题得到解答，将会在组织中树立可信度和股票价值，最终为企业提供运营许可并继续推进。

Laketic：在每一天结束时，人们都希望能看到自身从中受益。我们会随着企业自身的发展而建立自己的信誉。我们受到信任，是因为我们提供的业务别无二家。之后，我们证明了我们可以实际完成交付，并且我们就是人们所需要的技术专家。我们一直在从事黑客马拉松的业务，现在人们对我们的看法不再是我们要休息两天，而是希望我们有更多的休息时间。“哦，我们支付了两天的工作，竟然收获了这么多？”

InfoQ：各位有没有碰上一些业务尚未真正开展、但的确具有挑战性的事情？

Laketic：有时在开始快速推进之前，你必须要将脚步放得非常慢。如果这样做，你将会带领更多人员加入，使他们相信你的前进目标。在向人们展示我们的长期事业之前，我很高兴能有一段时间放慢自己的脚步。

Clark：我认为“20-60-20”就是这样的事情。当你想要做出改变时，有 20% 的人员完全会直接加入你的行列。这些人将真正喜欢你的主意，真正想要支持它。中间的 60％会保存沉默的。他们想要当骑墙派，静观事情如何发展。此外还有 20% 的人非常抵触，他们立场坚定地反对你，不想要做出改变，因为他们对新事物充满恐惧。通常，人们总想要聚焦于抵制变革、充斥杂音的 20%。但我认为，我们是否可以做通中间 60% 的工作，这样就有 80％的人支持你。对于拖后腿的 20%，要么争取到他们，要就干脆放弃他们。

Howell： 我们想要在组织内发展的文化就是这样的事情，它可归为组织内的人员和信仰体系，包括我们与合作伙伴打交道的方式。我们一直致力于建立人与人之间的关系，并允许人们以不同的方式获得许可。从那时起，我们逐渐看到了改变心态和以身作则的真正优点所在，因为人们喜欢看到一些加入改变和以不同方式做事的实例。没有人喜欢繁文缛节，没有人喜欢挫败感，这最终归结为对获得许可的要求。企业不再是一个孤立（siloed）的组织。我们希望人们能直接相互交流，最终将合适的人员纳入到团队构建中，以便他们能够以更高效和快捷的方式实现改进。

InfoQ： 按 Simon Sinek 的说法，各位是否具有一些文化资产、组织层面的“为什么”问题，或是对组织目的的描述？

Howell： 作为一家银行，从组织层面看，我们的使命就是为英国的繁荣发展提供帮助。当我为企业的 18000 名员工介绍 DevOps 时，我会使用一些已定义的关键信息，并给出这些信息在 Lloyds Banking Group 中的具体含义。我们知道，如果你提问十个人，那么你会得到十二种定义。所以我将对话围绕着“为什么”、“如何做”以及“是什么”的框架展开。其中，“为什么”相关问题是希望帮助员工安全、可靠、快速地交付技术和改进。然后据此驱动“如何做”以及“是什么”的问题，即我们将如何做到这一点，以及我们将如何实现它。我们正在建立一个标准，以便我们能同舟共济时，可对我多年来开发的这些神秘事务具有同样的观点，并具有可识别的内容。

Clark：回顾历史，技术只是推动者和成本中心。现在我们按 ITV 的理念共事，同时技术本身也在努力发展出自身的内部文化。ITV 曾有五个业务部门，在各个业务部门间技术方法是相当孤立（Siloed）的，刻意的且不适当的孤立。在部门内部非常好的一件事情是，技术与我们的业务非常接近，因为各部门看到了比以往更多的技术。当前我们面临的挑战是，我们的技术结构终究还是略显分散。现在，我们需要确保各部门能保持一致，同时也能与业务保持一致，这需要一种矩阵式管理。这种结构曾经颇受非议，现在似乎已经完全重新轮回，我们正在研究如何按适合我们业务部门和技术功能的方式，将这种矩阵结构应用于 21 世纪。

Laketic：我们花了一段时间才掌握了这种矩阵结构。我已经看到，随着时间的推移，我们尝试首先采用更多的池式 IT 管理方式将 IT 与业务联系起来。将技术用于整个企业中的同时，朝着目标努力，这种组合是最有效的。

InfoQ：对于了解客户想要交付什么，以及客户需要的具体内容，为缩短这一过程的时间，各位采取了哪些做法？

Laketic：就我们而言，我会将所有人、业务代表和技术代表召集在一起，让大家畅所欲言开展讨论，提出想法，确定实现想法所需的努力。 如果你将所有人召集在一起，那么不仅实现了一次交流，而且每一方都可以告诉对方自己想要的是什么，以及如何实现这一目标。

Howell： 我们的组织遍布全球，我们使用离岸供应商，因此让人们聚在同一房间并不容易。所以我们一直在做的是，围绕价值流观察我们的可交付产品。这里并非是项目价值流和程序价值流，而是抵押价值流究竟是什么（例如，我们出售的产品）。然后我们尽可能让业务贴近交付，这可使我们具有抵押价值流的产品负责人，由其定义和优先排序，进而与工程负责人开展合作，在敏捷的场景中切实率先解决最近积压（backlog）问题。我们使用 MVP 方法，将每隔一周做一次 Sprint，交付一些商业价值，让各个角色间更紧密地相互合作。

Clark：从历史上看，我们曾存在许多不同的孤岛（silo）。CTO 在大约四五年前开始了一项大规模的现代化计划，通过产品团队从上到下转向敏捷，该计划现在即将结束。我们为团队提供了一个空间，如播客安排，人才支付或灯光，并说：“这里是产品负责人”。产品负责人有时是来自我们的业务人员，有时来自于技术人员。各团队像小型创业公司一样运营，并与整个投资组合保持一致的路线图，但管理着他们自己的路线图和自己的积压工作（backlog），在整体上作为一个自给自足的单位运作。从历史上看，全部内容都有一个非常大的共享基础架构。如果有人想要做出更改，那么他必须做一些协调，包括必须去 CAB、必须得到许可，以及必须做出提问。我在设计通用平台时，所做的一件关键事情就是我们的云敏捷托管通用平台，其中加入减少爆炸半径的理念。因此，产品团队在通用平台上部署一个实例。该实例是非常通用的，而非共享的。每个产品团队都具有自己的独立实例。这意味着如果你是产品负责人，并且你想在星期五下午发布一个版本，如果你的团队已经参与其中并出现了错误，那么唯一受到影响的是托管在实例中的特定产品。

InfoQ：从业务与 IT 如何协同工作的角度看，各位认为未来几年中针对 DevOps 的运营模式将如何发展？

Clark：将不会再有 DevOps 功能。我认为，我所提到的这些产品团队对我来所就是 DevOps 的演变。DevOps 是与人们的工作并存的。我认为就像我之前提到的那样，ITV 已经实现了这样的机制。在线业务、我们的产品团队以及技术产品团队在历史上曾是组织的组成部分，并且我认为这种趋势将会持续下去。人们将在同一功能中共事，成为技术人员、开发人员、平台工程等。DevOps 一词将成为常规业务。

Howell：对我来说，DevOps 是一个模糊地带。我认为我们并不会有专门的运营团队或专门的开发团队，我们拥有的是产品团队和功能团队中的所有人员。实际来自开发组织的工程师将不断发展，并具有更多的运营思维。我认为我们做得很好的一件事情，就是对成长过程中的问题、变革和事件管理。我们仍然会具有这些学科，他们仍然非常重要。但在我看来，同样重要的还有要确保开发和运维人员真正成为一个团队。我和 Tom Clark 的观点一致，我不会再看到我们继续谈论 DevOps 一词了。

Latekic：实际上我并不喜欢使用定义和术语，我真的不在乎我们如何称呼 DevOps。如果我们称 DevOps 为其它名字，对我来说无关紧要。回顾历史，我们在并不知道一些工作可称为 DevOps 的情况下完成了这些工作。因此对我而言，DevOps 只是在逻辑上得以推进。

研讨会的完整视频可在线观看。

查看英文原文： Spanning the Business and Technology Divide: A Talk With UBS, LBG and ITV