◆ 專案現場的真實痛點
產品進入穩定營運後，PM 很快會遇到一種很難處理的會議情境。
RD 主管在會議上嚴肅地說，這套系統架構已經非常脆弱，功能一直往上加，但底層沒有整理。如果再不處理，未來不是開發速度越來越慢，就是系統在關鍵時刻出現重大異常。他的建議很明確，暫停新功能開發，花三個月全面重構。
業務主管聽完通常很難接受。他會立刻提醒團隊，年底業績還沒達標，客戶指定的新功能下個月一定要上。若現在暫停功能開發，公司不只是少做幾個功能，而是可能直接少掉幾筆關鍵訂單。
這時候，老闆會轉頭看著 PM。
如果答應 RD，三個月內產品沒有明顯新產出，業務可能無法成交，公司現金流會受到壓力。
如果答應業務，研發團隊會繼續在脆弱的架構上追加功能，開發效率越來越差，下一次大促銷或大型活動時，系統可能直接出現嚴重問題。
這不是單純的技術討論，而是一個典型的商業兩難。
不重構，系統可能會掛。
重構太大，公司可能先倒。
PM 在這裡真正要做的，不是站在 RD 或業務其中一邊，而是把問題從「工程師覺得程式碼很亂」轉換成「公司目前願意承擔哪一種成本與風險」。
◆ 這篇文章「不解決」什麼
這篇文章不是要教你軟體架構模式，也不是要討論微服務、Clean Architecture、Domain-Driven Design 這類技術選型。這些議題應該由 CTO、架構師與研發團隊主導。
這篇文章也不是要教 PM 如何用話術安撫工程師，讓他們繼續在品質不佳的程式碼上追加功能。那不是管理，而是在延後問題。
本文真正要處理的是，PM 如何把抽象的
- 程式碼很亂
- 架構很舊
- 技術債很重
翻譯成老闆、業務與營運聽得懂的
- 商業成本
- 營運風險
- 交付效率
- 未來機會成本
因為在企業裡，技術決策最後往往不是由技術理由單獨決定，而是由資源、時程、營收、風險與機會成本共同決定。
PM 若只停在「RD 說需要重構」，很難說服管理層。
但如果你能說清楚，繼續維持舊系統每個月多花多少開發成本、可能造成多少營收風險、會不會讓工程人力流失，這個問題就會從技術偏好，變成管理層必須面對的財務判斷。
◆ 白話版框架定義：破窗效應 × 總持有成本
談技術債，我會先用兩個概念來看。
第一個是 破窗效應。
第二個是 總持有成本（TCO, Total Cost of Ownership）。
破窗效應：系統腐敗的心理學
在一棟建築裡，如果有一扇窗破了卻沒有人修，其他人很快會覺得這棟建築本來就沒有人維護。下一扇窗再破，也不奇怪。久了之後，整個環境會更快惡化。
系統也是一樣。
當程式裡已經存在一段明顯不合理、但一直沒有被處理的架構，後續開發者在時間壓力下，很容易延續同樣的做法。不是因為工程師不專業，而是因為環境已經傳達了一個訊號。
這裡可以先這樣做，反正以前也是這樣做。
技術債可怕的地方就在這裡。它不是靜態存在，而是會影響後續每一次開發決策。放著不處理，通常不會自己變好，只會讓團隊越來越習慣在不健康的基礎上工作。
總持有成本：老闆看到的是開發成本，PM 要補上長期成本
老闆看到重構，通常第一反應是聽不懂。
三個月不能做新功能，代表少了三個月產出。這個判斷沒有錯，但它只看到一次性的開發成本，沒有看到系統持續維護的總成本。
PM 要協助管理層看到的是完整的 TCO。
維持舊系統的總持有成本，通常包含幾種成本：
- 開發利息
每次新增功能都要多花時間理解舊邏輯、處理相容問題與修補例外。 - 營運損失
系統不穩定造成當機、交易失敗、客服量暴增，最後會回到營收與品牌信任。 - 人才成本
工程師長期處理低品質架構，士氣下降，甚至選擇離開，後續還會產生招募與交接成本。 - 機會成本
未來要串接新服務、開新模組、做資料分析時，處處受到舊架構限制。
用這個角度看，技術債不是工程師的潔癖問題，而是公司正在付一筆利率越來越高的商業貸款。
初期借一點，可以換速度。
但當利息高到吃掉未來所有開發效率時，就不能再假裝它只是技術細節。
◆ 框架的三個判斷問題
當 RD 提出重構，業務提出新功能，老闆要求產品繼續前進時，PM 可以先用三個問題判斷。
Q1：致命性測試。這是毀滅性風險，還是慢性風險？
第一個問題是，這個技術債會不會造成毀滅性災難。
如果它已經可能造成：
- 資安外洩
- 金流中斷
- 資料錯亂
- 核心服務停擺
那就不是排不排版本的問題，而是必須立即處理的風險。
這類問題一旦發生，影響的不是某個功能，而是公司信任與營運底線。
但如果問題目前主要表現為：
- 維護困難
- 開發較慢
- 程式可讀性差
- 新人接手成本高
那它更接近慢性風險。
慢性風險不代表可以忽略，而是需要進入版本規劃，用更精確的方式安排處理節奏。
Q2：利息計算。這筆技術債的利率有多高？
技術債最適合用「利息」來理解。
例如一個新功能，若在健康架構下原本三天可以完成，但現在因為舊系統邏輯混亂，每次都需要花七天處理相容、例外與修補，那多出來的四天就是利息。
如果這種利息只發生一次，還可以接受。
如果每一個新功能都要付一次，而且幅度越來越高，這就代表系統已經在持續消耗未來產能。
PM 可以請 RD 協助估算幾個數字：
- 同類功能原本預估幾天，現在實際需要幾天
- 每次新增功能，有多少時間花在理解舊邏輯與補救相容問題
- 過去一季，有多少 Bug 來自同一個架構問題
- 是否已有多位工程師反覆在同一段模組上處理異常
這些數字不一定要精準到財務報表等級，但必須足以讓管理層理解一件事：
這不是工程師主觀感受，而是產品開發速度正在付出成本。
Q3：分期付款測試。能不能用漸進式重構，而不是全面暫停？
全面重構最大的問題，是商業上很難承受。
三個月完全不做新功能，對很多公司來說不是理想選項。
因此，PM 需要和 RD 討論另一種可能，也就是 漸進式重構。在技術上常被稱為 Strangler Fig（絞殺者榕樹模式），概念有點像用新系統逐步取代舊系統，而不是一次把整棵樹砍掉重種。
放到產品版本裡，可以這樣理解。
- 這次要做會員新功能，就順便整理會員相關的底層模組
- 下次要做報表功能，就順便把報表資料來源重新定義
- 每一版都不只新增功能，也逐步處理一部分舊架構的風險
這種做法不是最快，也不是最乾淨，但通常更符合企業實際情況。它讓產品可以繼續前進，也讓技術債逐步下降。
對 PM 來說，這往往是比較能被老闆、業務與研發同時接受的方案。
◆ AI 協作 Prompt：讓 AI 扮演 CFO 與 CTO 的雙重視角
當你面對重構與新功能的取捨時，AI 可以協助你先整理決策架構。它不能替你做最後判斷，但可以協助你把選項、風險與成本攤開。
你可以這樣使用：
我是一名產品經理，目前面臨一個技術債決策。
研發團隊認為現有系統架構已經影響開發效率，建議投入三個月全面重構；業務團隊則希望下個月先交付新功能，以支援既有客戶與營收目標。請同時用 CFO 與 CTO 的角度，協助我建立一份決策矩陣，比較三個方案：
- 全面重構
- 維持現狀，繼續開發新功能
- 漸進式重構，每個版本處理一部分底層問題
請從總持有成本（TCO）、機會成本、營收影響、系統風險、研發效率、工程團隊士氣、短期與長期商業價值等角度分析利弊。
最後，請協助整理一份適合給高階主管看的簡報式結論。
這類 Prompt 的價值，在於幫 PM 先把抽象技術問題轉換成管理層可以理解的決策素材。
但仍要記住，AI 給的是分析架構，不是公司現況。真正的判斷，仍然要回到你掌握的市場壓力、團隊能力、現金流狀態與產品階段。
◆ 常見誤用提醒：不要為了工程潔癖而重構
技術債確實需要管理，但重構本身也可能被誤用。
有些重構提案，並不是因為系統真的無法支持未來，而是因為工程師對舊技術不滿意，或想導入新的框架與架構模式。
這種情況不能直接否定，但 PM 必須問一個商業問題：
如果不重構，未來一年會造成什麼具體損失？
如果一個舊系統雖然不好看，但跑得穩，使用量也穩定，未來一年不需要頻繁新增功能，也不牽涉重大營收擴張，那最好的商業決策，可能就是不要動它。
特別是某些已經進入成熟期或衰退期的 Cash Cow（現金牛） 產品，它的價值在於穩定提供現金流，而不是追求技術上的優雅。
這時候，花大錢重構沒有未來擴張性的模組，很可能不是投資，而是資源錯置。
所以，PM 在判斷重構時，需要避免兩種極端：
- 完全忽略技術債，讓系統一路惡化
- 把所有技術不滿都視為重構理由，最後為了整理系統而犧牲商業時機
真正成熟的判斷，是把技術債放進產品生命週期裡看。
你要問的是：
- 這個系統還有多少未來
- 它未來是否需要快速擴充
- 它現在的維護成本是否已經高到影響新功能交付
- 它是否正在影響營收、穩定性或團隊人力
這些問題，比「技術新不新」更重要。
◆ 廣三觀點
嗨，我是廣三。
我一直覺得，技術債很像公司的商業貸款。
產品早期為了搶市場、搶時間，有時候刻意留下不完美的程式碼，這不一定是錯。很多時候，那反而是務實的商業選擇。因為當時最重要的不是系統優雅，而是產品能不能先被市場驗證。
但貸款終究有利息。
如果利息還在可承受範圍內，繼續擴張也許是合理選擇。
如果利息已經高到每次新增功能都變慢、每次上線都提高風險、每次出問題都需要大量人力處理，那就不能再假裝這只是工程師的抱怨。
PM 在這裡最重要的任務，不是替 RD 說服老闆一定要重構，也不是替業務要求 RD 繼續接受所有新功能。PM 真正要做的，是把技術債翻譯成公司聽得懂的成本，把重構選項變成管理層可以評估的商業決策。
如果要把這一篇轉成專案現場可以使用的說法，我會這樣講：
我們這次同意撥出 30% 的開發資源處理底層重構，不是為了解決程式碼的潔癖，而是為了降低未來的開發利息。這樣做的目的，是讓業務下半年的新功能可以更穩定、也更準時地交付。
這句話的重點，是把重構從「工程想整理」轉換成「公司要降低未來成本」。
我曾經接手過一個已經運作 7 年多的專案。當時股東希望在既有系統架構上，搭建新的機制。坦白說，一開始我也以為這套系統既然已經運行多年，過去也沒有聽說發生重大問題，應該具備一定程度的穩定性。後來才發現，這個判斷太樂觀了。
接手後隔天剛好有一場大型活動，結果連線數大約只有 200，系統就開始出現 HTTP 500 錯誤。當下非常難以理解，因為這個流量並不算高，卻已經讓系統進入不穩定狀態。活動當天，系統就在反覆重啟與持續異常的狀況下勉強結束。那次經驗也讓我很清楚意識到，這已經不是單純加大伺服器就能解決的問題。
後來盤查後才發現，原本的系統架構其實存在明顯問題。如果直接在這樣的基礎上開發股東期待的新機制，只會把未來的風險放大。因此在安排專案時程時，我們必須把系統架構調整與效能優化納入版本規劃。這不代表那段時間只能做優化，而是要重新分配比重。也許 11 到 12 月優先開發新機制，1 到 2 月處理底層架構；也可能在規劃新功能時，同步把相關底層模組整理進去。
這件事讓我學到的是，技術債和商業目標不一定只能二選一。真正困難的是，PM 能不能把兩者放進同一張版本計畫裡，讓團隊一邊交付商業成果，一邊逐步降低系統風險。
當你能把技術債說成商業語言，重構就不再只是技術部門的要求，而會變成產品路線圖裡可以被討論、被安排、被承擔的決策。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言