決定釋出日期前，記得要考慮上架平台
「那麼釋出日程呢？」
「日程？沒有這種東西，我們就是每次開發完就釋出。」
「不決定特定日期，完成就釋出嗎？所以沒有熱修復(Hotfix)的概念嗎？」
「對，就是完成開發與測試後就立刻釋出。」
剛轉到Korbit任職時，我問了一位外國工程師關於釋出日程的問題，但Korbit似乎還沒有這樣的制度。
所謂「釋出」，是指開發完成後經過產品的品質或功能測試(Quality Assurance, QA)，如果被判定是完成狀態，就意味著可以提供給顧客使用。所有開發的終點都是釋出，如果是新產品的話，釋出日期就會被稱為上市或公開日期。
然而， 不分時刻地「釋出」具有風險 。如果是大規模的產品，就很可能發生多個團隊同時嘗試釋出，如此一來會增加發生技術性問題的可能性。每次發行都會有新的程式碼版本，如果沒有依照特定週期，而是有需要就釋出，那麼連版本管理都會變得很費力。除此之外，在沒有充分告知顧客的情況下，就隨時改變功能和設計，會使顧客體驗難以保持一貫。
決定釋出週期對各方面都很有幫助。一般會建議兩週定期釋出一次，因為大部分的Sprint都是兩週一個週期，在Sprint結束當週的星期四發行會比較安全。
這是因為，安排在星期四釋出的話，假如釋出後發生問題，還可以利用星期五進行修正。這是確保Sprint結束之前，能有最多開發時間，又同時保有後續修正時間的理想排程。
如果在Sprint中途發現目前的產品出現問題，且必須要盡快解決時，緊急修正後發行穩定版本的動作被稱為Hotfix（熱修復）。理想情況下，應該在每兩週一次的固定釋出週期中間的星期四釋出Hotfix。如此一來，我們就可以把當週需要修正的內容放入Hotfix的版本，來不及的話，就還是可以在固定的釋出日期釋出。
但如果是非常緊急的狀況，就要馬上進行Hotfix。我們一定會遇到必須要忽視釋出排程，直接套用修復版本的情況。這種時候，PO要跟開發團隊討論好再做決定。如果是會嚴重影響顧客體驗的問題，最好就要立刻修復。
決定釋出日程的時候，也應該把要上架的平台納入考量。 一般來說，產品主要可以在安卓、iOS、PC等三種平台上使用。PC平台上使用的產品，大部分都是網頁形態，可以透過瀏覽器連接使用，所以釋出日程相對自由。只要新版本釋出，顧客在連接到瀏覽器的瞬間就能看見新功能，因此開發團隊只需要協調好釋出日期，也不需要透過任何機構驗證。
但是，安卓或iOS的情況就有點不同了。安卓相對來說非常自由，當新版本一釋出，幾乎就可以立刻從Google Play上下載或更新了。經營iOS系統的蘋果則相對保守，如果要釋出新版本，就必須先經過蘋果檢驗，沒辦法立即推出到顧客面前，且必須獲得蘋果APP Store允許才能下載或更新。
想要推出同樣的功能到顧客面前，安卓與iOS APP的釋出日程肯定會不同。
一般來說，安卓只要根據每兩週一次的固定釋出週期來更新就好；但是，iOS就必須考慮APP Store驗證的時間來抓釋出日程。
韓國的安卓使用者較多，因此可以先上傳安卓APP，等幾週後再上傳iOS APP。先解決安卓發行後發現的所有問題，也有助於穩定應用在iOS版本上。
PO不可以因為急於想推出新產品而隨意決定釋出日程，遵守以下幾點原則的話，會很有幫助：
・先確認開發團隊是否有決定好釋出日程或程序
・如果需要跟其他團隊合作，要盡快事先討論好釋出日期
・盡量不要在深夜或星期五釋出
最後一點原則非常重要。如果只是因為要遵守時程而在深夜釋出，為了要確認狀況或預防問題發生，負責組員就需要留守到很晚，或是需要一兩個人留下來觀察。無論對PO，或對開發團隊都會造成不便。如果選擇在星期五釋出，也會遇到類似的問題。倘若星期五下午釋出的版本出現問題，除了星期五，連星期六都有可能要繼續處理問題。如果時間拖到太晚，不妨就延期至隔天；如果是星期五，就延期到星期一吧。
某些產業中，有些事項必須要告知顧客。舉例來說，因為金融科技產業受公共金融機構規範，如果要追加或刪除某項特定功能，就有義務要在7到30天之前告知。即便沒有告知義務，套用新功能時，為了避免造成顧客困擾，也可以考慮事前公告。在這種情況下，就要先跟負責告知和公告的法務部、客服中心等討論，考量他們的意見後再決定釋出日期。
有些公司可能會禁止在使用率或銷售量激增的時期改版。因為在這個時候釋出新版本，如果發生技術問題，反而會造成大量顧客的不便。公司也可能會考慮在春節、中秋或年底等特定期間禁止改版。若以外送服務為例，由於訂單量會在特定時間內湧入，因此也可以避免在該時段釋出新版本。而遊戲、加密貨幣交易平台則是從晚上到凌晨之間的使用率最為活躍。因此，建議可以考量每個產品的使用率高峰期，避免在該時段釋出新版本。
在產品上線之前，PO要考慮的事情非常多；根據各個平台排定日程、應對可能會發生的問題、事前通知等，PO要做足許多準備。安排好固定的釋出時程雖然會有幫助，但為了解決突發問題，也要盡可能決定好Hotfix的釋出日程。
雖然PO都很希望能盡早推出新功能，但是，為了提供良好的使用體驗，PO要隨時隨地與開發團隊和其他部門討論，盡可能有計畫地安排好釋出日程。
運用A/B測試分散流量
「預計B組會在一天後從5%調升至20%。」
「好的，我會從數值達到5%的時候開始監控。」
「我也會持續觀察數值，假如系統有什麼異常的話再通知我。」
推出新版UX的當天上午，我在Scrum會議上向開發團隊宣布後續計畫。我們已經完成發行，我選擇了慢慢釋出新設計的方法。
就像我們前面提到的，如果公司有A/B測試平台，就可以分散使用者流量。
所謂的「流量」(Traffic)，指的就是使用產品的使用者。通常我們會用下述的方
式分散流量：
A組：不適用新設計或新功能的使用者
B組：適用新設計或新功能的使用者
一般來說，A、B組是隨機劃分的。這樣一來，以後要比較各組數值時，才能獲得有意義的統計結果。我會在後續章節再詳細說明A/B測試。
某些情況下，B組也可能是由人為方式劃分的。如果只想先向VIP顯示新版本，就可以利用使用者ID或手機裝置的識別號碼將其編入B組。另外，如果想先以公司內部員工進行驗證，就只要把他們納入B組即可。
發行新設計或新功能之後，就立刻讓所有使用者使用，是很危險的。當然，有時也會因為有法律義務，而必須要在特定日期同步推出。在Korbit時，也曾因為要遵守金融機構的規範，必須得在特定日期推出新功能。
但若是一般情況下，就建議循序漸進地提升曝光率，先針對少數人釋出，如此一來便可以觀察系統或公司銷售等數據，檢視新功能會不會造成負面影響。假設出現問題，就可以將B組關閉，讓流量全數聚集在A組，這種方式被稱為開關(On/Off)轉換。
當我要分階段釋出一項功能時，通常會遵循以下時程：
A組 B組
第一階段 95% 5%
第二階段 80% 20%
第三階段 50% 50%
第四階段 20% 80%
第五階段 0% 100%
前兩天先漸漸確認狀態，先投入5%的流量在B組，對他們推出新設計或功能，這代表實際產品使用者中有5%的人會有與現在不同的體驗。
最多可以花費一天的時間檢討各項數值，觀察B組的使用率有沒有銳減、人均銷售量有沒有減少、系統錯誤率有沒有提升等問題。如果沒有特別的狀況，隔天就可以把B組的人流提升至20%，接著再花一天的時間觀察相同的數值。此時也要跟客服中心合作，確認顧客發問或客訴案件的增加率。如果客訴明顯增加的話，代表其中可能含有開發團隊沒有意識到的問題。
如果前兩天都沒有發生問題，第三天開始就可以把A組和B組分為50 : 50，讓一半的實際顧客使用新的設計或功能。從這個時間點開始，為了取得有效的統計分析樣本，至少要維持該比例7天以上。PO在這段時期也要隨時隨地確認數值，因為中間也可能會有突發狀況，所以千萬不可以掉以輕心，要保持警戒持續觀察。
即使這段時間沒有發生問題，我也不會立刻把B組調成100%。我會花至少3天左右把比率調成80%，再確認一次數值，因為B組流量快速增加時，可能還會發生無法預期的問題。
經歷所有過程、約莫兩週以後，我才會將新設計或新功能釋出給所有顧客。像這樣經過逐步反覆的驗證後，再上線新設計或新產品，會比突然完整上線給所有顧客要來得更加穩定。
如果遇到無法像這樣分組分散流量的狀況，就只能保持警覺。遇到技術問題，或是基於其他法律義務因素，而必須立刻100%上線時，PO必須隨時準備還原。
所謂「還原」(Rollback)，是指降回以前的版本，還原時會選擇以前營運下來最穩定的版本。還原後，還要再經歷一次確認問題、修正問題、重新發行的過程。
為了承擔這些風險，PO必須要跟開發團隊協調，建構可以分散和調整流量的環境。A/B測試非常重要，因此運用A/B測試平台最有效率，後文會再詳細說明。
推出新設計或產品的時候，PO要盡可能避免100%這個數值。如果是使用者數量非常多的服務，100%適用帶來的風險會更大。我們必須要循序漸進地釋出，確認各項數值，以穩定的方式適用新設計或新功能。比起盡快推出產品，推出穩定的產品會帶來更好的顧客體驗。
本文授權轉載自《產品負責人實戰守則：從洞悉顧客需求，到引領敏捷開發，韓國電商龍頭頂尖PO教你打造好產品的決勝關鍵》，三民出版
責任編輯：林美欣
