BBC如何使用团队拓扑构建内部核心平台?

22-03-25 banq

在软件工程方面,我们的愿景是让 BBC 以其工程和内容而闻名。为此,我们必须进一步发展 BBC 作为产品和技术公司的理念。
我们的资产中有数百个微服务,所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作之间取得平衡。
我们希望 BBC 以其工程质量和内容质量而闻名。
 

背景
BBC 网站由多种数字服务组成,包括iPlayerSoundsNewsSport
每项服务本身就是一项主要服务——每周有数百万次访问——而且它们在几年内相互独立发展。
这反映在组织的形成方式上——每个数字服务都由不同的部门负责。

服务之间存在不匹配的技术和重复。许多功能尽管在概念上相似,但被多次实施——总维护成本也支付了多次。跨领域能力——例如个性化和分析——是每个产品开发团队必须自己解决的主要任务。
 

WebCore
这是一项名为 WebCore 的更广泛计划,WebCore 是重新构想 BBC Online 并为所有数字服务创建单一网站的战略的一部分。
对单一技术集进行标准化,建立共享的 "水平 "能力,并在团队之间共享商品组件--将使BBC更好地利用技术,为观众建立更多的创新功能。
WebCore 既是对组织的重构,也是对技术的重新实现。
高度自治对于高绩效的产品开发团队至关重要。之前解耦的技术栈让自治更容易实现,所以 WebCore 策略迫使我们思考如何平衡自治与标准化技术。
 

跨越组合变得困难
BBC 数字产品的演变反映在与数字服务所有权相一致的内部部门结构中。
跨越这些传统的部门界限例如​​,改进将新发布的内容呈现给观众所需的时间是长而困难的。

一个早期的改革办法是创建一个新的内部部门,称为核心服务——一个不以提供面向受众的服务为导向的部门(核心平台部门)。
WebCore 平台是一个内部产品,由一组通用组件(系统、服务和框架)组成,客户是内部产品开发团队。(核心平台共享给其他产品线,属于共享核心)
这些团队不是将成功建立在观众参与度上,而是努力在整个组织中提升并为依赖平台的租户团队提供支持。

随着时间的推移,使用该平台的团队数量不断增加。
不久之后,超过 100 名工程师正在创建组件——跟踪正在制造的组件变得更加困难。
早期“零重复”的高标准正在制造摩擦:团队如何快速行动、迭代并保持好奇而不造成重复?

答案是对技术债务形成一种更务实的心态:技术债务并不总是坏的,零债务带来高成本。
就像金融债务一样,技术债务并不总是坏事。
如果债务不被追踪、变得过大或无法追究债务人的责任,债务就会成为问题。
 
这突出了一个重要原则:必须将控制权从核心平台部门转回给其使用方:租户团队。
 
使用共享技术已经在新的核心平台团队中产生一种被剥夺权力的感觉。
当产品开发团队习惯于拥有和控制其整个技术堆栈时,转向依赖他人的情况可能会让人不舒服。
然而,从操作系统到框架,没有一个团队是从零开始编写所有东西的。
 

团队拓扑——交互模式
在早期阶段,我们倾向于将支持视为“核心团队和租户用户团队之间的协作”。
这在早期是合适的——一切对每个人来说都是新的,互动团队的数量是可控的。然而,随着贡献组件的团队数量的增加,我们现在对我们可用的团队之间的一系列交互模式有了更细致的了解。

协作:这是一个团队共享相同任务的时候。当多个团队在这种模式下互动时,它可能看起来像是一个跨团队的小队,他们整天、每一天、在同一个任务上工作很长时间。非常适合开拓

合作/促进:这看起来像是一种支持模式;我们有团队可以在需要时寻求帮助的机制。它也可以是关于鼓励跨社区支持,无论是来自主题专家还是来自更广泛的产品开发社区。非常适合定居

系统化 - 这是关于消除人工干预。它可以是文件、流程、工具或用户界面。对town planning来说是完美的。
协作是昂贵的,但当新的领域被打破时是理想的。它加速了租户和核心平台团队之间的反馈,使平台中的差距得以迅速解决。然而,它本质上是一种人工干预,而且不能扩展。

系统化是指消除人工干预,是平台的地平线目标。当模式被证明了,那么后面的团队就可以踏上这条路了。
黄金路径工具可以用来加速团队,使他们保持在已知的良好路径的护栏内。
在这些护栏的范围内,租户团队有高度的自主权,可以在最小的阻碍下向他们的受众提供服务。

合作和促进是这两者之间的灰色中间地带。虽然工具和程序可以减轻一些负担,但这始终是可能需要的。
寻求帮助的个人、人员流动等总是会产生这样的需求。
 

经验教训
这并不总是美好的--但这是一个迷人的旅程,我想很多组织都会踏上这个旅程。

围绕正确的任务进行组织--无论是团队还是部门结构,这都是创造一致性和团体凝聚力的主要方式。如果它不正确,结果也不会是这样。

优化,不要理想化--有很多人分享和贡献于同一个代码库,需要有一些规则来保持每个人的正直和狭隘。
在人与人之间,尽量把这些作为经验法则。随着时间的推移,使用仪表板和工具来指导人类,并让机器人来创造执行。

一起工作,但要深思熟虑--分享技术将需要工程师与其他工程师跨越传统的组织边界合作。这很容易让人不知所措,所以要根据情况选择正确的互动模式。可能没有一个单一的最佳互动模式,所以需要一个混合的方法。

从平台的角度来看,关键是要努力摆脱困境,让租户团队不受阻碍地交付。这意味着要坚持不懈地寻找并消除开发生命周期中平台所带来的障碍。这可能意味着为租户团队提供控制--配置、工具、用户界面等,但也可能意味着同意并执行某些标准。

自主性不是银弹--如果团队之间没有一致性,自主性会滋生低效率和低价值的变化。统一可以通过组织有明确目的的人和团队来创造。它也可以通过一个有意见的平台来创造--这个平台使做正确的事更容易,做错误的事更难。在这些约束条件下,有很多高度团队自主的空间。

WebCore的最终成功将随着时间的推移而得到衡量:
在未来的十年里,优秀和创新的数字产品将为BBC的观众提供信息、教育和娱乐。这种组织结构的重构是在优化标准化的商品组件和创新功能所需的自主权之间的一种权衡。
改变是困难的。当人类参与到像产品开发这样复杂的、创造性的和技术性的工作中时,保持对大局的关注可能是一个挑战。但是,通过认识到一个组织是一个系统--尽管是一个非常复杂的系统--我们就可以运用杠杆来引导有效的变革。