🔧 阿川の電商水電行
我們需要重構這段程式碼。
茫然的眼神。
“建築風格越來越雜亂了。”
更多茫然的眼神。 （甚至還有一絲「別煩我，我們還有功能要發布」的意味。）
“如果我們現在不解決這個技術債務，以後會拖慢我們的速度。”
他禮貌地點了點頭，然後問道：“我們能先發布這個功能嗎？”
我已經數不清跟人討論過這個問題多少次了。多年來，我一直把責任歸咎於產品經理。
他們根本不明白。他們只關心功能。他們無視地基，卻要我們再蓋一層。
後來我意識到：問題不在於他們，而在於我的溝通。
翻譯差距
我當時是這麼說的：“我們需要重構這段程式碼，因為架構越來越混亂，技術債也在不斷累積。”
他們聽到的是：“我寧願花兩週時間把東西做得更漂亮，也不願去做客戶要求的事情。”
我們當時說的根本不是同一種語言。我談的是程式碼質量，他們談的是客戶價值、收入和產品路線圖承諾。
我們倆都沒錯，只是彼此之間沒有溝通。
一切改變的那一刻
我當時正在開會，試圖解釋為什麼我們需要暫停功能開發來解決技術債問題。
產品經理眼神迷離。我能看出她正在心裡盤算著如何禮貌地結束這場對話。
於是我停下話說到一半，試著用另一種方式表達。
「想像一下，你剛剛切掉了半根手指。你可以好好清洗並包紮，也可以置之不理。如果你一直對切掉一半的手指置之不理，會發生什麼事呢？”
她看著我，好像我瘋了一樣。但後來她明白了。
“他們會被感染。”
“沒錯。最終，你甚至連那隻手都用不了了。這就是技術債對我們程式碼庫的影響。”
突然間，我們不再討論程式碼架構，而是討論化膿的傷口、擴散的感染和喪失功能的雙手。
她把技術債可視化了。而可視化能產生緊迫感。
為什麼技術術語會失效
-
當我們說「重構」時，非技術利害關係人會聽到「可選的潤色」。
-
當我們說「技術債」時，他們聽到的卻是「開發人員想要完美的程式碼」。
-
當我們說「架構」時，他們聽到的是「不影響用戶的抽象問題」。
我們彼此之間使用這些術語並沒有錯。但是，對於那些以已發布功能、產生的收入和客戶滿意度評分來衡量成功的利害關係人來說，我們需要一套不同的詞彙。
並非因為他們智力較低，而是因為他們追求的是不同的結果。
產品經理並非出於惡意而忽視技術債。
他們關注的重點是：
-
向客戶交付承諾的功能
-
實現營收目標
-
保持領先於競爭對手
-
讓利害關係人滿意
「我們需要重構」與這些目標都不符。所以我們需要向他們展示重構是如何達成這些目標的。
搭建橋樑
這種改變不是為了降低難度，而是為了找到共同的語言。
以下是我覺得有效的比喻：
創可貼治感染傷口
任何權宜之計都像是用創可貼掩蓋沒有徹底清理的傷口。任何捷徑都像是粉飾牆面裂縫，而不是從根本解決問題。
乍看之下還不錯：牆面看起來像是刷過漆的，切口也被遮住了。
但創可貼會脫落，油漆會剝落，而底下的情況比一開始更糟。
原因在於：人人都明白，忽視感染只會讓情況惡化。沒人會質疑「這會被感染」這句話。
裂痕基金會
你可以在開裂的地基上繼續蓋樓板。一開始，它或許還能撐住。但每蓋一層，壓力就會增加。裂縫會不斷擴大。總有一天，整個房子會坍塌——偏偏在你最需要它的時候。
它的作用原理：它將技術決策與風險管理連結起來，這是每個企業領導者都會考慮的問題。
用他們的語言
比喻固然有用，但你知道真正有效的方法是什麼嗎？那就是將後果轉化為商業語言。
而不是：“這段程式碼很難維護。”
嘗試這樣說：“由於結構的原因，該領域的每個新功能都需要花費三倍的時間才能完成。這意味著每個迭代周期我們都要額外花費 20 個小時來開發新功能。”
而不是說：“我們這裡有技術債。”
可以這樣說：“這讓我們每個季度損失15000美元的開發人員時間。如果我們現在投入兩週時間，以後每個季度就能節省這筆錢。”
而不是：“建築風格雜亂無章。”
嘗試說：“我們這個模組的錯誤率比其他地方高 4 倍。”
每週都有客戶回饋問題。我們可以解決這些問題，但這需要從根本解決系統架構問題。
時間浪費，金錢損失，漏洞增多，速度下降。
這些都是利害關係人能夠理解的指標，它們能夠營造出緊迫感。
真正有效的對話
這是我目前使用的框架：
- 認可他們的優先事項：“我知道我們需要在本季度末之前發布 X 功能。這很重要。”
不要一開始就採取對立態度，要從合作開始。
- 將技術債務與他們的目標聯繫起來：“問題是，我們需要建置功能 X 的區域非常不穩定。我們每週都會發現那裡有 bug，而且每次更改所需的時間都是正常情況的兩倍。”
要指出技術問題如何影響他們的目標，而不是你的目標。
- 量化成本：“目前，我們每個迭代周期都要花費大約 10 個小時來解決該模組中的問題。這相當於半個開發人員的時間。”
讓不可見的事物變得可見。給它們賦予數字。
- 提出投資方案和投資回報率：“如果我們花一周時間清理這個問題，就能將時間縮短一半。此外，功能 X 的建置速度會更快，穩定性也會更高。”
把它看作是一項有明確回報的投資，而不是一項成本。
- 給他們選擇：“我們可以現在解決這個問題，之後進展更快；或者繼續繞道而行，接受這個領域的每個功能都需要更長時間才能實現。考慮到我們的優先級，哪種方式更合理？”
賦予他們充分的訊息，讓他們能夠做出決定。
🛠️ 如何應用此方法
在下次討論技術債之前：
-
明確業務影響。時間、金錢或風險方面的成本是什麼？如果你無法清楚闡述這一點，表示你還沒準備好進行討論。
-
選出合適的比喻。什麼比喻最能引起這個人的共鳴？金融類人士關注債務和利息，產品類人士關注速度和風險。
-
盡可能量化一切。工時、成本、缺陷數量、速度變化。數字能營造緊迫感。
-
做好投資報酬率分析。投資額是多少？回報是多少？多久才能回本？
對話過程中：
-
首先要考慮他們的目標，而不是你的目標。 “我知道發布 X 功能至關重要…”
-
將技術問題與業務連結。闡明技術問題如何阻礙業務目標的實現。
-
提供多種選擇，而不是下最後通牒。 “我們可以現在解決這個問題，之後加快進度，或者繼續繞道而行。考慮到我們的優先事項，哪種方式更合理？”
-
要坦誠面對權衡取捨。每個選擇都有代價，要正視這些代價。
取得買入權之後：
-
說到做到。如果你說需要一周時間，那就花一周時間。信任是透過言行一致的累積起來的。
-
衡量成效。速度提高了嗎？ bug減少了嗎？分享這些成功經驗。
-
加強聯繫。 “還記得我們清理 X 模組的時候嗎？正因為如此，我們才能如此迅速地發布 Y 功能。”
更深層的技能
我希望有人早點告訴我：跨領域溝通是一項核心工程技能。
這不是軟技能，也不是錦上添花，而是一項核心技能。
我認識的最優秀的工程師不僅技術精湛，他們還能將技術問題轉化為商業價值、設計理念或使用者體驗。
他們明白：
-
後端工程師需要與前端溝通，了解 API 契約和資料流。
-
前端工程師需要與設計師溝通，了解互動模式與限制。
-
每個人都需要從客戶價值和業務成果的角度來談論產品。
跨學科融合並非意味著犧牲你的專業知識，而是要讓你的專業知識對那些追求不同結果的人有用。
🤔 需要思考的問題
你上一次試圖解釋技術問題卻得到對方茫然的眼神是什麼時候？當時用的是什麼語言？
哪些比喻能引起您的特定利害關係人的共鳴？
你是在量化科技決策對業務的影響，還是只是希望人們信任你？
您多久會從利害關係人的目標出發來展開關於技術債的討論，而不是從工程方面的考量出發？
底線
技術債終將為我們帶來麻煩。但僅僅告訴利害關係人這一點並不能讓他們意識到問題的迫切性。
創可貼可以緩解感染的傷口。信用卡利息會累積。地基開裂也會造成損害。
任何權宜之計都只是用創可貼掩蓋我們沒有徹底清理的傷口。
任何捷徑都如同粉飾牆上的裂縫，而不是從根本解決問題。
起初看起來還不錯。但創可貼會脫落，油漆會剝落，而底下的情況比一開始更糟。
你的工作不僅僅是找出技術債務，還要讓非技術人員像你一樣重視它。
而這一切都始於學習他們的語言。
照片由charlesdeluvio拍攝，來自Unsplash
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
