之前有在板上分享上分享過每天上版的部署流程、單一功能釋出從功能拆解到分階段釋出的概念，這篇文章則會著重分享之前文中提到的 Beta Release、Feature Flags 的使用方法。
主要也是寫給 PM 看的，文章內容包含：
- 適用 Feature Flags 的時機
- Beta Release 的流程規劃
- Beta Release 的受眾選擇、移除功能的做法、測後訪談方向
- 實作 Feature Flags 的工具分享
- 上線規劃如何與其他產品研究方法互補
- 結語＆推薦書單
有圖有排版有延伸閱讀連結 medium 好讀版：
http://a0.pise.pw/SRFCZ
這篇文章的背景為，產品為已在目標市場中穩定發展的網路產品，產品改動都以提供新功能、優化使用者體驗、解決現有使用者問題為主，工作方法以敏捷式開發為主。
▍適用 Feature Flags 的時機
Feature Flags（功能開關、特性切換）是一種軟體開發技術，概念上就是正式環境中有多個程式碼分支，某些特定功能只會出現在特定分支上，擁有最高權限者可以自由地切換新版本給特定使用者，例如：QA、內部團隊、小批量的真實試用者等等，而讓其他使用者預設使用原始的版本。
這種做法允許我們在不影響現有使用者體驗的情況下，一張一張 Tickets 慢慢上線、測試，在正式環境優先開啟功能給內部產品團隊，直至 Epic 內的所有任務都完成開發、內部測試並上線後，再依據要驗證的目標來決定分階段釋出的受眾。
根據上篇提到分階段釋出與驗證的流程中，適用 Feature Flags 的時機包含：
1. 我們確定這功能要做、且規劃完整，或是現有功能的大改版，但功能整包太大，怕一次大上線會出錯（著重在程式碼的分階段上線與測試）
2. 我們確定這個功能要上線，它已經經過測試且各方面回饋都很正向，但是因為改動很大，我們想要讓使用者主動切換並慢慢適應，最終目標是讓所有人切換使用新版本（著重在受眾的分階段上線）
3. 我們不確定這功能值不值得持續花資源做、解法方向對不對、使用者體驗好不好、數據會不會改善（著重在受眾的分階段測試）
第一點很直覺，重點就是 Epic 下各個 Tickets 要怎麼拆解、技術實作、測試。跟第三方服務串接的時候也很好用，可以先開給合作廠商一起做測試。
第二點常見於一些大型軟體改版，例如 iOS 版本升級，使用者要主動選擇升級後才能開始使用新版本。有些產品團隊的作法則是先強制開啟新功能給所有使用者，但允許使用者手動切換回舊功能，例如 JIRA 某次更新版本後，論壇中開始出現各種詢問如何關掉新功能的文章。
讓使用者主動更新與切換至新版本的 Feature Flags 作法很常出現在 B2B 產品中，因為一個產品會有非常多不同類型的使用者，企業端通常會希望做好新版本的內部教育訓練後再來進行。
第三點則可以透過先將功能推給小部分使用者試用，再慢慢擴大範圍，最終釋出給所有人；若中間任一步驟發現苗頭不對，就暫停釋出，根據得到的回饋來修正產品。
這種分階段釋出的做法在中國有一個很傳神的名字叫做灰度發布，亦即有個版本是黑、有個版本是白，我們的產品狀態就在這之間的灰度游移。歐美的命名則是用了一個我比較難理解的名稱金絲雀發布（Canary Release），聽說是以前礦工開礦要放人下去前，會先放一隻金絲雀進去看看是否有有毒氣體，如果金絲雀活下來了，人類礦工才會下去工作。
常見的 A/B Testing 就是這其中一種方法，而我這篇要來分享的是以質化使用者研究與解法驗證為主要目的的 Beta Release、Beta Testing 的方法。
▍Beta Release 的流程規劃
https://imgur.com/a/C8AXoBW
這裡的目標跟假設，可以是針對使用者提出的需求、我們定義的問題、或是實際解法的假設，而對應到這個假設，就需要有一系列的驗證標準，可以是比較模糊的質化目標，也可以是非常明確的量化指標。
量化指標的比較又可以分為同時有對照組與實驗組的「同期比較」，以及同一批使用者在改動前、改動後的「前後比較」。
關於如何設定一個好的目標、合理的指標成長數字，可以參考 Nana Chiang《給產品經理和分析師：如何用指標框架計算產品改動影響力（Impact Sizing）？》中的手把手計算教學與思考框架。
由上圖可知我們通常都會進行多批（Batch）的階段性釋出（Phased/Staged Rollout），每個階段的目的可能相同、也可能不同，並根據每個階段的結果來決定是否要繼續走下去。
舉例來說，第一批鎖定「該功能重度使用者」來驗證功能本身適不適用、使用頻率正不正常，並且會認真的做質化訪談；修改或調整過後，第二批開放給更多潛在重度使用者，遠端觀察數據、使用行為，事情況做質化訪談，同時確認第一批使用者遇到的問題都已經被解決了；第三批則隨機挑選非重度使用者、新使用者來測試，看看是否會有負面影響。當然，也可以反過來操作。
▍Beta Release 的受眾選擇
如果目的是提升整體的指標，從整體使用者中去做隨機分配來做測試就很重要，A/B Testing 會是較好的做法；但如果流量過小（樣本數過小）或是目的是服務特定對象的使用者，就可以試著挑選出特定型態的使用者來測試、同時確認不會傷害到其他型態使用者的體驗與指標。
在 Nana Chiang 分享的《如何在低流量產品中做實驗，做出有品質的產品決策？》中有提到「證據金字塔」的概念，不同形式的證據是不同強弱程度的證明，從高到低代表證據的強到低。樣本數愈多，證據就愈強。
而「群組研究」的研究方法特別適合運用在使用者付費的 SaaS 產品、B2B 產品的場景中。這邊的「群組」可以用使用者樣貌（行銷角度）、參與度高低等方法來分類，以下也分享一些挑選測試受眾時可以切入的其他方向。
1. 友好測試名單
在 B2B 產品中，客戶花錢使用產品，通常會非常願意提供想法。我們曾經有一份約 30 名客戶的「友好測試名單」，包含常抱怨的、常提建議的、我們訪談過的客戶。他們已經習慣我們的產品開發流程，也了解這只是最陽春的測試版本，因此對對於新功能的試用有正確的期待。
我們第一批測試受眾通常就會優先從這個名單中去找尋適合的測試對象，蒐集回饋的當下，也可以避免跟不熟的客戶打交道造成的品牌公關危機。
而 B2C 產品中可以讓使用者主動註冊成為「優先試用」的前導受測者（Pilot Testers），也可以稱他們為早期採用者（Early Adopters）。對他們來說不但可以第一時間得知產品的最新功能，自己提供給產品團隊的建議也有機會被採納，這個群體經營得好的話會是一群很棒的死忠粉絲！
2. 曾經提過需求者
在訪談過需求者，定義完問題後，很多時候我們無法確認我們的解法是否有正中要害，也有很多時候老闆覺得 A 解法比較好、我覺得 B 解法才合理、設計師卻對 C 解法更有信心。
提出需求的使用者有時候也不知道他們真正需要什麼（反正跟你們提提看不花他多少時間），但他們的確是有遇到問題、擁有痛點的使用者，因此先用這種 soft launch 測試的方式來跟曾經提過需求者試探水溫能夠幫助我們後續的決策。
根據想測試的內容不同，大致可以分為兩種做法：
- 第一種是主動告知我們有新功能，包含寄發訊息、或是在介面上明示，詢問、觀察他是否會想要試用、使用情況，同時蒐集回饋與建議；
- 第二種是不主動告知我們有新功能，設定一段觀察時間，觀察使用者會不會察覺到新功能並主動使用、功能使用頻率是否符合預期，最後再來蒐集回饋。
3. 假設下的需求者
我們在設計產品時列出的假設，通常也會包含實際有提過需求的那群使用者所提到的使用情境，因此這邊可以開放給更多雖然沒主動提過、但我們認為會有類似需求與使用情境的使用者來試用。
4. 不能只照顧抱怨者！！！
我早期在設計產品做過一件超雷的事。
當時 A 功能是使用 A1 邏輯，有許多使用者抱怨 A1 邏輯不合理，應該要使用 A2 邏輯才對，因此崇尚「以使用者為中心」的聽話產品經理如我就毫不猶豫地改了邏輯並一次上線給全部使用者。
沒想到我們有一群默不吭聲、且一直覺得 A 功能用 A1 邏輯非常棒的使用者，我們改成了 A2 邏輯後，瞬間被原先滿意的使用者罵到臭頭。而有些人則是用我們沒想過的用途在使用 A 功能，這也是我們沒有考慮到的。
所以在前期使用者研究階段，除了關注大聲抱怨者之外，也要關注一般人，把使用情境想透徹。而在上線之前，除了讓提出需求者測試，也一定要事先開放給未提出需求者、一般人使用，全面性的考慮並確認不會造成負面影響，在風險低、信心足的情況下再釋出給所有人。
【補充】移除功能、淘汰功能
另一種比較特別的使用情境是「移除現有功能」以及「淘汰現有功能、更新為新版」的流程，也很適合使用 Feature Flags 來實作。
相較於上線新功能，移除現有功能更容易造成使用者反彈。B2B 產品尤其嚴重。
最常見的處理方式是將用戶分群，「新註冊用戶」一律使用新版本、「現有用戶、但沒在用該功能者」強制切換至新版本並發送簡單通知、「現有用戶、有在用該功能者」則分批次分階段通知客戶、細心處理資料移動（migration），並預留一段較長的時間慢慢讓所有人有心理準備並順利轉換，這段時間也要把想要備份資料的、吵著要換平台的客戶都安頓好。
▍Beta Release 的使用者分類與測後訪談方向
無論是上述哪一種類型的 Beta 使用者，在測試後期大致可以分為三種類型。這三者的回饋都需要蒐集，並且觀察比例，了解最大的問題到底出在哪個環節、有什麼有價值的切入點可以推進產品。
1. 有開始試用、且有持續使用新功能（Active Users）
- 為什麼使用此功能、使用情境為何、帶來的價值如何？
- 這個功能或解法還有什麼優化的空間？（次要問題）
2. 有開始試用、但沒持續使用（Abandoners）
- 既然有起心動念試用，為何最後沒繼續使用？不滿處為何？
- 是否有與此功能相關的問題或痛點？若有，目前如何解決？
3. 根本沒發現有新功能、有發現但沒開始試用（Non-starters）
- 是否有發現平台上有新功能？（適用於我們沒有主動告知的情境）
- 若有，為什麼沒有開始試用新功能？
- 是否有與此功能相關的問題或痛點？若有，目前如何解決？
▍實作 Feature Flags 的工具分享
Feature Flags 可以由內部技術團隊自行實作，或是付費找外部的 SaaS 工具協助。
技術團隊自行實作可以參考 Etsy — Feature API、Reddit’s feature flagging API等團隊的文件，包含全開、全關、開給特定使用者、開給一定比例使用者、A/B Testing 等等不同類型的釋出條件。也可以參考這篇長文《Feature Toggles (aka Feature Flags) — Pete Hodgson》的內容。
至於如何找特定受眾呢？如果是技術團隊自行實作的話，可以使用一些追蹤工具來調出特定使用者行為或分類下的使用者 ID，或是透過客戶管理工具（CRM）、客戶溝通與回饋蒐集工具（例如 Intercom、Zendesk、Canny、Kustomer）來撈出曾經提出特定回饋或需求的客戶名單，再利用上述的 Feature Flags 實作方式開啟給這些名單來搶先試用。
外部工具的部分，做產品優化與測試的工具中 Optimizely 算是滿廣為人知的一個平台，產品功能很全面但價位也較高；LaunchDarkly 也是一個專注在上線管理與功能管理的產品，另外也可以參考 APPTIMIZE、Rollout、Centercode 等等。
如果想要了解 Feature Flags 可以在哪些情境下使用，我很推薦看看上述這些工具的部落格（例如這篇），裡面除了概念性、功能說明的文章外，也會有些實際案例可以參考。
而最後當某個版本已經釋出給所有使用者後，表示 Feature Flags 的階段性任務完成，必須將它拔掉（或說退休），讓正式環境未來都直接使用新版本的程式碼，否則長久下來會累積許多切換負債，這也是技術債的一種。
我知道有些團隊會將 Feature Flags 當成一個永久的功能給內部團隊使用，例如讓業務團隊可以特別開啟某些進階功能給 Key Accounts 使用，若是這樣則需要建立明確的權限管理守則。
▍上線規劃如何與其他產品研究方法互補？
Beta Release 就是社會的縮影。它是使用者研究的一環，可以補足其他使用者研究沒辦法探索到的問題。
前期使用者訪談，我的訪談技巧可能也沒有好到覆蓋所有可能的探索方向，有時候是使用者在啟發與引導我們做產品、有時候是我們在啟發使用者的想法、激盪出新的使用情境；製作 prototype 的階段，使用者看上去滿意，禮貌性比個讚，甚至提出更多進階功能想法，但這一切有時候也不是真實的。
有時候驗證東西就是要花時間。經過一段時間的試玩，使用者才知道他喜不喜歡、上不上手；又或者，使用者自己一個人在電腦前嘗試時，剛開始用兩下便覺得太複雜或沒興致，因此只試用了一次就晾在旁邊放棄；更甚者，這個功能從擺在架上的最一開始就無法吸引他的注意力，當然也就無法驅使他開始使用。這些有時候是單純訪談、測試 prototype 中很難得到的資訊，還是得實際試車才能見真章。
數據相對的不會騙人，而在得到一翻兩瞪眼的驗證數據後，能夠抓出這些我們最初的「錯誤假設」，再次透過質化研究來了解背後的原因、蒐集資訊、調整命題，才能有信心地推出調整過、優化過的產品。
有趣的是，有時候客戶抱怨連連、回饋一堆、激動不已，但是口嫌體正直、嫌貨才是買貨人，數據反映出來的卻是新功能的使用頻率高，這可能代表我們其實已經走在對的道路上，只是還有很多可以改進的地方。產品釋出之後所做的改善才是最有價值的。
▍結語＆推薦書單
這幾篇文章分享的心態與做法都是一種以顧客為中心的開發方法（Customer Development），而工具真的有千千百百種，我也還在努力理解各種方法論、學習什麼時機點應該用什麼工具來抽絲剝繭、撥雲見日，希望這一系列的上線管理與上線規劃的分享對各位有幫助。
常見的產品開發方法論通常都是雙鑽石（Double Diamond），而最近 Zendesk 提出了三鑽石（Triple Diamond）的流程，不知道大家覺得如何？（Ref: The Zendesk Triple Diamond）
產品方法論推薦書籍：
《精實創業 The Lean Startup》
《使用者故事對照 User Story Mapping》
《產品專案管理全書 INSPIRED》（作者來台演講內容繁中筆記）
數據、實驗、假設推薦書籍：
《精實數據分析 Lean Analytics》
《善用數據幫你打造好設計 Designing with Data》

7ㄟ ㄅ推推