技術債排不進 Backlog？因為你沒把它翻譯成 PO 聽得懂的語言
上週聊 User Story 怎麼拆，這週來聊技術債——為什麼它總是排不進 Backlog，以及，為什麼有時候它太容易排進去反而更危險。
先說一個我還是熱血工程師時期，被主管打槍的經驗
那時候我還是純技術職，公司產品有一段程式碼的擴展性很差，每次需求變更都要 hardcode。我處理過幾次之後，覺得不能再這樣下去了。
我去找主管，滿腔熱血地說：
「這段程式碼擴展性太差，我計畫整個翻新，不然每次都要 hardcode，之後會很難維護。」
主管沒有直接回答，而是連問了我三個問題：
「你做這個變更要花多少時間？」——大約兩週。 「那現在 hardcode 一次要多久？」——一到兩小時。 「改完之後呢？」——大約⋯⋯ 30 分鐘吧，但我還沒實際驗證過。
他點點頭：「Jed，我理解你想優化，但這一季的進度我們是落後的。你有空的話先做個 PoC，我們再來看值不值得現在進行。」
那段程式碼，到我離職都沒有重構過。後來有沒有炸？我不確定。但我確定的是，當時的我根本不知道自己的提案哪裡有問題。
常見三種劇本
這種場景到處都在上演。
場景一：工程師在 Retro 裡抱怨「技術債太多了」，PO 點頭表示理解，下個 Sprint 的 Backlog 雖然有技術改善的單，但都排在最後面，光是功能性需求就追不完。
場景二：Tech Lead 好不容易爭取到一張「重構 Story」，但因為沒有明確的驗收標準，做到最後也說不清楚改善了什麼，下次就更難爭取了。
場景三：技術債真的炸了——某個功能改一行 code 要花三天，PO 終於同意處理，但已經變成救火，不是還債。
你的團隊有沒有以上任何一種？我自己全都經歷過。
另一種更隱性的風險
但帶的團隊多了，我發現技術債的問題不只有這一面。
有些團隊剛好相反——工程師說要重構，PO 就讓他重構。不是因為被說服了，是因為聽不懂，不敢問，怕問了顯得外行。
這種團隊的畫面長這樣：
工程師在 Refinement 裡說：「這邊架構有問題，我需要兩個 Sprint 重構。」 PO 問：「可以再說明一下影響嗎？」 工程師回：「就⋯⋯ coupling 太高、違反 SOLID 原則，反正技術債太多，不處理的話之後很難維護。」 PO 點點頭：「好，你們專業判斷。」
表面上看起來很和諧，對吧？
但實際上，這個 PO 根本不知道這兩個 Sprint 換回了什麼。他沒有足夠的資訊去排優先序，只能選擇相信。而當 stakeholder 來問「為什麼這季少交了兩個功能」的時候，他只能硬著頭皮說做了技術改善。stakeholder 再追問：「改善了什麼？」PO 只能回答提高了系統穩定性。
更危險的是——當「重構」變成一張不需要被質疑的萬用卡，團隊會漸漸失去為技術決策提供論述的能力。不是故意的，是因為不需要，所以就不練了。
我在帶某一個團隊的時候遇過這個狀況，PO 曾跟我說：「我其實不確定每次重構是不是都必要，但我不想讓工程師覺得我不信任他們。」
這句話讓我意識到——PO 被說服和 PO 聽不懂就放行，是完全不同的兩件事。
技術債的溝通問題，其實有兩種病
一種是 PO 太強勢，工程師提什麼都被打回來。債愈欠愈多，最後爆炸。
另一種是工程師太強勢，PO 不敢質疑技術判斷。看起來沒衝突，但資源配置其實失控了，只是大家都不知道。
兩種病的症狀不同，但病根是一樣的——雙方對技術債從來沒有建立過共識。
我是什麼時候開始想通的？
後來我當了主管，有一次在看工單時，發現有一種單子的數量和頻率很特別——客戶請客服協助修改參數設定。照理說這種事客戶應該自己能操作，結果追查下去才發現：這是早期趕時程留下的債，參數設定模組從來沒有做完整，RD 提過很多次想重構，但客戶需求多到排隊要以半年為單位，在業務端的壓力下，RD 就一直手動幫客戶改參數。
從 PO 的角度看，「重構參數設定模組」跟「我花三天整理房間」是一樣的——你告訴我要做，但我看不到不做會怎樣，也看不到做完會怎樣。
但反過來，如果 PO 看到一張要重構的 task 就直接放行，那他其實跟簽空白支票沒什麼不同。
問題不在誰強勢誰弱勢，而在於技術債從來沒有被放進一個雙方都能理解、都能評估的框架裡。
關鍵：把技術債翻譯成能被排序的語言
後來我慢慢整理出一個思路，核心概念其實 Martin Fowler 在他的技術債象限（Technical Debt Quadrant）裡就講過了——技術債有分「故意的 vs 無意的」、「謹慎的 vs 魯莽的」，不是所有債都一樣，處理方式也不該一樣。
但光有分類還不夠。真正讓對話產生改變的，是建立共識。而建立共識的方式，是翻譯。
白話就是：不管你是工程師還是 PO，技術債都應該被翻譯成三個東西——風險、成本、跟速度。
拿前面的參數模組當例子。
「參數設定四散在 appsetting、環境變數、DB，需要重構」——這是工程語言。
翻譯成產品語言，可以變成三種說法：
- 風險角度：「以目前參數模組的架構，每次上新功能要連帶處理參數設定和完整測試，整體時間會從一個 Sprint 膨脹到三到四週。時程風險很難控制。」
- 成本角度：「過去一年，每個 Sprint 幾乎都要額外安排 1 位工程師，花 4 到 6 個小時處理客戶的參數變更請求。這是持續在燒的隱形成本。」
- 速度角度：「下一季如果要上 XX 功能，以目前的架構，光是參數模組的前置調整就要額外多出一個 Sprint，直接影響整體上線時程。」
同一件事，三種說法，但每一種 PO 都能放進他的優先順序框架裡去衡量。
而且這個翻譯是雙向的——對工程師來說，這是在幫 PO 理解技術決策的代價。對 PO 來說，這是在幫自己取得質疑技術決策的合理依據。
當 PO 可以看著數據問「這個重構預期把變更時間從三天降到多少？」的時候，他不是在質疑你，他是在做他該做的事——排序。而工程師也必須認真回答這個問題，不能只說「重構完就會比較好」。
這才是健康的張力。
該如何協助團隊建立這個溝通習慣？
我現在會建議更具有商業思維的做法：不要開一張叫「重構 XXX」的卡。改成：
- 把技術債的影響寫進相關功能 Story 的風險欄位
- 或者，把它寫成「降低 XXX 的變更成本」這種 PO 看得懂的目標
- 附上數據：過去 N 個 Sprint，因為這段 code 多花了多少時間
這樣做的好處不只是讓 PO 買單。對那些「PO 不敢問」的團隊來說，這個格式等於給了 PO 一個合理的介面去參與技術決策。他可以問「額外的 4 到 6 小時是怎麼算的？」、「如果只處理一半，風險能降多少？」——這些問題不是不信任，是正常的產品決策討論。
大型技術債怎麼處理
當然，有人會說：「可是有些債就是需要大規模重構，不是一兩張 Story 能解決的。」
沒錯。但回想上一篇聊的——大的東西要先拆小，對吧？技術債也是。
一口氣提「花兩個 Sprint 重構」，不管 PO 是拒絕還是直接放行，都不是好結果。但如果你把它拆成幾個可獨立交付的改善，每個都附帶具體的風險降低或效率提升，整件事就變得可追蹤、可評估、可排序。
PO 也終於可以不用在「全部買單」跟「全部拒絕」之間二選一了。
結論
PO 不是你的敵人，工程師也不是在亂花資源。大家只是活在不同的壓力結構裡——PO 要面對 stakeholder 的功能需求和時程壓力，工程師要面對程式碼的現實和系統的長期健康。
當技術債只停留在工程師的語言裡，PO 只能選擇「相信」或「拒絕」。這兩個選項都不好。真正健康的狀態是：工程師有能力論述，PO 有能力提問，雙方在同一個框架裡做取捨。
技術債不是工程師的情緒，也不是 PO 的空白支票。它是產品的風險——但只有當你把它翻譯成風險的語言，它才會被當成風險來管理。