系列：Spotify敏捷模式详解之研发过程
Jerry Li(李洁)， Eric Liao（廖靖斌）
讲述：丁婵大小：7.39M时长：05:23
在昨天的文章中，我们介绍了 Spotify 的敏捷研发团队，以及它独特的组织架构，即整个研发组织由多个部落组成，每个部落中包括多个小队，从横向的维度，把拥有类似技能的人放在一起形成分会和协会。本文继续分享 Spotify 基于敏捷开发和精益创业思维的产品研发过程，供你参考。
Spotify 产品开发的核心理念主要有三点：
创造革命性的产品，通过早期低成本的原型设计来控制产品风险。
品质不过关决不发布产品，即便是落后于既定的发布日期。
通过产品发布后持续地调整优化，来确保产品从发布时就表现优异，直至最后得到惊艳的产品。
从产品创意的产生到形成产品会经历思考、构建、发布、调整这 4 个阶段。而在产品开发过程中，最大的风险就是构建一个错误的产品。而控制风险的办法就是从产品形成的四个阶段入手：
思考阶段：以较低的成本，大幅度降低产品风险。
构建阶段：运作成本高，几乎无法降低产品风险，所以要尽量缩短。
发布阶段：随着产品的发布和客户使用，产品风险持续降低。
调整阶段：随着时间的推移，产品逐渐完善，运作成本持续下降，小队们可以开始逐渐去做其他事情。
下面具体分析每个阶段的工作流程及内容。
一、思考阶段
这个阶段的目标是拿出一个足够吸引人的故事性描述和能够传达它的可运行原型。首先要组建一个思考小队，根据目标写故事描述并定义指标，然后构建原型，讨论确认是否值得构建 MVP，即最小可行性产品。如果管理者和小队成员都认同这个产品值得构建，就将进入下一阶段。
为什么要写故事描述呢？这是一个简短的文档，用来回答以下 4 个问题：
为什么要开发这个产品？谁能从中受益？如何受益？
期望这个产品提升哪些关键指标？比如会增加多少用户等等。
预期是怎样的？如何判断这个产品是否成功？
是否会令产品“再上一个台阶”？即期望这个产品在既定指标上能带来至少双倍的提升。如果只是在度量指标上略有提升，最好重新想一个更强有力的理由。
故事描述不是所谓的产品愿景规划，因为它不包括特性清单、预算、资源计划。更像是一个用数据说话的意愿陈述。重要的部分就是故事，要讲一个生动的、能吸引人的故事。
写好故事描述，就可以构建原型了。小队会构建许多不同的原型来传递产品在感官上的体验，比如“低保真”的纸面原型、“高保真”的可运行的原型等，并进行筛选。只有当小队能拿出一个足够吸引人的故事性描述和能够传达出它的可运行原型时，才值得去构建产品。
二、构建阶段
目标是构建出能够向真实用户充分传达产品理念的 MVP。首先，要基于思考小队扩建一个构建小队，用来构建和内部发布 MVP，并确认 MVP 是否足够好。这个过程要尽量快，同时还要保证代码质量。
当管理者和小队成员共同认为目前这个 MVP 已经实现了基本的故事描述，并且已经足够好，可以开始向真实用户发布了，就可以进入下一阶段了。
三、发布阶段
在这个阶段，目标是逐渐将产品扩散到所有用户，同时对产品进行度量和分析，确保产品在真实环境下，也能够达成它的设计初衷。
首先在小范围发布产品，进行 A/B 测试，然后对产品进行度量和分析、迭代提升，最后根据小范围用户对产品的使用反馈选择逐步扩散到所有用户，或者抛弃产品。
如果产品扩散到所有用户，发布阶段的目标就算达成。不过，这并不意味着产品已经“功能齐全”了，完成发布阶段只是意味着产品（MVP+ 必要的改进）已经被 100% 铺开而已。确切地说，不存在“功能齐全”的说法，因为产品即使在发布阶段之后还会继续优化。
四、调整阶段
小队将对产品不断地进行持续优化、A/B 测试、度量和分析。直到有一天，所有重要的改进都已经完成，新的改进已经无法带来吸引人的收益，指标数据也很难有进一步的提升，就代表产品已经趋近于“极致”了。这时候，小队会逐渐转向新的工作或者重构下一代产品，回到思考阶段。
以上就是今天的内容，希望给你带来参考价值。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论