這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
什麼時間點適合把產品推上線？
「上線」聽起來簡單，但是該在幾月幾號的幾點把產品功能推上線呢？
通常產品功能的上線，都是要配合某個節慶或特殊時間點。比如做了一個聖誕節活動的促銷頁，那當然就是要配合行銷團隊的檔期，看活動什麼時候開始，是否需要提早把網頁推上線做預熱活動等；又或者公司可能剛好有一些公關時間點，比如公司創立 X 週年、募資成功、宣布要 IPO 等，可能也會有對應的功能要公佈，那就是搭配公司整體的戰略規劃。
除此之外，產品上線的死線多半也是看需求端要求。比如我在做的企業內部工具之一是績效考核系統，公司的各個事業體都有各自的年終考核時間，那就得在考核開始前，先把加好的功能推上線，這樣等考核開始後，各單位就能順利使用。
有了日期後，那怎麼決定具體的時間點呢？
1. 避開用戶的高峰使用時間
即使不是產品經理，平常身為用戶時，應該可以發現許多網站的維修或維護的時間都在半夜。舉例來說，各大銀行、金流平台或網購平台的公告為了減少對於使用者的影響，辛苦的工程團隊通常會在流量低谷（通常是半夜）進行系統升級或維修。
像我前公司在做線上學習，其中有一條主力產品是財經訂閱的內容，平日早上九、十點開盤後，網站的流量就會明顯竄升，直到中午收盤後，流量才會慢慢降低，所以一般來說，白天與平日就不會是一個理想的停機時間，也不適合把東西推上線，因為一旦出問題，將會影響到大多數的用戶。
2. 傍晚不上線原則
必須老實說，這個「傍晚不上線」不是一個「通則」，比較像是我自己會盡量遵守的原則。現職公司的上班時間大約是 09:30~19:00，正常情況下，我都會要求工程團隊在下午五點前把東西推上線，五點之後就不要再動作了，寧可等到隔天一早再做。
如果傍晚把東西推上線，出問題的話，大家只剩兩三個小時可以修，而且有時候不一定能馬上找到問題，即使找到問題，也不一定馬上就有解法，所以很可能耽誤到大家的下班時間。
簡而言之，為了不加班，我自己很少在傍晚推東西；不過，也有同事秉持著「今日事今日畢」的心情，即使表定七點下班，還是堅持要在六點半推東西，但反正只要團隊沒有特別的意見，這麼做也沒什麼問題。
3. 週五不上線原則
承上，應該可以看出我是個很不想加班的 PM……所以我通常在估時後，也不會把上線時間訂在週五（或者當週最後一個工作日）。即使是週五推上線，下午也很可能會有緊急的 bug 要處理，甚至週末也可能接到用戶反應有問題，那週六日的清閒就毀滅了……
不過，再次強調，上一段以及這一段的原則純屬個人偏好，真實情況可能因產業特性（比如只有週末是流量低谷，平日早晚都不適合推上線）或其他因素而異。
上線之後
產品或功能上線後，建議 PM 可以主動一點，一是主動宣布上線，不論是公佈在公司群組還是告知需求端、告知用戶等，都可以算是一種「主動」。一方面可以幫辛苦的團隊刷個存在感，趁機感謝一下大家；另一方面也可以給需求端或用戶一些信賴感，讓他們知道自己的需求有被聽見。
第二個主動的做法是，可以自己先去使用新功能或者趕快收集使用數據，看一下新功能有沒有什麼問題、有沒有用戶開始在使用了、用戶是如何使用這個功能等。萬一有問題，PM 在第一時間發現，總比用戶來抗議來得好；如果發現沒什麼人用、或者大家使用的方式不如預期，也可以再跟團隊是否要做什麼調整。
萬一出包了
上線之後，最理想的狀況當然就是風平浪靜～天下太平。但更常見的情況恐怕是以下這兩種：
1. 緊急修 bug（hot-fix）
即使上線前做了很多測試，但上線後不知怎地，就是會遇到一些意料之外的 bug。如果是影響範圍較大或者較嚴重的，當然就要請工程師或設計師趕快處理。
如果是比較輕微的 bug，我自己的習慣是，會把這些輕微 bugs 集結起來，統一放在下一個版本一起修復、測試並上線。
2. 緊急回復到上個版本（rollback）
另一種比 hot-fix 更可怕的情況是，上線之後很多功能（甚至整個產品）就……爛掉了。這通常是技術端遇到一些難解的問題，評估後認為短時間難以修復，所以只好選擇 rollback，意思就是將產品回復到上一個版本的樣貌與內容。
上線後遇到好多問題……為什麼？
上線後，不代表這整個產品的工作流程就結束了，也不代表下次又得從頭開始；反之，應該要把每一次的開發、優化和迭代都當成一次經驗，從中萃取出好的與不好的學習，並作為下次改善的參考。
所謂的「不好」，可能是實際上線時間跟預計的不符，也就是上線時間延誤，原因可能是來自於開發過程中各種不順，比如溝通有落差、設計稿一直變動、需求也變動等。關於這些「不好」、這些「問題」，不一定有一個 100% 適用於所有團隊的解法，所以個人很建議的是，在團隊完成開發與上線後，一定、一定、一定要開一個回顧會議 / 檢討會（retrospective）。
這個 retro 的目的不是要抓戰犯，也不是只講不好的地方，而是要知道團隊哪裡做得很好、哪個環節出問題，並且趁機集思廣益想解法，作為之後的參考，這樣才能從錯誤中學習，而不是讓同一批人下次再去踩一樣的坑。
關於 retro 的流程，留待之後再細講。
結語
兩個月的時間，終於把「如何改善產品？功能優化怎麼做？」這系列共 10 篇文章寫完了……希望對於「好奇 PM 要怎麼把一個功能做出來的人」以及「剛接手新專案、不知從何開始的新手 PM」都有些幫助。
如果有任何問題、建議和心得，也歡迎留言、私訊或寫信交流。
