技術債如何處理？產品經理面對技術與商業的抉擇｜EP68
產品經理在規劃功能時，不時會遇到「這個需求在技術上是否可行」、「產品現況的技術架構跟客戶期望的修改方式好像無法符合」等技術相關問題，但哪些是技術債要大改、哪些是技術限制只要微調，往往需要工程師協助盤點，這篇想記錄在面對技術債（Legacy Code，Technical debt）時，身為產品經理會遇到的狀況。
一、技術債與技術限制的差異
⠀⠀
在討論技術債時，要先將「技術債」和「技術限制」拆開說明，因為各代表著不同層級的工程問題。
技術債通常指的是「系統架構」層面的問題，例如：
- 早期為了快速開發，選擇了單體式架構，核心邏輯耦合度過高，導致修改一處可能影響多個功能。
- 資料庫（Schema）設計不夠彈性，造成新功能難以擴充或效能瓶頸。
- 存在大量重複程式碼、或沒有使用共用元件，導致不同相似功能的寫法都不同，需要較大規模的盤點和整理才能整合架構。
相比之下，技術限制多半是「程式實作」層面的問題。例如：
- 某些參數被寫死（hardcode）在程式碼中，導致缺少彈性，但可以改為可配置。
- API 介面設計過於固定，但可以增加彈性欄位。
- 未預留擴充的彈性，如固定的狀態碼或預設值。
⠀⠀
⠀⠀
二、為什麼會有技術債
⠀⠀
理解了上述差異後，可以再探討為什麼會產生技術債，通常來自於各種「妥協」，像是：
1. 時間壓力
工程師面對產品經理的需求，為了快速開發完畢，可能會在架構上做出妥協，架構就像是房子的地基，雖然住戶（使用者）看不見、也不會影響使用者流程，但未來要考慮加功能時，終究會影響房子（系統）的擴充性。
2. 資源限制
呈上，時間壓力下，又要開發多種功能，這時可能會在某些功能的元件上進行取捨，用最快速的方式交付，讓時間投入在更關鍵的功能。
3. 缺少場景
產品經理在描述功能時，可能只講了「當下」使用者的操作方式，沒有預告未來要怎麼迭代，而工程師也用可滿足現況的做法，導致未來要迭代加上新功能時，發現無法直接加上去，需要再大改架構。
4. 需求不明確
產品經理在描述需求時，針對要支援、或不支援的使用情境不夠明確，為了避免過度開發，工程師可能會選擇較為寬鬆的寫法，但隨著使用者樣貌越來越多，一些特殊的操作方式就會讓程式出現異常。
⠀⠀
⠀⠀
三、如何有效管理技術債
⠀⠀
技術債通常不是任何人刻意為之，而是在各方情境下的妥協，有可能當時的時空背景完全沒問題，但過了幾年，商業場景、使用者操作模式更換後，就會讓原本正常可運作的程式變成「技術債」。
⠀⠀
作為產品經理，在軟體開發一定會遇到技術債，而我們只能選擇如何有效管理，像是：
1. 開發前，確保工程團隊先技術評估
通常技術債發現的時機，是在原有功能迭加新的機制時才會發現，因此產品經理需要與技術團隊建立有效的溝通機制，共同避免技術債：
- 規劃產品流程前，產品經理要先和技術團隊進行技術評估，確認現有機制是否可直接增加新功能，並盤點要改哪些範圍。
- 進產品開發後，若後續才發現有些程式需要調整，在不影響原本目標的前提下，由產品經理決策是否要這次一起修改，或放在未來優化項目。
⠀⠀
2. 開發前，掌握短期需求與長期願景
產生技術債的原因，通常是在做產品決策時，對於產品現況和未來考慮的不夠全面，因此若要避免，可以透過：
- 規劃產品功能時，產品經理也需要設想未來會不會出現額外情境，例如「1 對 1」變成「1 對多」。
- 規劃流程時，產品經理需要明確列出哪些是「現在支援、現在不支援、未來可支援」的操作模式。
- 針對寫死（hardcode）的部分，建議工程師留註解，同時產品經理也需要在需求文件備註，確保未來接手的人知道當時的時空背景。
⠀⠀
3. 開發中，確保技術債可能產生的風險
上述提到的都是開發前，但有些情況是已經開發中，工程師為了加快開發速度，提出是否可用繞道（workaround）的方式進行，這時要確保：
- 明確掌握這次的 workaround 是短解或長解，若因為時間壓力需要先採用短解，也要將可能衍生的長期問題寫進文件。
- 有長解的話，則在後續產品路線圖（Roadmap）、或迭代計畫，要預留調整技術債的時間。
⠀⠀
4. 開發後，適時償還技術債
技術債大部分情況不會安排一個完整時間去進行，通常是要加新功能時，陸續修補一點，因此還會需要：
- 確保調整技術債不會影響到現有使用者的操作模式，並要經過完整的功能測試。
- 確保這次調整後，可以一併解決現有的相依問題，並對開發品質、或未來迭代的功能帶來可見的效益或價值。
⠀⠀
⠀⠀
四、結論
⠀⠀
根據我目前待過 B 端和 C 端的產品團隊，技術債是軟體開發一定會遇到的困境，通常 80% 的經驗都是發生在「早期的時空背景，原本寫法已可滿足需求；在現在新需求要加上去，就無法滿足」。
因此技術債往往需要產品經理、技術團隊共同承擔的策略議題。好的技術債管理應該：
- 建立溝通透明的制度，確保各方都知道有技術債的存在
- 提供修補的合理時間，確保迭代後符合未來需求。
- 規劃完整的測試範圍，確保原本的使用流程都可以正常操作。
處理技術債不是一次性的工作，而是當用戶需求越來越多變，系統就必然會經歷升級或打掉重練的過程，「拆解技術債」、「新功能開發」和「提升用戶體驗」都是軟體開發重要的一環。
市面上也有滿多文章和社群在討論「無瑕的程式碼 Clean Code」、「遺留程式 Legacy Code」、「重構 Refactoring」，這篇僅單純以產品經理的角度來分享，未來如有其他議題再陸續記錄成文章！
⠀⠀
如對這系列文章有興趣可以再觀看：
你可能也想看
