產品上線規劃：分階段釋出網路產品的實作流程與工具
在上一篇《產品上線管理：寫給 PM 的基本名詞解釋與工作流程》中我從上線管理（Release Management）的角度分享了從部署到正式上線的流程、技術名詞解釋、每天上版的實務經驗分享，聚焦於整體產品部署（deployment）相關的工作方法；這篇文章則來從個別產品管理（Product Management）的角度來看，該如何針對一個新功能、流程改動來做產品上線規劃，以及前篇文章提到的階段性釋出的工具、方法與工作細節。
文章內容包含：
✔ 什麼是產品上線規劃？從舊開發流程轉變到新開發流程的原因？
✔ 分階段釋出：產品改動（Epic、Tickets、Feature Flags）
✔ 分階段釋出：產品受眾（Dogfooding、Beta Testing、A/B Testing）
✔ 產品上線規劃文件
✔ 目標導向＆假設驅動開發這篇文章的背景為，產品為已在目標市場中穩定發展的網路產品，產品改動都以提供新功能、優化使用者體驗、解決現有使用者問題為主，工作方法以敏捷式開發為主。
雖然上篇文章分享了每天上版的流程，但平心而論，我並不認為追求「每天上版」是一個好的工作方法，我真正喜歡的是我們背後「分階段釋出」來降低風險與快速探索方向的核心概念，而每天上新版只是在當時有多個團隊同時衝刺新功能造成的結果。
有些 PM 會調侃自己只是功能開發團隊（Feature Team）、功能開發工廠（Feature Factory）的推手，而非在真正的產品團隊（Product Team）創造價值。
如果你讀過《精實創業 The Lean Startup》《使用者故事對照 User Story Mapping》《產品專案管理全書 INSPIRED》（演講內容繁中筆記）等書而且也熟悉實作的方法，這篇文章可能不會對你有太多幫助。
但如果你的團隊跟我一樣正在功能開發工廠的光譜上游移，希望這篇文章能提供你一些思考方向。（當然，上面那幾本書也很建議去翻一翻。）
跟上一篇的狀況一樣，不論是跟台灣團隊還是海外團隊工作，我們在提到某些專有名詞時都是用英文稱呼，也因此講話總是中英夾雜，文章中我會嘗試翻譯，但習慣上還是會用其原文單字表達！▍什麼是產品上線規劃？
產品上線規劃（Product Release Planning）顧名思義就是針對你負責的產品、單一功能、流程優化、問題解法從開發、測試到正式上線的規劃。
剛開始做產品工作時，我們團隊的工作流程非常線性、直覺：
- 研究：蒐集使用者回饋
- 開發：打造使用者想要的功能
- 上線：釋出功能給使用者
上線後，專案正式結束，我們就會著手去處理下一個使用者遇到的問題、期待我們開發的功能。這些產品功能開發短則幾週、長則幾個月，所謂的上線規劃幾乎就等於功能開發時程表。
然而我們漸漸遇到了一些讓團隊不開心、使用者也不開心的狀況，例如：
- 開發出來的新功能的使用頻率很低，感覺像在做白工
- 開發出來的新功能沒有滿足使用者的需求與期待，甚至得到負面評價
- 為了做好功能，當 PM、QA 檢查時遇到問題，總是在最後時刻更改或新增需求，導致開發跟測試一直來來回回，花非常多時間才完成
有鑒於此，我們著手改變工作方式，核心概念類似於精實創業（Lean Startup）的開發－評估－學習（Build-Measure-Learn）模式，將每個步驟切小、切碎，這種非單一線性的流程，可以讓團隊在每個階段稍做評估與排序，若遇到問題則可以回到前面的階段重新出發。這也就是大家很常說的迭代/疊代（iteration）。
這篇的產品上線規劃指的就是上圖中「分階段釋出與驗證成果」這個步驟的執行方法，而其中又可以分為兩個面向：產品改動（程式碼）的分階段釋出、產品受眾（使用者）的分階段釋出。
▍分階段釋出：產品改動
每個大問題、大功能都可以分為三個層次。最上層是 Initiative（計畫），也就是最大的目標；第二層是 Epic（史詩故事），其下有多張 Tickets（票），每張 Tickets 的內容可能是底層架構或 API 的改動、可能是一個或數個使用者故事（對應到下圖的 Story/Task 階層）。
這邊的名稱都是取自專案管理工具 JIRA 的用法，官方定義可以參考《Epics, Stories, Themes, and Initiatives》。
請注意，在某些方法論、書中這些的定義可能會有些許不同。
舉例來說，我們團隊前陣子從 JIRA 換到了 GitHub 的專案管理工具，他將階段性任務稱為 Milestone（里程碑），下面可以包含多個 Issues、Pull Request，這個對應方式跟上面提到的 Epic、Tickets 的關係是很類似的。
➔ 分階段開發 — Tickets vs Epic
分階段釋出產品改動，代表每一張 Ticket 都可以獨立被部署上線、每一個 Epic 都是可以被驗證的最小單位。
【Tickets】與其一次做完一整個功能，不如將它分為更細的改動來釋出。這樣做的優點是透過將每個部分的技術實作、Use Case Review、Code Review、測試範圍縮小，來降低出錯的機會，避免來來回回修改；另一方面也方便分工，讓團隊持續交付，能在短時間內透明化且直接的看見進度與產出。
【Epic】所謂可以被驗證的最小單位，表示功能並不需要一次完全到位，而是先抓出最核心的使用者故事們，來驗證需求是否真實存在、問題是否值得花資源處理、解法是否符合使用者期待、商業指標是否有相對應的提升等等，蒐集回饋後再來調整下一個階段（Next Phase）要做的事情。
這個驗證單位也有可能只是很小的改動，一張 Ticket 就可以完成；相反的，如果是非常明確的需求，那其版本可能就需要做到非常完整，舉例來說若是電商系統要串接新的物流商，不可能只做到「出貨、取貨」功能而沒有「退貨」流程就上線。
在開始動用工程資源之前，也有許多的驗證方法可以避免我們浪費工程資源走在歧途上。舉例來說：假門測試（Fake Door Testing）、原型測試（Prototype Testing）等等，產品經理的其中一個重要工作就是辨認何時要使用何種工具，降低風險、提升效率，讓團隊一起朝對的方向前進。不過就算上述這些「前期測試」的結果是正向的，也不代表我們已在康莊大道陽光前行，分階段釋出的方法還是很值得使用。
➔ 實作方法 — Feature Flags
我們是用 Feature Flags（功能開關、特性切換）來實作。每一個 Epic 會有一個獨立的 Feature Flag，其下的每張 Tickets 都會被包在其中。我們可以為特定的使用者開關功能 —— 關閉狀態時，前台使用舊程式碼邏輯；開啟狀態時，前台使用新上線的程式碼邏輯。
這種做法允許我們在不影響現有使用者體驗的情況下，一張一張 Tickets 慢慢上線、測試，在正式環境優先開啟功能給內部產品團隊，直至 Epic 內的所有任務都完成開發、內部測試並上線後，再依據要驗證的目標來決定分階段釋出的受眾。
左圖為每一次部署所包含的 Tickets，包含修 Bug、設計改動、小功能等等，同時也會有已經被切分開來的各種 Epic 的部分任務，也就是上篇文章提到的上線管理的範疇。其中，小改動們原則上不需要上線規劃，就是修好、測試完、上線沒問題就行了，再後面就是跟內部團隊的告知與溝通。
右圖則是一個 Epic 與其包含的各種任務，對於大型功能來說，任務的切法其實很仰賴工程師的幫忙，可能會從前後端、頁面、使用者故事 … 等不同角度來切；如果我們要驗證的項目很簡單，也有可能一張 Ticket 就完成改動。
從上圖案例可以發現，我們必須每天上版的原因就是因為同時有多個產品團隊在共同打造產品，每個團隊每天、週或多或少都會上一些東西。如果你的產品使用 Microservices（微服務）的架構，事情也許會簡單一些。
▍分階段釋出：產品受眾
預期的改動都被部署到正式環境後，並不會直接呈現在使用者面前，而是由 PM 來決定如何分階段釋出 — — 先釋出給哪些目標使用者、每個階段釋出的時間間隔、什麼情況下繼續釋出或喊停。
這邊分享一些在不同階段可以使用的工具與測試對象。每個工具的成功/失敗驗證指標、開放使用者人數（比例）、所需經歷的時間因情況而異，這邊就不詳述。
1. 內部團隊 — Dogfooding、Alpha Testing
- 【主要目標】基本品質管理。
- 【實作內容】在正式環境抓 bug、確認基本使用情境下正常運作。
- 【適用時機】任何情況。
這個階段為內部測試，我們通常 Epic 上完就會先開放給公司的人試用，一方面讓大家一起在正式環境抓 bug、另一方面也是讓團隊知道這個功能已經階段性準備好，我們即將開始釋出給真實使用者測試了。
詳細作法可以參考《Dogfooding 101: A Quick Guide to Internal Beta Testing》，我也曾寫過文章分享如何做內部使用者測試《沒有資源做產品的使用者研究？讓我們從內部易用性測試開始！》，跟這邊提到的 dogfooding 有些不太一樣，但依然可以作為正式上線前測試的一種做法。2. 特定使用者 — Beta Testing
- 【主要目標】透過實際產品互動再次探索使用者問題與需求，確認解法方向是否正確，並提前辨認完整上線時可能會遇到的風險。
- 【實作內容】了解目標客群對功能的回饋（質化）、觀察功能的使用頻率與指標變化（量化）。
- 【適用時機】全新功能上線、現有功能/介面/流程改版。
優先釋出功能給一群被挑選的、特定的、可控的使用者試用，從他們身上蒐集回饋、小範圍觀察數據變化，若反應都是正向的則可考慮整體上線、或是進行下一階段測試。
反應是負面的常見狀況如下：
- 小部分釋出後發現根本沒人使用，表示這個功能、解法不一定值得花時間繼續投資；
- 重要指標下降，要深入研究原因再決定是否值得繼續釋出；
- 對於 Phase 1 需要包含的內容判斷錯誤，使用者表示確實有這個問題、解法有解決問題，但現在版本所功能包含的內容太少所以他還不想用、無法給予好不好用的想法（這樣通常就是不好用吧），因此可能要將 Phase 2 的內容包含進來，再重新進行分階段釋出與測試。
回到最上面的流程圖，將每個步驟切小、將一個大個任務切成很多小任務就能夠依照回饋的狀況，決定是否要回到前面研究的步驟重新探索一次、或是回到打造功能的階段做調整。
3. 隨機使用者 — A/B Testing
- 【主要目標】比較舊版本與新版本的指標差異，確認新版本是否有顯著達成目標。
- 【實作內容】將 A/B 版本分別釋出，觀察重要指標的變動狀況（量化）。
- 【適用時機】與現有指標相關的改動上線、現有功能/介面/流程改版。
A/B Testing 的方法則是一種隨機測試的產品實驗方式，將兩個（或多個）版本丟給隨機的使用者，透過系統化變因控制與差異計算，來驗證假設並判斷哪個版本比較好。
通常這兩個版本分別為現有的舊版本（對照組）、開發後的新版本（實驗組），若反應正向就可以考慮整體上線，若反應負面則通常不會上新版本。
這邊分享一些好文作為參考：
以下這篇包含：實驗假設、統計假設檢定、實驗設計與資源配置、實驗分析、實驗結果出爐後的行動方案（顯著與不顯著、反向顯著、不顯著但依舊 100% Release）、不適合 A/B Testing 的情境。以下這篇包含：Leading VS Lagging Metrics、如何挑選指標、成功指標、輸入指標、健康指標。以下這篇包含：成功指標的選擇方法、實驗沒有統計上顯著、實驗失敗了要不要上線、傷害了健康指標要不要上線、如何探索實驗失敗背後的原因。▍產品上線規劃文件
上面談了工作方法與流程，而實際的文件通常包含這些項目：
- 基本資料：名稱、目標、背景與功能簡介、上線內容、正式環境測試連結
- 上線規劃內容：驗證項目、成功/失敗指標、目前所在階段、整體上線規劃與時程
整體上線規劃與時程包含每個階段的釋出時間（時間間隔）、目標使用者（開放人數、開放對象）。例如：
07/01 - 內部測試
07/08 - 第一批 Beta Testing （名單連結）
07/15 - Bug 修復、產品調整
07/22 - 第二批 Beta Testing（名單連結）
07/29 - 確認全體上線與否、全體上線時間每開放完一個階段，蒐集到數字或回饋後，可以適時更新最新狀況；若整個專案要喊停、確認不繼續進行，也要告知團隊原因，以及下一個 Phase 要做的事。
這邊雖然稱為「文件」但他不一定是個獨立出來的檔案，它可以只是一條發給團隊的溝通內容，例如：
- 專門發布上線規劃的 Slack channel
- 內部團隊使用的 dashboard 與公告欄
- 內部團隊共同維護的上線規劃表單
當然，我自己在寫產品需求文件（PRD）的時候，裡面本身就會包含上線規劃的內容。上面提煉出的這個精簡版本主要為了跟團隊溝通使用。
各種產品經理會使用到的文件類型，可以參考 Peter Su《產品經理與牠們的文件》；
在中國似乎會寫一個「上線郵件」來通知各單位，內容可以參考《产品经理：3W1H分析法，教你写好上线邮件》；
關於我對文件的想法，可以參考《如何撰寫產品需求與規格文件？問題、心法與實作小撇步！》。▍目標導向＆假設驅動開發
所有的「上線規劃」都應該在上線前完成，更準確的說，是在前期產品探索至一階段，開始撰寫產品需求文件時就應該一併考慮進去。
在訂定產品目標的同時就開始規劃你的產品上線策略 — — 如何驗證假設、如何挑選受眾，而不是等到產品改動都準備要上線了才開始思考。
假設驅動開發（Hypothesis-Driven Development, HDD）是一種用驗證假設為核心概念的開發方法，將目標拆解成多個問題、每個問題又有多個解法，而每個問題、解法其實都是未知的假設，我們要做的就是想辦法用有效率的方式去驗證這些假設，一邊開發、一邊學習，淘汰掉錯誤的假設與不可行的解法，不斷調整產品設計方向，嘗試在浪費最少資源的情況下，為公司或使用者帶來最大的價值。
既然是假設，就代表我們其實不知道他對不對，隨時都處在「測試階段」「實驗階段」中。 實務上，我們透過這樣的方法降低長遠資源的浪費與潛在風險；心態上，我們不斷在從市場與使用者身上學習與獲取回饋，而這個學習循環週期的時間歷時愈短愈好，代表團隊可以更有效率的調整方向。
Marty Cagan《The Four Big Risks》提到做產品的四種風險分別為：
1. Value Risk (whether customers will buy it or users will choose to use it)
2. Usability Risk (whether users can figure out how to use it)
3. Feasibility Risk (whether our engineers can build what we need with the time, skills and technology we have)
4. Business Viability Risk (whether this solution also works for the various aspects of our business)而在這樣的工作方法中，很難在這個「上線規劃」中交代一個明確的「功能上線時間」。
如果測試結果很失敗，決定東西不上了，要回到前面的使用者研究階段、解法設計階段找其他機會點來優化；也有可能實驗結果不上不下，因此決定針對 Beta 功能做一些挑整後、持續測試，直到我們有足夠信心後再開放給全體使用者。
我相信「不確定的上線時間」讓業務、行銷、客服常常很頭痛，我們在跟他們溝通時通常都是用「季」為單位在討論，也就是「2020 Q3 我們預計會出『跟優化購物車轉換率相關的功能』，而這個專案預計會朝 XXX、YYY、ZZZ 這幾個方向嘗試」這樣模糊的說法。
但相對的，我們有「可控制的發布時間」，不受限於部署當下遇到的問題，而且發布的版本是內部團隊與部分使用者已經在正式環境看過、用過、驗證過的，同時，我們可以從「達成目標」的角度、而非「開發功能」的角度來思考要做什麼，這才是最重要的對吧！
▍結語
這篇文章大致上說明了如何從源頭規劃產品上線，Release、Phased/Staged Rollout、Full Rollout 中間的流程與決策點，以及這種工作方法背後的理由。
講起來很簡單，做起來真的很不容易，文內說明得好像是我們一開始就知道該怎麼做、各種專有名詞與方法論信手拈來，但實際情況是我們不斷修正做事方法，參考網路文章、工具書、其他產品團隊的實務經驗，並且仰賴 DevOps 團隊的努力，最後從一些社群推崇的方法論中嘗試調整成當下適合自己產品、團隊的工作流程。
值得一提的是，公司內不同的產品團隊做事方法依然不盡相同，有些偏技術的專案團隊甚至沒有 PM 而直接由工程師領軍，保持適度的彈性也是很重要的。畢竟有時候難以避免地，有些東西就是非開發不可嘛～～～為了投資人、為了老闆、為了跟競爭對手搶市場、為了跟上時下最夯的話題、為了將底層結構大翻新，或是做給內部團隊使用的工具，可能就不會用這樣的流程工作囉 😎
下一篇文章，我會再分享 Beta Release、Feature Flags 的實務經驗。
感謝閱讀，如果希望看到其他相關的主題也歡迎留言 📔如果單純想給我一點鼓勵，請給我 1–19 個拍手；
如果覺得文章對你有點幫助，請給我 20–49 個拍手！
如果想看更多此類型文章，請長按拍手按鈕（max50）讓我們知道 👏每週末我們都會在 產品三眼怪實驗室 (◉◉◉) 定期更新產品經理相關文章，
別忘了追蹤才不會錯過！
