在 《#067 上線不是按個按鈕就好》，我們走完了停機維護的流程，系統也重新對外開放。很多 PM 看到首頁正常載入、核心流程看起來可用，就會自然地鬆一口氣，覺得這一輪發布總算結束了。
但實務上，真正的考驗，往往是從重新開門的那一刻才開始。因為只要真實用戶進來，系統面對的就不再是內部測試帳號，而是各種真實裝置、真實網路條件、真實操作習慣，以及真實的不耐煩及客訴。
上線後的前 6 個小時，通常是整個產品週期裡最混亂、資訊量最大，也最容易讓人做出錯誤判斷的一段時間。這時候 PM 面對的，其實是兩個戰場。一個是機器發出的訊號，也就是技術監控。另一個是人發出的訊號，也就是營運回報與客服聲音。
若事前沒有建立基本的應對機制，這 6 個小時很快就會演變成一種熟悉的失序狀態。客服急著要答案，PM 急著找 RD，RD 忙著看系統、查log，所有人都很忙，卻沒有人先把問題分清楚。這篇文章要談的，就是 PM 如何在這段時間裡，把混亂轉成可判斷、可分流、可處理的資訊。
◆ 戰場一。技術團隊的成熟，不是等客訴，而是讓系統來跟你說
很多團隊判斷「系統有沒有壞」的方式，仍然停留在很被動的層次，也就是等客服回報。這種做法最大的問題，不是慢，而是你永遠比問題晚一步。
當客服已經接到 5 通電話說無法結帳，通常代表真正受影響的人數遠不只 5 位。系統可能已經異常一段時間，而團隊直到電話進來才知道出事。這種判斷方式，在正式營運階段風險很高。
比較成熟的做法，是讓系統自己先說話。PM 不需要親自看 Log，也不需要自己盯監控圖表，但你必須知道團隊是否已經建立最基本的主動監控機制。因為正式上線之後，真正可靠的，不是誰反應快，而是能不能在使用者情緒升高之前，就先看到異常訊號。
◆ 監控的基本盤，不是只看網頁能不能打開，而是看系統是否仍在安全範圍內
正式上線之後，至少有幾類指標應該被持續觀察。
第一類是網路流量。流量突然高於預期，有可能是活動轉換超出估計，也有可能是異常攻擊或爬蟲行為。這類情況若沒有先被看見，後面所有效能問題都會被放大。
第二類是 CPU 與記憶體。系統有沒有異常資源消耗，這裡通常最誠實。尤其是記憶體若持續上升、不釋放，往往代表程式內部存在明顯風險。前台可能只是慢了一點，後面其實已經在累積系統性問題。
第三類是資料庫負載與連線數。很多畫面延遲，表面上像是前端問題，實際上是查詢過慢，或資料庫連線被耗盡。若沒有同步看到這一層，PM 很容易把問題方向判斷錯誤。
第四類是硬碟空間。這是很常被忽略，但也很實際的風險。系統一上線，錯誤日誌大量累積，短時間內就可能把空間吃滿。等到服務真的停住，現場才會發現問題並不複雜，只是沒有提早看見。
第五類是錯誤率。例如 HTTP 500、特定 API 錯誤比例異常上升，或某一段核心流程的失敗率突然增加。這些數字不會告訴你完整原因，但會明確提醒你，問題已經開始發生。
真正重要的是，團隊不要把這些指標停留在「有人有空再看一下」的層次，而是要有明確的警戒值與告警機制。
還有一個隱藏的陷阱，由於現在很多服務都是透過AWS或GCP的服務，而在這些雲服務中，為了可以有效的承載瞬間的流量，往往會考慮設計「Auto Scaling」的機制，也就是自動擴展，這是一個方便的設計，如果受到攻擊，則有可能會讓伺服器一直處於高檔，最後還是會承載不住而造成異常。過去就有過類似的經驗，導致伺服器一直被擴展，當然也有做監控，卻也是造成不少的損失，不可不慎。
◆ 監控不能只做儀表板，還要讓系統主動通知你
很多團隊的監控系統做得很完整，但實際上沒有人會一直盯著看。這也是為什麼光有儀表板並不夠，還需要閾值告警。
例如，當 CPU 持續 3 分鐘高於某個門檻，或結帳 API 連續出現異常，系統就自動把訊息發到指定的 LINE 群組或 Telegram 頻道。這樣做的意義不在技術炫耀，而是在問題剛開始形成時，就讓團隊有機會先介入。
這一層處理好，PM 才不會永遠是最後一個知道出事的人。
因為正式營運真正需要的，不是等使用者憤怒之後再處理，而是讓團隊在使用者開始失去耐心之前，就已經知道哪裡異常。
◆ 戰場二。營運與客服的聲音很多，但不是每一種聲音都代表同一件事
若說監控是在看系統，那客服與營運的回饋，看的就是人。問題在於，上線第一天，使用者很少會主動說「你們這次做得很好」。大量湧進來的，多半是抱怨、不習慣、找不到、看不懂，甚至只是單純的不耐煩。
PM 在這個階段最常見的錯誤，是把所有抱怨都當成同一層級的問題。這樣做的結果通常很糟，因為你會在最混亂的時間點，把本來應該分開處理的事情，全部混在一起要求團隊立刻回應。
所以，真正重要的不是「有沒有客訴」，而是你能不能先把回饋分成不同類型。
◆ 這是習慣改變帶來的反應，還是真正的功能缺陷
只要介面改動，不管改得多合理，第一波都很容易出現抱怨。因為使用者對介面的反應，很多時候不是功能判斷，而是習慣被打斷後的直接反射。
這類回饋通常會長得像這樣。
「以前比較好找。」
「按鈕怎麼換位置了。」
「顏色怎麼變了。」
「我找不到以前那個地方。」
這些聲音不能忽略，但也不能立刻等同於設計失敗。很多時候，它代表的是使用者需要重新熟悉，而不是系統真的不能用。這類情況比較合理的做法，通常是先補操作引導、FAQ、圖文說明，再觀察幾天數據與回饋是否自然下降。
但若使用者反映的是另一種問題，例如流程中斷、資料遺失、閃退、付款失敗、登入失敗，這就不是習慣問題，而是真正的缺陷。這類問題不需要再觀察，必須立即進入處理程序。
PM 若沒有先把這兩種情況分開，接下來所有判斷都會失真。
◆ 面對情緒，不要急著改，先用數據確認問題的性質
有些回饋聲量很大，但未必代表方向錯了。這也是 PM 在上線後最需要保持判斷力的地方。
例如客服回報很多人說新版搜尋不好用。這時候若只根據情緒強度就要求改版，很容易做出過度反應。比較穩妥的方式，是先回頭看數據。搜尋使用率有沒有下降。搜尋後的點擊率、轉換率是否變差。使用者是否中途離開。若抱怨很多，但核心數據沒有明顯惡化，問題可能比較接近操作習慣改變，而不是功能本身失敗。
相反地，如果聲音不大，卻伴隨明確數據下滑，那往往更值得重視。因為不是所有會造成傷害的問題，都會立刻被大聲抱怨。
所以，情緒不能忽略，但情緒本身也不應直接變成決策。
數據與回饋，必須放在一起看，才比較接近現場的真實狀態。
◆ 上線後最重要的工作之一，是把所有回報整理成可處理的清單
系統剛上線的前幾個小時，來自監控、客服、營運與內部同仁的訊息通常會非常多。如果 PM 沒有先做分類，這些訊息很快就會變成一種資訊壓力，讓團隊持續被細碎問題牽著走。面對持續不斷的通知訊息，你也會不知道該怎麼辦。
比較有效的方式，是盡快把回報整理成幾個層次。
第一類是 Hotfix 緊急修補。
這類問題通常影響核心流程，例如無法登入、不能下單、資料錯亂、付款失敗，或直接影響營收與正式服務。這種情況不應排進下一輪再說，而是要立即處理，必要時切出緊急修補版本。
第二類是 體驗優化。
系統本身沒壞，但文案不清楚、位置容易誤解、操作容易誤觸，這些問題會讓使用者不舒服，也會增加客服負擔。它們重要，但不一定要在當天立刻修。這類問題更適合整理後排進下一輪小版本優化。
第三類是 新需求。
有些使用者會在新版上線後提出很多新的想法，例如希望多一個功能、支援更多條件、提供另一種操作方式。這些聲音很有價值，但它們不應該在上線後的混亂時段直接進入實作。比較合理的做法，是進需求池，成為後續版本規劃的材料。
PM 在這裡真正重要的能力，不是立刻回應所有訊息，而是把不同性質的問題先分開。
因為一旦分類做對，團隊的資源就不會被錯放，真正需要當下處理的問題，也比較不容易被埋掉。
◆ 廣三觀點
嗨，我是廣三。
很多 PM 會覺得上線完成之後，真正累的部分已經結束了。但我自己的經驗剛好相反。系統重新開放之後，才是 PM 最需要保持判斷力的時候。
因為這時候進來的訊息，不只是多，而且很雜。監控數字會跳，客服會回報，營運會緊張，工程師也會在觀察系統。你若沒有先把訊息分類，很快就會掉進一種大家都很忙、卻沒有真正處理到問題的狀態。
所以我一直很在意一件事。上線後的前 6 個小時，PM 的角色不是去放大焦慮，而是把問題整理成可以處理的順序。哪些是系統穩定性問題，哪些是使用習慣轉換帶來的反應，哪些要立刻修，哪些先記錄下來。你只要把這一層做對，整個團隊就會穩很多。
產品正式上線，不代表工作結束，而是正式進入市場驗證。這一段如果處理得好，第一波混亂就會變成後續優化的基礎。反過來說，如果這一段沒有處理好，原本可以修的問題，也很容易在情緒與誤判裡越變越大。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言