技術債如何處理?產品經理面對技術與商業的抉擇|EP68

閱讀時間約 6 分鐘

產品經理在規劃功能時,不時會遇到「這個需求在技術上是否可行」、「產品現況的技術架構跟客戶期望的修改方式好像無法符合」等技術相關問題,但哪些是技術債要大改、哪些是技術限制只要微調,往往需要工程師協助盤點,這篇想記錄在面對技術債(Legacy Code,Technical debt)時,身為產品經理會遇到的狀況。

raw-image

一、技術債與技術限制的差異

⠀⠀

在討論技術債時,要先將「技術債」和「技術限制」拆開說明,因為各代表著不同層級的工程問題。

技術債通常指的是「系統架構」層面的問題,例如:

  • 早期為了快速開發,選擇了單體式架構,核心邏輯耦合度過高,導致修改一處可能影響多個功能。
  • 資料庫(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」,這篇僅單純以產品經理的角度來分享,未來如有其他議題再陸續記錄成文章!

⠀⠀

如對這系列文章有興趣可以再觀看:

《思維的創意想像》是工作之餘發起的 Side Project,因為近期快速吸收各種資訊跟商業知識(Input),但一直沒有地方輸出(Output),因此想透過這系列記錄學到的內容,包含商業知識、產業洞見,或是職場分享等等,目前已有產品開發、客戶成功、社群行銷、思維增長、職場日記等系列文章。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
AI 功能如何導入介面?產品如何運用 AI?AI 如何讓使用者更便利操作功能?幾乎是近幾年產品經理在規劃功能時需要考量的事情,每個系統化、固定的操作流程,都開始被詢問「能否導入 AI」,因此這篇想記錄在電商平台我觀察到可以應用 AI 的場景。
在產品經理這個職位上,常需要撰寫各種產品文件,像是產品需求文件、產品教學手冊、產品路線圖、產品維運常見問題等,這篇想整理過往以產品經理的角色需要維護哪些文件。
需求無限、資源有限的情況下,產品經理設計功能都會面臨如何縮減需求,透過有限的開發人力打造最小可行性產品(Minimum Viable Product,MVP),這篇將分享「減法思維」在實際產品規劃中如何運用。
目前多數產品都使用數據驅動的商業環境,不論是面向企業(B 端)還是面向消費者(C 端)的產品,怎麼看數據、如何使用數據,都是產品經理需要了解的議題,這篇會分享我在 B 端和 C 端的產品經歷,各自會面對到什麼數據場景。
帳號權限管理一直是產品系統的重要議題,近期規劃權限功能時發現 RBAC 這套模型,才開始了解為什麼要有 User-Role-Permission 的架構,隨著系統規模的擴大和複雜度的增加,傳統的權限管理模式已經無法滿足需求,而基於角色的訪問控制(Role-Based Access Control,簡
產品設計階段我們常追求流暢的使用者體驗,希望用戶能夠輕鬆、直觀地完成各種操作,但有些刻意設計的「摩擦」反而能提升產品體驗,這篇想記錄「摩擦設計」(Friction Design)的概念,以及在實際工作中的應用。
AI 功能如何導入介面?產品如何運用 AI?AI 如何讓使用者更便利操作功能?幾乎是近幾年產品經理在規劃功能時需要考量的事情,每個系統化、固定的操作流程,都開始被詢問「能否導入 AI」,因此這篇想記錄在電商平台我觀察到可以應用 AI 的場景。
在產品經理這個職位上,常需要撰寫各種產品文件,像是產品需求文件、產品教學手冊、產品路線圖、產品維運常見問題等,這篇想整理過往以產品經理的角色需要維護哪些文件。
需求無限、資源有限的情況下,產品經理設計功能都會面臨如何縮減需求,透過有限的開發人力打造最小可行性產品(Minimum Viable Product,MVP),這篇將分享「減法思維」在實際產品規劃中如何運用。
目前多數產品都使用數據驅動的商業環境,不論是面向企業(B 端)還是面向消費者(C 端)的產品,怎麼看數據、如何使用數據,都是產品經理需要了解的議題,這篇會分享我在 B 端和 C 端的產品經歷,各自會面對到什麼數據場景。
帳號權限管理一直是產品系統的重要議題,近期規劃權限功能時發現 RBAC 這套模型,才開始了解為什麼要有 User-Role-Permission 的架構,隨著系統規模的擴大和複雜度的增加,傳統的權限管理模式已經無法滿足需求,而基於角色的訪問控制(Role-Based Access Control,簡
產品設計階段我們常追求流暢的使用者體驗,希望用戶能夠輕鬆、直觀地完成各種操作,但有些刻意設計的「摩擦」反而能提升產品體驗,這篇想記錄「摩擦設計」(Friction Design)的概念,以及在實際工作中的應用。
你可能也想看
Google News 追蹤
Thumbnail
這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
Thumbnail
11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
Thumbnail
Hi 大家好,我是Ethan😊 相近大家都知道保濕是皮膚保養中最基本,也是最重要的一步。無論是在畫室裡長時間對著畫布,還是在旅途中面對各種氣候變化,保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水,還能提升後續保養品的吸收效率。 曾經,我的保養程序簡單到只包括清潔和隨意上乳液
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
Thumbnail
工程師希望能釐清任務的輕重緩急,其中那些「看起來不錯,但目前重要性沒那麼高」的任務,就叫做 nice-to-have...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
當企業服務到一個階段,並評估已可脫離顧問服務時,我會將服務轉向諮詢比重比較多一點,逐步輕量合作但仍保持諮詢。這篇文章討論了企業顧問服務的重要性,並提供了一些策略和方法。
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
專案失敗以往被定義為超期、超預算或無法結案,但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
Thumbnail
產品需求怎麼來?產品經理能決定產品走向嗎?產品路線圖怎麼制定?這篇想整理我在不同公司的產品開發流程,也分享不同公司的產品決策方式。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
Thumbnail
11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
Thumbnail
Hi 大家好,我是Ethan😊 相近大家都知道保濕是皮膚保養中最基本,也是最重要的一步。無論是在畫室裡長時間對著畫布,還是在旅途中面對各種氣候變化,保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水,還能提升後續保養品的吸收效率。 曾經,我的保養程序簡單到只包括清潔和隨意上乳液
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
Thumbnail
工程師希望能釐清任務的輕重緩急,其中那些「看起來不錯,但目前重要性沒那麼高」的任務,就叫做 nice-to-have...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
當企業服務到一個階段,並評估已可脫離顧問服務時,我會將服務轉向諮詢比重比較多一點,逐步輕量合作但仍保持諮詢。這篇文章討論了企業顧問服務的重要性,並提供了一些策略和方法。
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
專案失敗以往被定義為超期、超預算或無法結案,但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
Thumbnail
產品需求怎麼來?產品經理能決定產品走向嗎?產品路線圖怎麼制定?這篇想整理我在不同公司的產品開發流程,也分享不同公司的產品決策方式。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。