◆ 多數時候，你接手的不是產品，是歷史

在軟體世界裡，
PM 很少有機會「從 0 到 1」打造新產品。

更多時候，你接手的是：

跑了十年的平台、
寫在某個已停產框架上的系統、
只敢重啟，完全不敢升級的老服務。

版本舊、框架舊、語言也不是現在主流。
懂這套技術的人，要嘛退休、要嘛變顧問，
偶爾出現一個，報價高得像傳說生物。

但偏偏，這套系統還活著：
會員、訂單、金流、合約、歷史資料。

沒有人敢說關就關，
大家只能小聲地補一句：

「先讓它再撐一下。」

◆ 先別談重寫，新舊系統其實有三個階段

說實在的，
「全部重寫」這句話誰都會講，
但輪到你報預算、排人力、估風險，
你就知道那不是一句口號。

現實世界比較像這三個階段：

  1. 先維持活著就好
  2. 將沒人在用的功能關閉
  3. 保留關鍵資料，慢慢換一個新系統

不一定要照順序走，
有時候會交錯在一起。

但只要你腦中有這三個層次，
你就不會再陷在那種：

「又想全新開發，又不敢關掉舊系統」
的拉扯裡。

◆ 階段一：先確認這個病人還活著，能穩定呼吸

很多老系統，一開始你的任務很單純：
不是優化、不是改版，
而是——不要讓它今天掛掉。

這種時候，PM 要先幫自己換一個心態：

短期目標不是「變好看」，
而是「努力活著」。

你會做的事情比較像是：

  • 把最容易爆的功能先標出來
  • 先凍結大規模改版，只允許必要修補
  • 跟老闆說清楚：這一階段是「裝呼吸器」，不是「動手開刀」
  • 能加監控就先加監控，能補 log 就先補 log

工程師會抱怨系統有多爛，
你也知道它真的很爛，

但在還沒談「進手術室前」之前，
至少先幫病人戴好氧氣罩。

這不是在拖時間，
而是在買「討論未來」的空間。

◆ 階段二：從沒人用的地方開始，讓功能好好退場

要優雅地下架功能，
絕對不是某天心血來潮，
直接在會議上說：「這個我們乾脆關掉。」

那樣一定會有人跳起來說：
「如果突然關掉，會不會連動到甚麼關鍵系統，我們並不知道。」

比較務實的做法是：

  • 先用數據看「幾乎沒人用」的功能
  • 再問客服、營運：「最近一年有沒有人真的靠它活著？」
  • 確認有替代方式（手動流程也算）
  • 確認沒有法律/合約上的硬性要求

然後，幫這個功能安排一場「小型告別式」：

  • 先內部溝通：客服、業務、營運要先知道
  • 再對使用者公告時間表：
    「某某功能將於 x 月 x 日下線」
  • 在畫面上加註記：
    「此功能即將關閉，請改用 xxx」
  • 下線後，預留一段觀察期，看會不會有人來敲門

重點不是「偷偷關掉」，
而是讓受影響的人：

有時間適應、
知道替代方案、
理解為什麼要關。

功能會被忘記，但情緒不會。
能被平靜接受的下架，
通常都不是突然發生的。

◆ 如何不引發暴動？順序比理由重要

很多 PM 以為，
避免使用者暴動的關鍵在於「理由要講得很漂亮」。

其實更關鍵的是「順序」。

錯誤順序長這樣：

  1. 先關功能
  2. 大家發現不能用
  3. 客服被罵爆
  4. 你開會解釋「我們是為了系統長期發展」

正確順序比較像：

  1. 內部先對齊：為什麼要關、會影響誰
  2. 找得到名字的人，一個個先講（大客戶、重度使用者）
  3. 公開公告，清楚寫原因與替代方式
  4. 在畫面上持續提醒，讓使用者有時間搬家
  5. 正式下線，預留一段可以「反悔」的緩衝期

理由可以很坦白：

「這個功能使用率已經很低，
但維護成本很高，
我們決定把資源集中在 xxx 上。」

重點不是說得多冠冕堂皇，
而是讓對方感覺到：

你有評估過、
你有在乎他們、
你不是一個按鈕就把他們多年的習慣刪掉。

◆ 階段三：關鍵資料不動，讓系統有重生的機會

真正痛的，是走到這一步：
要不要重寫？要怎麼重寫？

這時候有一個原則很重要：

先鎖定「不動的資料」，再談「要換的系統」。

通常不能動的關鍵資料表，大概就是：

會員資料、
訂單資料、
交易紀錄、
帳務相關。

你可以把它們想像成一棟老房子的「地權」。
房子可以重蓋，
但地在哪裡、屬於誰，不能亂動。

新系統可以從這些資料結構往外長：

  • 先確認欄位是不是夠用，必要時加版本號、加 Mapping
  • 思考要不要做中介層，讓舊系統和新系統都能讀同一份資料
  • 安排一段「新系統、舊系統同時運行期」，兩套系統一起跑，同時觀察風險

這個階段一定會很累。
你要同時面對：

舊系統的情緒、
新系統的不穩定、
老闆對時程的焦慮、
團隊對未知的壓力。

但只要核心資料模型被想穩，
就算第一版新系統有問題，
你至少還「回得去」。

◆ PM 的難題：大家都想做新專案，但多半在幫老系統擦背

說句實在話，
每一個 PM 心裡都有一個「想從 0 到 1」的夢。

但現實工作裡，
更多時候是：

幫一個十年前的系統續命、
幫一個五年前的功能找人善後、
幫一個沒人敢動的平台，
想辦法多撐兩年。

嗨，我是廣三。
在軟體開發打滾二十年，
從新創到大公司，
看過太多專案不是死在「做不出來」，
而是死在「下不掉線」。

我們習慣把重心放在：
這版要長出什麼新東西？

但走久了你會發現，
一個產品能不能活得久，
常常決定於：

* 哪些功能被你勇敢地宣布「到此為止」
* 哪些老系統被你安排好「體面退場」
* 哪些關鍵資料被你保護到「可以承接未來」

產品的告別式，
不是把功能一關了事。

而是讓團隊、使用者、老闆都知道：

我們不是在「結束一件事」，
而是在「騰出空間，讓剩下的東西可以變好」。

當你既有能力接手一個老舊系統，
也有勇氣幫它規劃好「怎麼離場」，

你就不只是專案的維護者，
而是這個產品生命週期的傳承者。

若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。

🔗前往分析連結

歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi

《歡迎加我LINE，一起破局未來》

最後修改日期: 2025-12-14

作者

留言

發表迴響