fbpx

關於技術債,我是這麼看,這麼處理的

Image for post

上個月在一場演說中,有聽眾問到技術債的問題,他說:「公司內有很多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的機會還是是高的。

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

Image for post

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

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

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

2021商業思維學院招生中,早鳥優惠最後倒數
若想了解更多關於商業思維學院,可觀看下面影片喔!


立刻報名去

發表迴響

早鳥優惠實施中手刀報名
%d 位部落客按了讚: