案例解析：Spotify组织敏捷能力开发策略

<h1>企业概况</h1> • Spotify 是一个流媒体音乐服务平台，2008年10月在瑞典首都斯德哥尔摩正式上线。它提供免费和付费两种服务，免费用户在使用Spotify的服务时将被插播一定的广告，付费用户则没有广告，且拥有更好的音质。 • Spotify已经得到了华纳音乐、索尼、百代等全球几大唱片公司的支持，其所提供的音乐都是正版的，Spotify除了提供在线收听外，还能下载音乐到本地供离线收听。 • 2017年12月8日，Spotify与腾讯控股有限公司及腾讯旗下的腾讯音乐娱乐集团联合宣布股权投资，腾讯及腾讯音乐成为Spotify的第三大股东。 • 截止2020年2月，总用户数2.71亿，付费用户1.24亿，比例达到了1:2.2。也就是说，平均2.2个用户中，就有一个付费用户，这转化率是相当惊人的。到2020年底，Spotify预计MAUs将达到3.28-3.48亿，付费用户总数为1.43-1.53亿。 <h1>愿景驱动敏捷</h1> 这个案例非常有意思，我非常喜欢这样一家公司，可能很多伙伴们在海外留学回来，都用过这样一个软件，就是Spotify。这家公司的定义，是自由的、生而敏捷之路。 这是一家在全球来讲非常优秀的公司，现在Spotify付费用户数非常高，市值也是很高。我认为任何一家的公司它之所以会长成这个样子，一是跟创始人有关系，二是跟创始人的心智有关系。 他们两个创始人，一个音乐爱好者，一个是商业 IT技术爱好者，所以他们俩一结合就变成这样一个全数字化的流媒体音乐平台。 Spotify的愿景是要在任何时候要给你带来对的音乐。 为了让清晰的愿景成为组织内激发员工的动力，并且让所有部门保持步调一致。Spotify决定采用与传统的组织完全不同的组织结构，让企业快速规模化的同时，对外界保持敏捷性。这样的大规模敏捷框架也成为了敏捷组织的典范，为众多组织在转型时提供参考。 在Spotify没出来之前，流媒体数字音乐平台当中有很多巨头，Apple、索尼、环球音乐等等。Spotify出来之后怎么活下来，怎样做成全球第一，怎么样超过Apple？所以一定要想这个问题，我靠什么？靠我的资源？靠我的钱？可Spotify的资源、钱等等都PK不过其他巨头。所以Spotify纯粹靠它整个组织运营的效率，在垂直领域当中做到全球第一。 <h1>Spotify敏捷组织设计理念</h1> 1、社群组织 采用社群（Community）来替代传统的层级式组织（Hierarchical Structure）。 • 好处：让员工的兴趣转化为信仰，增强员工的行动力。 • 难点：在社区内确定职责非常困难。在很多情况下，社区的每个小队以及小队里面的员工对某个职位的理解都不同，甚至连职位的名称都完全不同。 2、教授和企业家模型 采用Mary Poppendieck 和 Tom Poppendieck 建议的“教授和企业家”模型（ Professor and Entrepreneur Model ） • 分会领导是“教授”，关注于技术卓越 • 产品负责人（PO）就是“企业家”，关注于交付优秀的产品 • 联系：这两个角色之间存在正向的紧张关系，因为企业家倾向于快速交付和走捷径，然而教授倾向于慢下来和把事情做对。两个方面都是必须且互补的，可以促进组织不断进步。 <h1>Spotify的敏捷组织的整个构成：分队、部落、分部、公会。</h1> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=1e8b21b727d6f9e5d2a72e5e519e446f&file=file.png" alt="" /> 1. 分队是由跨科学团队成员搭配而成的自主管理单元，高度专业化。一条线拥有明确特定的长期使命，每个分队最多不超过9个人。 2. 部落是由一系列从事相关领域工作的分队集合而成。工作目标是解决特定的业务问题，并为分队提供致力于解决专业问题的大环境。每个部落最多不超过20人。 3. 分部是由分队中拥有相同能力专长的人员构成的小组。工作责任包括为部落制定交付方式的指导原则。每个分部一般最多不超过7人。 4. 公会是虚拟的知识型社区。公司所有员工都可以在此分享代码、工具和最佳实践。人人都可以凭兴趣加入。 所以Spotify组建小队、部落打破组织的壁垒，是如何做的？ <h1>组建小队与部落，打破组织壁垒</h1> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=b889dff80f34d42d44559cdbc354a803&file=file.png" alt="" /> <h2>小队——PO（Product Owner）</h2> 首先，小队，是Spotify的基本开发单元，是一个全功能、负责端对端交付的工作团队，理论上9人左右。他们拥有设计、开发、测试和发布产品所需的所有技能和工具。在Spotify实践中，由于小队是根据一个业务里面具体的功能来组建的，根据不同的业务配比不同比例的测试、开发、产品和职能员工，所以人数在7+/-2范围。 小队的运营特点： · 坐在一起：为了践行敏捷宣言“个体和互动高于流程和工具”，小队成员坐在一起，更有利于个体的互动。 · 自主管理：除了PO之外，小队里的成员并没有角色的区分，所有的人承担所有的工作。PO是一个虚拟角色，非行政title，它的设定目标是让日常工作更平滑。且小队是一个高度自治的“迷你型创业公司”，他们可以和利益相关者直接对话，且和其他分队没有阻塞型依赖关系。 · 拥有长期的使命或任务：小队并不是临时为了一个具体的项目而成立的临时组织，而是有着长期使命的固定团队。可能是改良支付方式或搜寻功能，或是像「电台」的功能。小队自己建构自己的故事，并负责产品的上市。 · 每个小队都有一位产品负责人(Product Owner)和敏捷教练 (Agile Coach)，来推动小队日常运营和产品上市。 小队 PO产品负责人由小队员工民主选举产生。 不同分队的PO紧密合作，共同维护一个宏观层面上的产品路线图文件，指引整个Spotify产品发展方向。 PO负责把团队的待办任务综合考虑商业价值和技术因素来进行优先级的排序，但从不干涉团队如何完成这些任务。 每个PO产品经理也各自维护一个自己所在分队的产品待办项列表，叫PB。 <h2>小队—AC（Agile Coach）</h2> 大家很多在做技术开发的或者在互联网的企业大都清楚，小队当中的敏捷教练主要负责主持回顾会议、组织 Sprint 计划会议、做一对一辅导。 敏捷教练在第一周的时间排布，主要是团队持续沟通的可视化的工作，并提高领导团队的决策能力。了解人员建立信任和关系以及指导个人相关的所有活动，交付以项目和日常业务相关的所有内容，包括计划的会议就是会上的部分，教练要去做很多事情。 • 策略：与系统（团队和组织）持续改进相关的一切。一些是职业发展，招聘，我们应该怎么可视化工作，限制组织中的WIP，并提高领导团队的决策能力。 • 人员：与了解人员，建立信任和关系，以及指导和指导个人相关的所有活动。 • 交付：与项目和日常业务相关的所有内容，包括站会，计划会议等。 在第五周，敏捷教练大部分时间花在策略上。收集关于组织的信息，了解和各个团队如何互动。和各个管理团队分享目标，讨论如何达成目标。交流对工作角色的期望，以及如何将工作可视化，以便于更好的协作。 两个月后，敏捷教练的时间更加平衡。更多的地参与交付。在策略上付出的时间变少。 所以敏捷教练更多在进行人员的交流、策略组织的信息共享、各方面协作。 敏捷教练这个角色跟BP非常的像。首先把人员关系搞好了，建立信任。大家有什么策略弄一弄，然后进行关键事项、关键目标的排期，可视化，并放在信息管理系统当中。 像现在很多金融企业在做数字化的敏捷化改造的时候，他们叫敏捷教练，实际上我们给他们建议比较简单，我这敏捷教练实际上两种角色： 第一种是熟悉某个业务或者某个专业板块的，一些比较成熟的人，当然这是一个优选的教练。 第二种，我觉得HR的BP也非常好，可以成为这样的教练的角色。我觉得未来的BP还有一个很重要的发展空间，就是未来成为敏捷教练。 可能在不远的将来，3~5年的时间，敏捷教练应该会成为一个非常重要的新职业。我认为这是一个必然，特别是为了走向全面的数字化的时代，一定有敏捷教练这个角色。 <h2>部落</h2> 一个部落是在相关领域工作的小队集合——比如音乐播放器，或者后台基础设施。负责共同的产品组合或顾客区隔，组织方式取决于相互相关性，并尽可能简单。 员工以部落编制。一个部落不超过 150 名员工，部落的组建是和业务强对应的，所以部落的大小取决于业务的规模，有的特定领域可能人数为20+人也可以。 同一办公地点：为了有利于不同小队间的沟通，减少交流的成本。 部落拥有一个负责人：酋长 设计理念来源于邓巴数的原则：人类智力将允许人类拥有稳定社交网络的人数是148人。在实践中一般不超过150人。人数过多管理复杂度容易提升，沟通的成本也会迅速增加。 <h2>部落—酋长</h2> 酋长是部落负责人，是个虚拟角色。 对酋长的要求有两点： 1、正确地根据业务分出来独立工作的小队。 酋长要根据整个产品线的价值目标，把众多功能以及功能相关的这些岗位进行拆分组合，所以这个酋长是一个非常重要的角色。 2、和协同小队进行必要的合作。 判断酋长是否成功的标准有两个： <ul> <li> 他是否给小队提供了一个舒适的栖息地。 </li> <li>他是否为小队提供交流、合作、分享、创新、改进的环境和支持。</li> </ul> <h1>建立分会与公会，创建知识共享社群</h1> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=70cc4cf523c3eec28ea727d15a7a4533&file=file.png" alt="" /> <h2>分会</h2> • 目的：为了促进合作，避免各成员或各小队各行其事、不相往来进而重复造轮子，所以Spotify 在小队和部落之上，架构了分会（Chapter） • 组成：由同一个部落、相同技能领域、拥有相似技能的一些人组成。（技能领域，例如敏捷教练，或Web开发。） • 任务：类似于传统的职能部门，负责传播知识和开发工具，定期开会讨论他们的专业领域，研发成果和挑战。 • 分会领导： - 服务式领导 - 同时也是某个小队的成员，参与小队日常工作。 - 负责教导和指导分会成员的工作，执行员工发展、定薪和激励等工作。 <h2>公会</h2> • 目的：促进整个组织层面的资讯流通及知识分享。 • 组成：跨部落，贯穿整个组织，囊括公司所有成员。 • 虚拟知识型社区：定期进行特定领域的知识、工具、代码和实践的分享。 • 轻量级的“兴趣爱好社区”：有兴趣的人可以随时加入，也可随时离开。 • 每个协会都有一个“协会协调人”，负责组织和协调协会的活动。 所以分会与公会可以确保专业知识可以在组织内扩散，保持员工的持续学习的氛围。相关专业人员共同分享与交流的平台，以弥补在敏捷组织快速的变动下，成员可能会对组织认同不足的缺陷。 <h1>与传统矩阵制度组织对比</h1> <h2>传统矩阵组织形式</h2> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=120e5b8c0bba6e207563fac16121e038&file=file.png" alt="" /> • 项目立项时，“职员”由“职能经理”从职能部门“分配”到“项目”。 • 在项目中，“职员”由项目的“项目经理”分配任务。 • “职员”要例行向“职能经理”进行工作的“汇报”。 • 项目结项后，“职员”从“项目”释放，回到“职能部门”，等待分配到下一个“项目”。 <h2>Spotify的组织形式</h2> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=a93cb303243f39305fe90eec42757797&file=file.png" alt="" /> • 职员”在“小队”中“持续”工作，与小队中其他人员共同“打造”一款优秀的“产品”。 • “分会”和“协会”为“职员”提供“服务”，分享知识、工作、代码和实践，解决小队成员“如何做得更好”的问题。 <h1>监控实践过程，保持内外敏捷</h1> Spotify高管团队会定期对小队进行调查，判断各个成员是否各司其职，完成工作使命。以下是各个调查项的评判参考标准： 1、产品负责人 判断PO在为各个项目排序时，是否能够综合考虑商业价值和技术因素。 2、敏捷教练 判断敏捷教练是否能帮助团队识别障碍、指导团队持续进行过程改进。 3、支配自己的工作 判断小队内的每个成员是否都可以支配自己的工作、可以积极参与工作计划的制订、可以选择自己做什么任务。 4、易释出 判断小队是否可以(并且确实做到！)轻松释出产品，而不需要很多的争论和同步。 5、量身定制的流程 判断小队是否拥有自己的工作流程并且持续对其进行改进。 6、使命 判断小队是否有一个队内所有人都知道并关心的使命；并且待办项列表中的故事是否都是和这个使命相关。 7、组织层面的支持 判断小队是否知道去哪里寻求解决问题所需的支持，无论是技术问题还是“软性问题”（“soft” issues）。 所以这7个评判标准可用来定期监控Spotify内外部的敏捷。 <h2>减少小队间的依赖，保持创新能力</h2> 为什么要减少依赖？ • 在Spotify内部，依赖意味着堵塞和等待。 • Spotify认为小队模式成功的关键在于减少小队与小队之间的依赖。 如何减少依赖？ • 经常对小队进行依赖调查： -你们的工作依赖于哪些小队？ -这些依赖是否阻塞或拖慢了你们的工作？ -严重到了什么程度？ • 基于调查结果，围绕负向依赖来讨论，特别是引起了工作阻塞的以及跨部落的依赖关系。为了消除这些有问题的依赖，经常会调整任务优先级、团队组成、架构或技术方案。 • 必要时，召开SoS（Scrum of Scrums）协调会议。 • 发布成果规定由小队自行发布，运维小队只负责“铺路”。 <h1>创建敏捷文化</h1> <h2>举办“黑客日”，强化知识共享意识</h2> • 为了激励学习和创新，Spotify鼓励每个小队把大概 10%的工作时间用在“黑客日（Hack Days）”上。 • 在黑客日期间，大伙可以做任何自己想做的事情：通常大家会尝试一些新想法并和伙计们分享。 • 每个小队可以决定自己的“黑客日”时间。有的团队每两周举办一天黑客日；有的团队则攒够了日子，搞一个“黑客周”。 • 黑客日不仅可以提高员工参与感，也是一个让大家紧跟新工具、新技术的好途径，有时候非常重要的产品创新也诞生于黑客日。 我觉得这个很有意思，跨部门之间应该多分享，多互动。因为现在开个腾讯会议，大家就可以去交流了，很方便。 <h2>不惧失败，庆祝成功</h2> • 将「回馈和教训」与「工资和绩效」的讨论分开，以此鼓励员工不畏惧失败，大胆试错。 • 小队设有“失败纪录墙”，强调团队在失败中学到的教训。 • Spotify高管团队认为打造高绩效团队的基础就是鼓励犯错并快速纠正。“既然错误不可避免，那我们就只需要比其他人更快地犯错并更快地改正错误。我们无须对犯错恐惧。” <h2>以人为本，共创佳绩</h2> • 坚实的“互相尊重”文化：交流时经常听到类似“我的队友真棒”的评论。 • 员工常常把事情归功于小队其他人的杰出表现，而非自私的为自己争功。 • Spotify总是愿意花费巨资招聘很多天才和杰出人才，但却几乎没有狂妄自大的员工。 • 提供方向和指导但绝不插手：员工会被期望自己去找答案，没人会告诉他们该做什么。但当他们需要协助的时候，会很快获得许多援助。大家一致认同的真理是：我们在同一条船上，而且必须帮助其他人成功。 <h1>总结</h1> 我们今天分享内容大概就是三个部分： 第一个是为什么开发敏捷组织。 第二个是敏捷组织四大运作机制，还有十大特征。 第三个是Spotify案例解析，从文化、组织构成、从分会、公会、部落和小队当中跟大家做一些分享。 我们今天的分享就到这里，如果大家后续有什么样一些疑问，我们可以在群里面进行互动，后面我们还会继续分享跟组织敏捷能力提升的一些非常好玩的，非常有意思的一些深度的课题，我们今天是展开了一个视角，让大家理解什么是敏捷组织，Spotify到底怎么来做敏捷组织，它的构成是什么样子的。后面我们会来谈敏捷组织开发到底怎么来做，请各位及时关注我们的公众号“AgileXS敏捷组织”。如想获取更多的AgileOD相关的诊断工具，请点击：<a href="https://www.agile-xs.com/" title="ADS敏捷诊断：数智化组织诊断与分析工具">ADS敏捷诊断：数智化组织诊断与分析工具</a> <img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=f5f48efe46d1185b58409c11e662c1a5&file=file.png" alt="" />

AgileXS敏捷策略

案例解析：Spotify组织敏捷能力开发策略

页面列表