Spotify 模式并非“敏捷涅磐”

通过员工的成长，Spotify 实现了企业的管理和运作方式对团队和敏捷实践的支持。但 Spotify 并非一种“敏捷涅槃”，如果一个团队持续成长和改进，并不断地分解为新的团队，这样的团队是难以达到高效的。Spotify 的团队和领导力教练 Joakim Sundén 建议，人们应对愿景勇往直前，但是在达成愿景的过程中应小步前行。

Sundén 在 Lean & Agile 苏格兰 2017 大会上谈及了一些并不能在 Spotify 完全发挥作用的做法，以及 Spotify 是如何致力于去解决它们的。InfoQ 以问答、总结和文章方式报道了该大会。

InfoQ 采访了 Sundén，内容涉及：那些不能在 Spotify 完全发挥作用的做饭是如何影响产品的；Spotify 工程经理和技术带头人的日常工作情况，以及他们对 Spotify 成功的贡献；管理者在一对一会面中应讨论什么，以及一对一会面是如何对他们的工程师有所裨益的；如何让改进得以发生。

InfoQ：对于那些不甚了解“Spotify 模式”的人，您能否做一个概要的介绍？

Joakim Sundén：应澄清的是，我们从来没有提出过“Spotify 模式”这一称呼，我们只是向人们介绍我们当前正在做的事情。我认为的确可以言简意赅地称其为一种“模式”，但其并不能成为一种应“遵循或模仿”的方式，应使用该词汇的两种不同场景定义。在与非 Spotify 公司人员交流时，我将其理解为仅是关于组织结构以及小队（Suqad）、分部（Chaper）、部落（Tribe）和公会（Guild）的一切内容，外加一些大众工程师文化的视频，所有这些构成了所谓的“Spotify 模式”，并且人们在该模式上投影了自己的“敏捷涅槃”理念。如果的确是后者，那么人们无疑会在加入 Spotify 后感到大相径庭。

InfoQ：在 Lean & Agile 苏格兰大会上，你谈及了一些做法并不能在 Spotify 完全发挥作用。在此您能给出一个例子吗？

Sundén：不要误解我的意思。我热爱 Spotify，热爱我们在此所能培育出的企业文化和工作方式，但这远非一种“敏捷涅槃”。例如，一个令很多切实具有敏捷体验的人感到惊讶的事情就是，Spotify 并非普遍地采用了敏捷工程实践，诸如如 TDD、结对编程、整洁代码和简单设计等。如果大家看到一个小队频繁地实行其中的任何一种敏捷工程实践，那么这完全是一个例外情况，我们的规章制度并非要求如此。事实上，许多小组甚至不会遵循通常的敏捷团队做法。他们可能计划了会议，但并没有跟随计划的执行方式，或是表现出他们如何能改进计划。使用看板的团队很少使用 WIP 限制，即便他们这样做了，很多时候他们也会忽视了这些 WIP 限制。我并非想表示上面介绍的情况适用于我们所有的团队，我们的企业中还有大约 150 个团队是我知之甚少的。但是上述内容来自于我的观察，来自于我与数十个团队一起六年多的共事，并且与很多别的教练和 Spotify 员工的交流。

InfoQ：难道这不会影响到产品吗？

Sundén：如果我们开展更多的敏捷实践，并更加遵循这些敏捷实践，我是否认为我们的产品会更好？是的，我的确是这样认为的。但其中总是存在着改进的空间，我知道这些实践能给出哪些变化。我们时常力图去改进这些事情，这就是我们一直雇用很多敏捷教练的原因。你也必须看到，超增长多年来一直是 Spotify 的运行常态。当然，这在很多方面有力地支撑了 Spotify，但是这也导致了一些挑战。它使得团队保持持续成长和改进，并不断地分解为新的团队，因此团队难以达到高性能。另一方面，我愿意认为我们的文化在一定程度上弥补了我们所缺乏的。我力图避免在大的项目和大的版本上工作，而是转而信任自治团队能去实验，发现对于我们的战略需求和目标的很好解决方案。与我去过的其它地方相比，公司的管理和整体运作方式切实地支持了团队和敏捷实践，而非是团队和敏捷实践的补充。

InfoQ：能为我们介绍一下 Spotify 的工程经理和技术带头人的日常工作吗？他们对 Spotify 的成功有何贡献？

Sundén：他们最大的也是最重要的贡献，就是控制了企业的人员规模没有翻番。增加员工不仅意味着要招聘新员工和开发已有员工的能力，而且要培育这些员工去融入到 Spotify 所提供的缤纷环境中。超增长、高度自治和信任文化、开发和透明，这都意味着很多人只有在得到帮助的情况下，才能认清并了解我们日常所面对的所有信息、机会和决策。在这种被我称为“持续文化入职”的过程中，我们的分部领导起到了非常大也是非常重要的作用。不少分部领导与他们的直接报告人每周都进行一对一会面，为这些员工提供支持，并督促他们在企业中的成长进步。这些员工就变得相当固定，职业中的固定点有助于一个人毕其职业生涯成为 Spotify 雇员。

InfoQ：他们在一对一的交流中会探讨什么内容？这是如何对工程师产生帮助的？

Sundén：通常一对一交流中，很多时间专门针对工程师的需求，无论什么样的需求皆可。从更为正式的事情（例如建立并跟随自己的开发计划，并为此找到正确的教练和导师）到更为正式的对话（例如关于现在正在生活做什么）。一对一也为反馈和识别提供了很好的时间和场所。有时它可以是关于运行中的故障排除，有助于工程师找到可以交流的人，或是理解事情的工作机制。有时分会领导不得不引发一些阻碍，但是通常情况下主要是工程师们自己帮助自己，发展自身在企业中良好运作的能力。

InfoQ：对于那些想要促成企业改进的教练及其他的改进代理人，您有哪些建议？

Sundén：这个问题要根据情况的不同而定……。通常我会建议在身体力行去解决问题前，应先试图去理解问题。这是否应该是现在去解决的问题？尽量避免华而不实（hand waving）和主观臆断（Opinion），找出真正发生的情况。一个着手去做的好方式是让人们给出他们对所有一切都很完美情形下的意象场景。这将人们置于一个积极的框架中，有助于他们专注于伟大的成果。一旦你确信自己正致力于实现一个值得花费时间的改进机会，那么尝试一下时间上受限的小规模实验，这些实验是你切实去执行的。使用你所学到的技能去给出下一步。我已经发现，人们应对愿景勇往直前，但是在达成愿景的过程中应小步前行，这种组合是很好的组合。

查看英文原文： The Spotify Model is No “Agile Nirvana”