TL;DR: 繼承一個充滿大量技術債務的產品，是領導者或產品經理可能面臨的最艱鉅挑戰之一。最初的 30 天是絕對重要的 - 它們可以讓您的工程團隊留下來打好這場仗，或是選擇離開。關鍵在哪裡？不要只專注於程式碼；要專注於影響力、建立信任、策略性地排定優先順序，並讓工程師成為扭轉局面的真正合作夥伴。
在軟體開發的世界裡，「技術債務」是一個再熟悉不過的名詞。但是，當一位新的產品經理、工程領導，甚至是執行團隊繼承了一個幾乎被技術債務淹沒的產品時，它就不僅僅是風險登記冊上的一個細列項目了。它是在表面之下醞釀的全面危機。
我曾多次目睹這種情況的發生，不幸的是，我目睹工程團隊因為處理不當而內爆。多年來，我工作旅程的一部分就是介入協助引導和解決這種複雜的情況。讓我說清楚：技術債務不僅僅是技術問題。它是一個 信任問題，侵蝕了團隊和領導層之間的信任。它是一個道德問題，摧毀了天才工程師的精神。最後，這是一個巨大的 業務問題，影響交付速度、穩定性和客戶滿意度。
如果您剛走進這樣的風暴，感到不知所措是完全正常的。但是有一條路可以穿過它。
前 30 天：關鍵在於您的員工，而不僅僅是程式碼
當工程師與問題叢生的傳統系統作鬥爭時，他們的挫敗感經常高漲。他們可能會覺得自己的疑慮被忽視太久了。您的當務之急並不是要瞭解問題程式碼的每個角落。您的當務之急是要重建信任，並證明您是來協助解決問題的，而不是在混亂中指責或要求不可能的功能交付。
常見的陷阱：淹沒在債務中的細節
在這種情況下，新任管理者所犯的最嚴重錯誤就是試圖先仔細地規劃出所有技術債務。不要掉進這個陷阱。您會陷入困境，而您的團隊也會視此為分析癱瘓，同時他們也會繼續受苦。
相反，請立即將焦點轉移到繪製債務的影響：
- 哪些具體問題正積極阻礙重要新功能的開發？
- 哪些問題反覆造成生產事故和客戶痛苦？
- 哪些方面的債務會嚴重拖慢您的開發速度，並讓工程師的生活苦不堪言？
將挫折轉化為策略夥伴關係
您的工程師很可能對問題的存在和性質一清二楚。他們每天都與問題共處。然而，他們可能會不知所措或感情用事，導致他們提出「我們需要重寫所有東西！」這樣的解決方案。這雖然是由於挫折而產生的，但卻很少是最具策略性或最可行的第一步。
您的目標是將他們（可以理解的）憤怒和挫折感轉化為建設性的策略夥伴關係。方法如下
介紹「技術債務影響矩陣」：
- X 軸：業務影響（從低到高 - 考慮收入、客戶滿意度、策略目標）
- Y 軸：工程師的挫折感（從低到高 - 這個問題對團隊造成了多大的痛苦？）
讓您的工程團隊協助您將他們發現的每一項重要技術債務繪製到此矩陣上。這項練習可以立即達成兩件重要的事情：
- 這顯示您在傾聽：他們的疑慮正被直觀地確認和分類。
- 建立對優先順序的共同理解：並非所有債務的直接影響都是相同的。
策略性科技債務管理的藝術
這是鐵一般的事實：
- 如果您試圖修復 所有技術債務，您很可能會失敗，並讓您的團隊疲於奔命。
- 如果您忽略所有的技術債務，產品（也可能是您的團隊）最終會崩潰。
秘訣在於挑選正確的戰役。使用您的影響矩陣 (Impact Matrix)，將焦點放在債務上：
- 阻礙或嚴重妨礙創收功能或關鍵策略計畫。
- 直接造成重大的客戶痛苦、流失或信譽損害。
- 是挫敗感的主要驅動因素，會讓您最優秀的工程師考慮辭職。（這是一項關鍵的、經常被低估的企業成本）。
給其他領袖的訊息：您的支持不容商量
如果您是產品領導人、高階主管或 C-suite 成員，在這種情況下監督團隊，您的 PM 和工程主管需要您堅定不移的支持。當他們主張撥出資源處理技術債務時，他們並非「遲鈍」或「優柔寡斷」。他們是在執行重要的預防手術，以避免未來發生更昂貴、損害更大的緊急情況。現在每一週的策略性科技債務投資，都可以省下日後數月的緊急修復工作。
建立動力和士氣的實用節奏
除了矩陣之外，還要將這些實踐融入團隊的日常工作中：
- Daily Stand-ups： 簡單地問：「昨天是什麼技術問題或債務拖累了你？這樣可以溫和地掌握日常摩擦的脈搏。
- Weekly Retrospectives： 包括一個簡單的問題，例如：「以 1-5 分為標準，您會如何評價本周您對我們的程式碼庫的挫敗感呢？」追蹤此趨勢。
- 每月規劃/檢閱：明確詢問：「本月有哪些特定的技術債務項目直接影響我們的客戶或我們提供價值的能力？
當工程師主張「全面重寫」時，請深入挖掘。詢問：「我們現在可以做出哪些最小的變更，讓您的工作或特定的痛苦流程變得更輕鬆（例如 50%）？ 通常情況下，答案不會是多年的重寫。答案可能是
- 投資更好的測試工具或架構。
- 將痛苦的手動部署流程自動化。
- 在一兩個關鍵任務、高痛點模組中，進行重點程式碼清理或重整。
20/20/60 規則：平衡與進步的框架
為了確保在解決技術債務時不會完全停止前進的動力 (並維持利害關係人的信心)，請考慮對您的開發能力實施「20/20/60 法則」的變體：
- 20% 的時間： 專門用於必須、高優先級的新功能。
- 20%的時間：明確分配給優先減少技術債務和重構。
- 60%的時間：專注於定期、計畫中的開發與增強。
在一段特定的時間內（例如一個季度），承諾這樣的分配（或類似的均衡分配）。這種可見的、持續的改善程式碼基礎的投資對團隊士氣有很大的幫助。這顯示您對於改善事情是認真的。
在 Mercury Technology Solution，我們強調從第一天開始就建立穩健且可持續的軟體。對於繼承技術債務的企業，或正在處理這些複雜問題的客戶而言，建立這樣一個平衡的開發節奏是最重要的。我們在客製化軟體開發方面的專業知識，以及我們在業務營運套件中的專案管理能力，可協助有效地架構和管理這些工作，確保新價值和債務減少都能持續地得到解決。
黃金規則：關鍵在於人們感受到被聆聽
最後，請記住：工程師很少會因為技術債務而辭職。他們之所以辭職，是因為他們覺得沒有人聽到他們的聲音、他們的疑慮被駁回、他們的努力在腐敗的程式碼潮中徒勞無功。
讓他們成為解決方案不可或缺的一部分。 積極傾聽，協作排定優先順序，展現持續的進展（即使是微小的進展），並賦予他們權力。他們將成為您最大的盟友，幫助您解決讓他們感到沮喪的問題。
您的科技債務轉虧為盈玩法手冊：
- 呼吸與傾聽： 承認問題及其對團隊的影響。
- 瞭解影響力，而不只是細節：專注於傷害企業和團隊現在的事情。
- 建立共同的可見度和優先順序：協同使用影響矩陣等工具。
- 挑選策略戰役：解決妨礙營收、損害客戶或造成流失的債務問題。
- 實施平衡的節奏：為技術債務分配專屬容量（例如 20/20/60 規則）。
- 追蹤挫折和進展：使用簡單的指標來監控士氣和影響。
- 讓工程師成為您的合作夥伴：讓他們深入參與規劃和解決方案。
透過傳統程式碼領先：光明的未來
帶領一個有大量技術債務的產品是對領導力的真正考驗。它需要耐心、策略性思考、同理心和應變能力。但是，只要專注於影響力、建立信任並賦予團隊權力，您就能帶領這艘船擺脫風暴，創造出更穩定的產品、更有效率的工作流程，以及更投入、更忠誠的工程團隊。
