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的工程文化，敬請期待。
參考資料：
本文部分內容及引用的圖片主要來自於Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。
本文作者：
Jerry Li(李潔)， Eric Liao（廖靖斌）