上個月在一場演說中，有聽眾問到技術債的問題，他說：「公司內有很多legacy code，架構疊床架屋，時常改A錯B，跟老闆溝通了很多次，但始終排不進去工作中，永遠都被業務的需求排擠，在這種公司工作，很無奈，怎麼辦？」

gipi：「很棒，技術債是屬於活下來的公司，而技術債會愈來愈嚴重，某種程度也代表公司還在成長與發展，正面來看是一件好事。」

gipi：「你怎麼看待『債』這種東西？它一定得償還嗎？」

他回答我：「嚴重的一定得處理，否則會愈來愈麻煩。」

gipi：「你可以用投資的概念來看待償債這個問題，如果你今天借了一筆錢，將它用在公司的業務擴展上，一年下來，擴展的挺順利的，所以手上有一筆不小的現金，你會選擇一次把借來的錢還清，還是會選擇將這筆錢再次投資在其他更有價值的事情上？」

他說：「嗯，可能會還一部分，不會全還，剩下的繼續投入在更有價值的事情上。」

gipi：「觀念正確，『債』這種東西不見得立刻償還，除非已經產生一定的必要性，否則將手上的現金運用在更有價值的地方效益更大。而對技術團隊來說，現金就如同你們的開發資源，這些資源是投入在償還技術債，或者開發新的需求，一樣也得從價值的角度來思考。」

技術債，不是一定得立刻還，還不還得看它的價值。

關於專案工作的價值，可以參考我先前的文章：用商業思維談-如何有效的衡量專案價值

技術債償還的必要性

之前公司因為發展快速，沒有太多的時間停下腳步來處理技術債，許多的問題反覆出現，但engineer們往往都是用workaround來處理，例如直接下SQL更新資料、重啟服務、釋放資源、重啟主機、寫死代碼等，這些問題都隨著客戶數量增加、資料增加、開發團隊更動代碼頻率提高等各種原因持續惡化，而維運人員則疲於奔命的東補西補…

5成的時間花在workaround，5成的時間花在開發新功能，技術債？誰理啊。

除了這種典型的技術債外，還有架構設計不良所造成的可怕債務，當時的四個產品，功能其實有9成像，但這幾個產品的底層架構都不太一樣，甚至連table schema也有不小的差異。

這種問題挺常見的，在團隊沒經驗時所做的第一個產品，通常架構都挺糟糕的，而當團隊有機會做第二個產品時，會想將第一個產品做不好的地方徹底解決，因此第二個產品在架構上通常與第一個差異很大，這有個專有名詞叫第二系統效應。

而第二系統效應不只出現在第二個產品，連第三與第四個產品也都有這樣的狀況在，接手的人總想用新的架構來做新產品，因此四個產品有四個架構，要上一個新功能，必須要做四次開發工作，分四次上線。

第一個產品花1個月做完新功能，其他三個產品要花額外的2-3週來完成，明明是一樣的功能，卻要做四次。

這種架構的技術債，在任何有經驗的人眼中看來都是必然要被解決的，但老闆與業務部門通常認為這是技術部門應該解決的，一般不會主動要技術部門排入專案計畫中。這意味著，改善架構這件事不會發生。

連看起來這麼關鍵的問題，都不被納入考慮，技術部門還能怎麼辦呢？我建議，你必須試試更有效的溝通方法。

我是這麼溝通技術債的

過去我看技術團隊在跟老闆溝通技術債時，大多從技術觀點來提，例如多花了工程師多少時間，可能的系統風險等，老闆聽完這些普遍的反應是「感覺挺重要的，但我覺得還是開拓業績的專案更重要。」

在溝通技術債時，務必按著用商業思維談-如何有效的衡量專案價值，所談到的邏輯來溝通，技術債的嚴重性若只有技術人才能理解，那就很難排入top priority，我們必須用商業的語言來溝通才有機會，什麼叫商業的語言？那就是效益，所謂的效益不能是系統穩定性、效能提升、錯誤率降低這種含糊的用詞，請務必精準到收入、成本這類容易被量化與理解的數字。

舉例來說，以系統穩定度為例，原先的說詞是，這個問題偶爾會發生，每次發生時用戶會出現服務中斷問題，過去幾個月來發生的頻率愈來愈高。這段說詞貌似問題不大，但仔細想想，這段話完全無法讓我們了解問題的嚴重性，也絲毫感受不到它被解決的價值會有多大，交涉顯然是無效的。

如果我們換個說法：

這個問題從去年1月開始發生，2017年共發生了16次，2018年到目前為止共發生了58次，兩年下來總共影響了62萬人次的使用，其中有50,000個受影響用戶在問題發生後的3天內發生了退費，造成的退費金額約為5,000萬，期間帶來的客訴數量約23萬件，這是客服中心三個月的客訴總量，以客服中心人數120位來算，每位每月的人事成本為8萬台幣，額外衍生的人事成本約為2,940萬，光退費金額與人事成本就近8,000萬，平均每個月約330萬。

此外，2018年的58件中有28次是發生在最近3個月，共影響了34萬人次，光是近三個月，退費金額就超過2,400萬，問題愈來愈惡化。

第一個重點，掌握數據，讓所有人知道你是真的做了功課，而且明白這個問題的嚴重性；

第二個重點，圍繞著效益，8,000萬、330萬，這些都是大家比較能理解的用詞，可以直接拿來對比帶業績或省成本的專案；

第三個重點，說明趨勢正在惡化，所有技術債中最可怕的就是那種會持續惡化與累積的，這種技術債若不趁早解決，時間迫近時便只剩下極少數的時間能應對，屆時的壓力就不可同日而語了。

永遠要記得，用大家能聽得懂的語言來描述技術債的影響性，而別一廂情願的認為其他人天生就該聽懂你說的。

有共識後，解法也一樣重要

在上一個段落中我提到的四個產品四種架構的問題，過去曾有技術主管提出要解決此問題，當時也確實獲得老闆們的關注，但他的談法不是圍繞著對公司的效益，而是針對研發團隊重工的問題，而解法上是以「切出source code獨立專案，花兩年的時間將四個產品的架構翻新」。

但公司不可能兩年不開發新功能，如果切出source code，那兩年後還要把這兩年的新功能合併回去，這又要花多少時間？這個提案沒有經過充分的思考，最終自然是遭到否決了。

後來我們調整了提案方向與解法，新的說法是這樣的：

經過半年的調整，我們的交付週期已經從原先的三個月縮短為一個月左右，市場跟客戶享受新服務的時間已經大幅縮短了，優先享受的時間效益非常大，我們提早兩個月有更好的武器來搶佔市場，也有更棒的產品體驗來留住客戶，有效的支撐了公司的成長。

往下，我們希望能更進一步優化開發效率，但受限於目前的架構，第一個產品花一個月做完新功能，其他三個產品仍要花額外的2–3週來完成，原本一個月可以完成的功能，但終卻要三個月左右才能完成四個產品的上線，除了市場與客戶延遲享受外，業務、行銷與服務也要分四波操作，對內對外都是一種浪費。

因此，我們將會啟動架構優化的工作，未來所有新功能的開發時間將可大幅縮短，每個產品之間大約只有10-15%的工作是不同的，在同一週內完成四個產品上線將不會是難事。

而大家不用擔心，過程中所有top 10 priority的專案不會因此受到影響，我們仍會如期交付，但我們會投入額外20%的人力來同步進行優化工作，確保我們能一邊推進業務，一邊改善架構。

在三個月後我們會先完成其中兩個產品的合併，也就是說，三個月後客戶量最大的兩個產品在新功能發布時將會一塊。在九個月後則會合併完其中三個，在一年三個月左右則會完成四個產品的合併。

這一段說帖中我並沒有用到明顯的數字，因為縮短發布時間這件事本身就是個極端有感的議題，我說三個月變成一個月，這是大家馬上能感受的。

緊接著我提到我希望再加快這個速度，大家對此會產生期待，而我提出的作法是架構優化，並且說明了優化後的效益，此時多數人心裡都覺得這很好，但是，大家肯定對我接下來的作法產生擔憂，怕我是想要停下一些重要的專案來進行這個大工程，所以我緊接著說明我不會這麼做，而是從優先級較低的專案中調配資源。

最後再給大家一個預期的時間，為這個提案做一個收尾。

在思考解法時，永遠別忘了把效益放在最前頭，如果要公司停掉所有專案，那意味著這個技術債比公司任何專案都重要，但這種可能性太低了，償還技術債一般不會是priority 1的工作，但只要我們有依據的陳述它的價值，排進前10的機會還是是高的。

別總是希望一步到位，逐步交付，逐步創造價值，別想著與老闆對立，而是站在老闆的角度來思考問題，談妥的機率便會大幅提升。

上面是我在多次演講中分享過的問題解決的三段式方法，在問題發生的當下一定會有workaround，但技術債就是在一次又一次的workaround中逐漸累積出來，所以只有workaround是不行的，但workaround跟根本解所需要投入的資源差距太大，在資源排擠的狀況下根本解通常不會發生，而這便讓技術債愈欠愈多，因此我要團隊在兩者之間要加入臨時解或局部解，將根本解拆解成幾個part，一步步往根本解邁進。

技術債，幾乎每家公司都會有，思考技術債當然是技術問題，沒人喜歡有個bug在那但不解決，然而在商業場合中，我們必須將商業效益考量進來。

積極的想法，我們能站在商業角度，為公司創造更高的價值，消極一點，我們也已經預警了技術債的影響性，只是公司選擇了承受風險，到時真的出狀況時，也不好殺工程師祭旗了。