写点什么

MOO 如何改造 Spotify 模型

作者:Claire Donald

2019 年 5 月 27 日

MOO如何改造Spotify模型

本文要点


  • 敏捷并非真正的目标,快速对变化做出反应,从而支持企业的目标才是真正的目标

  • 你不能通过复制别人的组织设计来模仿其文化

  • Spotify 模型或许是一个很好的开端,但是你需要改造它,以使其符合你的需求

  • Spotify 模型的假设是你有一个现代化的基于微服务的架构,从而使自治化的团队成为可能。如果你没有这种架构,那么 Spotify 可能不起作用。

  • 你需要预见到你需要改造,并且需要计划一个应对改变的应急方法


我于 2018 年 4 月加入 MOO,当时它正基于 Spotify 模型改造其技术和产品所对应的组织结构。去年我们开始改进最初的设计,并最终使其符合我们当时的需求。


MOO 是一家在线打印和设计公司,创办于 2006 年。MOO 对于伟大的设计和使世界不同充满激情。我们让伟大的设计到每个人的手中,到每个地方,我们聚焦于帮助客户创造、分享和提升他们的职业特性。技术是我们所有工作的基础。所以,我们必须要使组织结构有效,才能支撑我们的业务愿望。这非常关键。


为什么 MOO 决定实施 Spotify 模型


2015 年,MOO 计划发展和扩大公司,包括技术团队。由于技术和产品团队已经有 50 人了,我们不得不改进我们的结构,以确保我们能够适应公司不断变化的需求。那时,我们已经在使用精益和敏捷实践,而且想要更多地进行这些实践,从而让我们能够保持灵活和快速改变。


在被征询意见时,团队和公司人员提到了以下问题:


  • “我们人员配备不对”

  • “版本发布令人非常痛苦”

  • “添加新的实际产品比较困难”

  • “跨团队协作比较困难”

  • “我们做的并不敏捷”

  • “从单体结构转变为服务并不一定总能按需得以优先处理”

  • “我们担心基础设施、网络和安全问题”


Spotify 模型方法最先由我们的首席技术官引入,他具有该模型的第一手经验,并且认识 Spotify 公司的敏捷教练。那时,Spotify 模型被我们认为是“新常态”,也是令人渴望的目标方法,并且它看似能够与我们的文化、价值观和原则良好契合。我们需要多学科的产品团队,这些团队需要能够:


  • 相对而言比较自动化

  • 频繁和安全地发布版本

  • 展开研究和“从生活中学习”

  • 掌控他们生产的产品

  • 继续检查和改善其工作方法

  • 构建能够快速扩展的产品

  • 构建服务和工具,这些服务和工具能够让我们在几天或几周之内(而不是几个月)把想法变成 MVP


因此,Spotify 模型看似是和我们很配!


我们瞄向的目标和结果


我们的目标是确保技术和产品团队能够和公司一道,实现 MOO 的战略目标,推出新的功能和服务,以及新的产品。MOO 所做的一切都基于技术,从电商体验到打印和完成订单都是如此。MOO 成功的关键在于能够快速地改造技术以使其符合业务的需求。敏捷并不是我们的目标。


我们如何实施 Spotify 模型


为了激发技术和产品团队中的组织设计和工作方式,我们首先将自己分成部落、分队、分会、工会,就像 Spotify 描述的那样。


我们将自己分成 4 个不同的部落,这 4 个部落拥有统一的一套产品和服务。每个部落拥有 2-4 个跨学科班组(我们选择不将团队的名字从班组改为分队!)。这些班组是稳定的,而且是围绕着统一的产品和服务掌控制而设置的,而且他们还得到了来自敏捷交付教练、产品经理和体验设计师的支持。分会总监为每个学科提供直线管理,同时,围绕着团队和个人各自所属的课题我们会设置不同的工会。


正确进行人员配置


我们希望每个班组都是多学科的,并且拥有使其能够自动化和独立运作的所有技能。除了引入稳定团队的概念以外,我们还引入了新的角色和职业路径,并且加强了我们现有的一些功能。


  • 引入技术产品负责人这一角色和职业路径。我们有些班组主要负责给内部提供非常技术化的服务。因为,我们认为自己需要一些具有技术背景的人来担任产品经理。

  • 配置测试工程师,使自动化测试成为班组的一项任务

  • 运维工程 - 设置一个平台团队。这并不完全是 DevOps 或 SRE,而是要让一个更现代化的类似系统管理员的人来看管所有的基础设施,这是移除工程师和生产环境之间的隔阂的第一步。

  • 配置用户研究和用户体验设计人员


最后,我们还引入了敏捷教练这一角色和职业路径。敏捷教练分会负责支持和保证 MOO 能够维持团队的健康和快乐感,使之持续交付有价值的成果。现在,MOO 已经有了一个蓬勃发展和永久性的内部敏捷教练分会。该分会的伟大之处在于使我们能够将眼界拓宽到技术和产品团队之外,并且考虑整个公司的敏捷。


从分队到四边形


我们在 Spotify 模型上所做的另一件事是引入了一个由产品经理、敏捷交付教练、技术主管和体验设计师组成的四边形。每个部落(和班组)都有一个四边形,这个四边形的人员负责商定一个班组或部落能够完成的是什么,以及基于每个学科的现有知识,最佳的行动路径是什么。



这个角色四边形将确保每个班组之间保持良性的张力,以及每个观点和学科都能得到平等的考虑。如果不能给客户带来价值,光做一些技术突破则毫无意义,或者反之,为了增加收入总是抄近路欠一屁股技术债也毫无意义。


其想法是,将根据当前的上下文讨论和调整职责,每个角色都将带来一个独特的视角。你也可以根据上下文来替换或者添加特定的角色。每个学科都有特定的“拉动因素”,这种因素会吸引特定类型的工作和职责,而这是传统的 RACI 方法的一种替代选择。


MOO 如何逐渐演进 Spotify 模型


两年前我们实施了第一次迭代。现在的阶段,我们需要更新模型,因为我们已经了解了这个模型过去表现好和不好的方面。


肯定有些方面表现非常好。比如,我们的组织结构更好了,基于产品而不是基于项目和临时团队了。我们对服务有了更多的端到端掌控,团队的稳定性也提高了,不经常发生变动了。


由于产品团队和部落同时协助端到端的掌控,技术和产品在 16 年和 17 年发展迅猛,而且组织结构良好。所以,当有新人员加入时,他们的归属感很强,这也帮助他们尽快地适应和融入。


当然,spotify 模型也有一些方面表现并不好。毕竟,Spotify 模型是别人发明的,它在别人那是奏效的。但它并不是万能秘方,所有人都可以用。


因此,在过去半年,我们对实施后的模型进行了一些小的微调和改进,换句话说,演进,而不是革命。我们不想要也不需要敏捷变革。但是,这并不是说就没有改进的空间了。比如,我们对如下内容做出了一些改变和改进:


  • 部落和班组的领导

  • 为了确保更多的本地化决策,我们更多地强调让产品和工程总监充当最终决策人。

  • 分队 - 对于小团队来说,分队并不可行。在一个常规的 7-9 人团队中,有一半的人都属于分队,这人为地造成了分裂和阶层。所以,考虑 4 个视角对于我们而言仍然十分重要。

  • 工程经理的角色

  • 我们改进了工程经理的工作描述,确保工程经理属于团队的一部分,我们不再只关注于单个人的管理,也不再只关注于利用工程经理的经验来支持和指导团队。

  • 敏捷交付教练的角色

  • 我们更清晰地叙述了该角色的教导和交付属性、这 2 个属性如何对班组内的工程经理和产品经理起到补充作用,以及这些教练在哪些方面可以提供独特的价值。

  • 职业路径

  • 我们改进了所有的工作类型,确保各个工作类型具有清晰的职业发展方向,并使其与 MOO 核心能力模型一致


Spotify 模型对于 MOO 来说是个非常好的开端,但是现在我们需要根据自己的需求和文化来调整组织结构设计。


从敏捷之旅中我们学到了什么


MOO 的组织文化并不是照搬 Spotify 组织文化,虽然两者很相似。也就是说,Spotify 的一些工作方式对我们来说并不起作用。


比如,我们引以为傲的分队概念后来就变得有一点阶级化了。结果是,许多分队的成员想要界限分明的职责,这样他们就能明白自己必须要做什么。另外,共同责任制的概念也跟我们格格不入。也就是说,许多决策需要由委员会做出,还有许多事事都向核心管理层寻求批准的行为。


我们另一个主要的收获是关于如何让 Spotify 模型在一开始就在技术上可行。


我们见过许多关于如何从瀑布转变为敏捷方面的培训和案例分析。它们大多都推荐使用和 Spotify 模型相似的伸缩框架或组织设计。Spotify 模型的假设是存在一个松耦合、现代化的架构,和由分队端到端掌控的微服务。而这就是 Spotify 所做的!这个架构就是一个基本的使能器。


而在现实中,许多企业都有老旧的软件、单体结构和技术债务,这些会造成团队之间有非常大的依赖,所以这会使得这种组织设计在实际中不太可行。让团队真正自治尤为困难,除非你解耦这些依赖。所以说,康威定律是正确的,当时我们构建的系统体现了我们的组织结构。


MOO 公司已经有 12 年历史了,而且还在快速发展。这意味着其技术栈也快速地在演进。但我们还未拥有理想的架构!而且我们还有单体应用需要处理。这让更好地组织部落和分队更加困难,因为当我们拆除单体同时构建新服务时,要处理的依赖关系实在太多了,而且在此期间我们企业还处于不断发展之中!


接下来的行动


MOO 正在以一种渐进的方式进行上述改变。我们拥有一个由经验丰富的敏捷教练和技术领袖组成的团队,他们善于从其敏捷和精益工具箱中选择正确的概念和方法来帮助 MOO 的发展。我们不会虔诚地坚持 Spotify 模型,也不会照搬现成的伸缩框架。MOO 做的事情并不俗套,我们挑战自己,并且对能够寻找到适合我们自己的方法满怀期待。尽管如此,行业趋势仍会是我们的灵感来源。


目前,我们正在评估自己的技术策略,更多关注现有的架构和老旧软件对我们形成的限制,以及评估能促使我们进步的各种不同的方法。这些都会改善班组之间和部落之间的依赖,并且显著减轻团队推出新产品的工作负担。


为了实现目标,我们将继续寻找和留住尖端的人才,平衡团队技能组合和资历,以及创造一个支持分布式工作的环境。


而 Spotify 模型在上述这些方面毫无帮助!


作者简介


Claire Donald 是 MOO 的“平台和敏捷教导部”的工程总监。她在领导私人和公共部门技术团队方面有 20 多年的经验。


查看英文原文MOOtopia – Adapting the Spotify Model at MOO


2019 年 5 月 27 日 08:008147
用户头像

发布了 34 篇内容, 共 15.8 次阅读, 收获喜欢 45 次。

关注

评论

发布
暂无评论
发现更多内容

架构师第七周学习总结

小蚂蚁

性能压测工具

武鹏

乘风破浪的文思海辉,以及TA的行业数字化“新人设”

脑极体

Gossip 协议详解

奈学教育

Gossip

JAVA已过气?中俄大佬对话告诉你俄罗斯最受欢迎的编程语言是什么!

华为云开发者社区

Java 开源 程序员 Lambda 编程语言

性能测试

考尔菲德

架构师训练营第七周作业

Bruce Xiong

中国区块链服务网络 BSN 宣布集成以太坊等六大知名公链

CECBC区块链专委会

BSN 集成公链 标准框架 底层基础设施

通过双 key 来解决缓存并发问题

Bruce Duan

缓存穿透 缓存并发 双key解决缓存并发

MySQL常用函数

Bruce Duan

mysql常用函数

Gossip 协议详解

古月木易

Gossip

一周信创舆情观察(7.13~7.19)

统小信uos

数据库 舆情 芯片

阿里官方 Redis 开发规范

Bruce Duan

redis Redis开发规范

Kubernetes 1.0 发布刚六周年,IBM 却想招 12 年经验的

神经星星

程序员 Kubernetes 云原生 招聘 ibm

秒懂云通信:如何用阿里云平台发短信?

巨侠说

总结

ruettiger

第七章总结

李白

【研报下载】InfoQ《2020中国技术发展白皮书》重磅发布

InfoQ写作平台官方

写作平台 InfoQ 白皮书 研究报告 活动专区

你只加了两行代码,为什么要花两天时间?

Yukun

程序员 debug bug

第7周作业一

ruettiger

架构师训练营课后总结-性能测试

superman

报销流程太慢太复杂?区块链技术引入票据系统效率翻一倍

CECBC区块链专委会

数据共享 电子票据 优化业务 可信体系

埋点全解析,你最关心的可视化埋点在这里!

易观大数据

全国第一枚企业区块链电子印章诞生

CECBC区块链专委会

萝卜章 区块链印章 全流程上链 e签宝

第7章总结

武鹏

工作总结

Arthur

架构师训练营作业-web性能压测示例代码

superman

极客大学架构师训练营

架构师培训第七周练习

小蚂蚁

SpringBoot分布式验证码登录方案

Bruce Duan

验证码 Kaptcha

【week07】作业

chengjing

《深度工作》学习笔记(1)

石云升

读书笔记 专注 深度工作

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

MOO如何改造Spotify模型-InfoQ