Spotify敏捷模式详解三部曲第二篇：研发过程

 本文转自：Scrum 中文网

 

引言

在本系列文章的第一篇，我们介绍了Spotify的敏捷研发团队，以及它独特的组织架构。Spotify的研发团队采用的是一种非常独特的组织架构，如下图所示：

整个研发组织有多个称为“Tribe部落”的单元组成，每个部落中包括多个“Squad小队”，从横向的维度，把拥有类似技能的人放在一起形成“Chapter分会”和“Guild协会”。

本篇是Spotify敏捷模式详解三部曲第二篇，将继续为大家介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。

Spotify产品开发的核心理念

• 创造革命性的产品，通过早期低成本的原型设计来控制产品风险。
• 品质不过关决不发布产品，即便是落后于既定的发布日期。
• 通过产品发布后持续地调整优化，来确保产品从发布时就表现优异，直至最后得到惊艳的产品。

从产品创意——>形成产品4个阶段

产品风险控制

• 产品开发最大的风险——构建一个错误的产品。
• 思考阶段：以较低的成本，大幅度降低产品风险。
• 构建阶段：运作成本高，几乎无法降低产品风险，所以要尽量缩短。
• 发布阶段：随着产品的发布和客户使用，产品风险持续降低。
• 调整阶段：随着时间的推移，产品逐渐完善，运作成本持续下降，小队们可以开始逐渐去做其他事情。

一、Think it 阶段

工作流程

过程说明

• 目标：拿出一个足够吸引人的故事性描述和能够传达它的可运行原型。
• 输入：产品创意
• 过程：

1. 组建Think it 小队。
2.写故事描述，定义指标（要达到的效果）。
3.构建原型。
4.确认是否值得构建MVP。

• 完成的定义：

1.管理者和Think it 小队都认同这个产品值得构建（或者这个产品永远都不值得构建，应该被舍弃）。
2.说明：这是一个主观上的决定，它并没有过硬的数据作支撑。直到Ship It阶段才会产生坚实的数据，所以我们希望尽可能快地到达Ship It阶段。

• 故事描述（narrative）

故事描述，是一个简短的文档，用来回答如下问题：

1. 为什么我们要开发这个产品？谁能从中受益？如何受益？

2. 我们期望可以从这个产品提升哪些关键指标？诸如：会增加多少音乐播放量，增加多少下载量，增加多少登录量等等。

3. 我们的预期是怎样的？我们如何判断这个产品是否成功？

4. 是否会令产品“再上一个台阶”(Step Change)吗？（指的是，我们预期这个产品在既定指标上会带来至少双倍的提升。如果只是在度量指标上略有提升，最好有个更强有力的理由，例如战略方面的原因）

关于故事描述的说明：

1. 故事描述不是所谓的产品愿景规划。它不包括特性清单、预算、资源计划。更像是一个用数据说话（数据驱动）的意愿陈述。

2. 最重要的部分就是故事，要讲一个生动的、能吸引人的故事。

举例：“Discover”标签产品的故事描述——介绍一种发现音乐的更好方式。看！你最喜爱的艺术家刚刚分享了一首歌给你。我们让艺术家们和粉丝们从未如此靠近过。喜欢一个艺术家？那就去follow（关注）他，并与朋友们分享你的新发现吧。

• 构建原型

1. “Think It”小队会构建许多不同的原型来传递产品的感官上的体验。

2.“低保真”的纸面原型。

3.“高保真”的可运行的原型（上面跑伪数据源之类）。

4.几个内部焦点小组会用来辨别哪一个原型能最好地传达了它的产品精神（那个故事性描述）。

5.直到我们不断缩小范围，最后只剩下几个胜出的原型。

• Think it 阶段何时可以结束

1. 这是一个没有截止日期的迭代过程，我们无法决定这个产品前期会花去多少时间。

2. 只有当我们可以拿出一个足够吸引人的故事性描述和能够传达出它的可运行的原型，才值得去构建产品。

二、Build it 阶段

工作流程

过程说明

• 目标：构建出能够向真实用户充分传达产品理念的MVP（最小可行产品）。
•  过程：

1. 扩建小队。
2. 构建和内部发布。
3. 确认MVP是否足够好。

• 注意事项：

1.尽量快：不希望在发布产品前构建一个十分完备的产品，因为这个过程会延迟我们获取客户使用数据的时间。

2.不希望产出无用的或令人沮丧的产品。要写产品级的代码并且保障质量。

3.（MVP也可以称为：最早令人喜爱产品。）

• 完成的定义：

管理者和小队共同认为：

1.目前这个MVP已经实现了基本的故事描述。

2.已经足够好，可以开始向真实用户发布。

三、Ship it 阶段

工作流程 

过程说明

• 目标：逐渐将产品扩散到所有用户，同时进行度量和分析，确保产品在真实环境下，也能够达成它的设计初衷。
• 过程：

1. 小范围发布。
2. A/B测试。
3. 度量和分析、学习、迭代提升。
4. 逐步扩散到所有用户，或者抛弃。

• 完成的定义：

1. 产品扩散到所有用户。

2. 注意点：

1）这时并不意味着产品已经“功能齐全（feature complete）”，完成了Ship It阶段只是意味着产品（MVP+必要的改进）已经被100%铺开而已。

2）不存在“功能齐全”的说法，因为产品即使在Ship It阶段之后还会继续优化。

四、Tweak It 阶段

工作流程

过程说明：

1. 在这个阶段，小队持续优化、A/B测试、度量和分析。

2. 直到有一天，所有重要的改进都已经完成，新的改进已经无法带来吸引人的收益，指标数据已经很难有进一步的提升，产品已经趋近于“极致”。

3. 这时候，小队会逐渐转向新的工作或者重构下一代产品（回到Think it 阶段）

五、总结

产品开发全景图如下图所示，它包括了四个阶段：

• Think it阶段：拿出一个足够吸引人的故事性描述和能够传达它的可运行原型
• Build it阶段：构建出能够向真实用户充分传达产品理念的MVP（最小可行产品）。
• Ship it阶段：逐渐将产品扩散到所有用户，同时进行度量和分析，确保产品在真实环境下，也能够达成它的设计初衷。
• Tweak it阶段：在这个阶段，小队持续优化、A/B测试、度量和分析。

本篇是Spotify敏捷模式详解三部曲第二篇：研发过程，本系列文章的下一篇将继续介绍Spotify的工程文化，敬请期待。

相关阅读：
Spotify敏捷模式详解三部曲第一篇：研发团队

参考资料：

本文部分内容及引用的图片主要来自于Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。
本文作者：

Jerry Li(李洁)， Eric Liao（廖靖斌）