本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

師父準備依安排去巡查時，我剛提著便當回來。他說等回到櫃台再聊，我便先上樓吃飯。晚一點下樓，看到他已經完成巡查紀錄，才坐到旁邊把問題接上。

前幾次談 MVP，他提到有些流程先用較簡單的做法。我一直想問，工程師明明知道一段實作不好，為什麼還能同意上線。

「你也知道以後會難改，那當時為什麼不一次寫好？」

先區分缺功能、內部負擔和不能接受的錯誤

師父說，得先說清楚哪裡不好。他用客服工具的政策資料匯入作為假設：第一版只支援一種格式，這是產品範圍；匯入規則分散在幾個重複的函式裡，以後每次改欄位都要一起修改，這會增加內部維護負擔；如果不同客戶的資料可能混在一起，那又是需要直接處理的錯誤。

我說：「前面兩個不都算技術債？」

師父回答，沒有做某個功能，不一定表示欠了什麼。技術債這個比喻，適合用來討論某些內部品質問題如何讓後續修改更費力。要先知道實際增加的成本，不能把所有不滿意都裝進同一個詞裡。

Martin Fowler 在說明技術債時，將內部品質缺口造成的額外修改成本，比作持續付出的利息；也提醒這個比喻不能被拿來任意忽略品質。

我問，如果第一版的規則確實寫得重複，但處理結果正確，要不要延後？師父說，這就需要比較當下的選項。

把延後、縮小和有限發布的代價放在一起

假設客戶已經排好一場小範圍試用，團隊可以選擇延後，先整理內部結構；也可以縮小資料類型，讓目前能穩定處理的部分先提供；或在已有測試與操作限制下，安排有限發布。

我追問：「你會選哪個？」

師父說，先看風險是否能被清楚界定。若錯誤會造成資料混用或結果無法確認，不能因為想趕試用就照常推出。若問題是內部重複、增加日後維護成本，且目前範圍能被驗證，就可以把代價和創辦夥伴一起討論。

他補充，承諾「以後再整理」也要有內容。哪些規則重複、下次改動會碰到什麼、由誰追蹤，以及什麼時候重新評估，都應該留下。不能只在自己的腦中知道很爛，讓接手的人自行發現。

我說：「可是產品永遠有新需求，怎麼可能有空還？」

師父回答，如果每次修改都被同一個結構拖慢，就把實際影響帶回排序。不能只說工程師想重構，而是說這個問題讓哪些工作多花時間、增加哪些出錯機會，以及整理後能改善什麼。

重看時機要和實際工作相連

我問師父：「所以在工單裡寫下個月處理就好？」

師父說，日期是一種方式，也可以設和工作有關的觸發條件。例如下一種資料格式進來以前，先集中匯入規則；第一次出現跨客戶共用需求時，重新檢查原有假設。但到期或觸發以後，真的要有人評估，不能讓它一直自動順延。

他用剛才的例子往下推演。如果新增第二種格式時，團隊先把共用步驟抽出，再用原本的資料範例確認行為沒有改掉，就能一邊做新工作，一邊降低後續負擔。這比突然宣告整個系統重寫，可能更容易控制影響。

我問：「如果後來這個功能根本沒人用了呢？」

師父說，那就可能不值得再花時間改善，甚至可以評估移除。技術債的處理也要看這段程式還會不會被修改、是否持續造成問題，以及保留它的責任。不是每一段不漂亮的程式，都要在某一天被整理到完美。

知道代價，才有辦法共同決定

我說，工程師最不舒服的可能是，當時大家同意先做，後來出問題卻只問為什麼寫成這樣。

師父說，這也是決策紀錄有用的地方。留下當時的資訊、選項和限制，回顧時才能判斷哪個假設錯了，而不只是拿現在知道的事指責以前。

但紀錄也不能變成免責聲明。接受過某個缺口，之後仍然要處理它帶來的影響。若新資訊顯示風險比原本高，就得重新安排，不是拿舊會議結論擋住所有問題。

接受暫時缺口時，要知道影響、限制、負責人和重看時機。 能在什麼範圍先提供、哪些部分需要先修，說清楚以後，才有一個可負責的上線決定。