技術債如何處理?產品經理面對技術與商業的抉擇|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
查看全部
發表第一個留言支持創作者!
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
美國總統大選只剩下三天, 我們觀察一整週民調與金融市場的變化(包含賭局), 到本週五下午3:00前為止, 誰是美國總統幾乎大概可以猜到60-70%的機率, 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Thumbnail
Faker昨天真的太扯了,中國主播王多多點評的話更是精妙,分享給各位 王多多的點評 「Faker是我們的處境,他是LPL永遠繞不開的一個人和話題,所以我們特別渴望在決賽跟他相遇,去直面我們的處境。 我們曾經稱他為最高的山,最長的河,以為山海就是盡頭,可是Faker用他28歲的年齡...
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
Thumbnail
工程師希望能釐清任務的輕重緩急,其中那些「看起來不錯,但目前重要性沒那麼高」的任務,就叫做 nice-to-have...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
當企業服務到一個階段,並評估已可脫離顧問服務時,我會將服務轉向諮詢比重比較多一點,逐步輕量合作但仍保持諮詢。這篇文章討論了企業顧問服務的重要性,並提供了一些策略和方法。
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
專案失敗以往被定義為超期、超預算或無法結案,但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
Thumbnail
產品需求怎麼來?產品經理能決定產品走向嗎?產品路線圖怎麼制定?這篇想整理我在不同公司的產品開發流程,也分享不同公司的產品決策方式。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
Thumbnail
美國總統大選只剩下三天, 我們觀察一整週民調與金融市場的變化(包含賭局), 到本週五下午3:00前為止, 誰是美國總統幾乎大概可以猜到60-70%的機率, 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Thumbnail
Faker昨天真的太扯了,中國主播王多多點評的話更是精妙,分享給各位 王多多的點評 「Faker是我們的處境,他是LPL永遠繞不開的一個人和話題,所以我們特別渴望在決賽跟他相遇,去直面我們的處境。 我們曾經稱他為最高的山,最長的河,以為山海就是盡頭,可是Faker用他28歲的年齡...
Thumbnail
這篇文章探討了工程師在如何有效提升自己,強調不僅僅是多coding,而是要對程式碼有更深層的理解。隨著職涯發展,工程師需要從單純的技術執行者轉變為團隊領導者,具備解決複雜問題和與他人有效溝通的能力。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
Thumbnail
工程師希望能釐清任務的輕重緩急,其中那些「看起來不錯,但目前重要性沒那麼高」的任務,就叫做 nice-to-have...
Thumbnail
業務與研發之間的溝通是職場一大挑戰,常因認知差異產生誤解,影響工作氣氛與專案進度。 透過本文提出的三點提醒,設定對應方案來打破專業壁壘,就能建立起有效的跨部門合作關係。
Thumbnail
當企業服務到一個階段,並評估已可脫離顧問服務時,我會將服務轉向諮詢比重比較多一點,逐步輕量合作但仍保持諮詢。這篇文章討論了企業顧問服務的重要性,並提供了一些策略和方法。
Thumbnail
這篇文章著重於解釋軟體專案管理中的戰略意義和專案特性評估,並提出了四個不同像限的專案特性。
Thumbnail
專案失敗以往被定義為超期、超預算或無法結案,但現今專案管理思維重新把失敗定義為未能產生預期價值。文章從產品經理、軟體設計和管理流程三方面提出對失敗專案的見解和解決方法。
Thumbnail
產品需求怎麼來?產品經理能決定產品走向嗎?產品路線圖怎麼制定?這篇想整理我在不同公司的產品開發流程,也分享不同公司的產品決策方式。
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。