fbpx

技術工作者的商業思維,從解決問題到探索問題

這個議題是我在MOPCON 2020上分享的議題,去年我談的主題是「技術人員如何陳述自己的商業價值」,有興趣聽的朋友可以自行上Youtube去聽,而今年我想進一步將一些大家常見的疑問與場景拿出來聊。

在技術圈裡,總是會有一些很常見的問題困擾著年輕朋友們,像是技術債、技術提案、跨部門溝通、開發方法,或者是最近很夯的Deploy on Fridays,我覺得都很有代表性,不過議程只有40分鐘,所以我想從裡面挑2個做為範例,讓大家瞭解一下從商業角度,我們會如何看待這些議題。

其實技術債、技術提案、跨部門溝通、開發方法、Deploy on Fridays這些議題,其實都是商業決策的一環,既然其他的決策是有憑據,有方法的,技術問題怎麼可能跳脫這個邏輯呢?我最後挑選的兩個議題是技術債Deploy on Fridays

完整的簡報在此:https://www.slideshare.net/shufanyu/ss-238968691

技術債,一定得還嗎?

這是我在一開頭拋出的問題,現場大約有1/4左右的聽眾舉手了,雖然大家應該都猜到我的答案了,但我不急著講我的想法,而是拋出另一個問題。

「請問,你欠債會還嗎?」,針對這個問題,多數人都舉手了。這個結果讓人感到欣慰…XD

我接著問:「如果你有助學貸款、房貸、車貸,這些都是貸款,而你手上剛好有足夠的錢,請問你會一次還清,還是慢慢還呢?」

針對這個問題,大家就沒那麼有把握了,不過按正常人的做法,通常我們不會一次還清,而是會思考還多少,怎麼還對自己生活才是最恰當的。聽到這,其實有些了解我想表達什麼的聽眾開始點頭了。

我說:「多數人的決定是不會急著一次還完,因為還慢一點死不了。」

接著,我又舉了另一個例子,我問大家是否有熬夜習慣?其實這應該算是年輕工程師的生活慣性,加班、熬夜算是稀鬆平常的事。我問大家:「各位都欠了很多的睡眠債與健康債,醫生跟你媽苦口婆心的勸你要早點睡還債,你會還嗎?」

答案一樣「不會,因為還慢一點死不了」。

不過呢,有一些債務我們會盡快還掉,例如高利息的貸款,卡債等等,這些債還的慢對我們會有不良的傷害,因此在能力可及的範圍,我們會盡快處理掉這些債務。

債還不還,或者怎麼還,這個問題得看手邊這筆錢,到底拿來還債效益大,還是拿來做其他事情效益大,如果是後者,將償還債務這件事放在比較低的優先順序也是合情合理的

同樣的概念,我們可以來看技術債,技術債並非一定得還,就算要還,也不見得得立即動手處理,而是得從商業角度綜合思考,這個時間點,我們究竟要把資源投入在解決技術債,還是要投入在開發新功能上

先讓大家了解了這個概念後,我舉了一個過往我們處理技術債的,並讓技術債處理可以在需求超多的狀況下,被優先配置了開發資源,這個案例我在另一篇文章中有提到,大家可以直接看這篇文章:關於技術債,我是這麼看,這麼處理的

總之,溝通技術債的關鍵在於以下三點:

  • 第一,掌握數據,讓所有人知道你是真的做了功課,而且明白這個問題的嚴重性;
  • 第二,圍繞著效益,8,000萬、330萬,這些都是大家比較能理解的用詞,可以直接拿來對比帶業績或省成本的專案;
  • 第三,說明趨勢正在惡化,所有技術債中最可怕的就是那種會持續惡化與累積的,這種技術債若不趁早解決,時間迫近時便只剩下極少數的時間能應對,屆時的壓力就不可同日而語了。

如果你自己做過這樣的評估後,覺得這個技術債現階段其實重要性並不高,那當被老闆回絕時你也不用太傷心,因為這只是正常的商業考量。

Deploy on Fridays

有了技術債這個開頭,我想大家對於面對技術問題的商業思維應該有了一定的理解,緊接著我想談的主題就是近期很夯的Deploy on Fridays,這個題目近期已經有很多技術圈的大大提過,我只是蹭個熱度來聊聊這個話題。

我舉的例子是我在2015年在公司,並接手維運負責人的那段經驗,我們是如何處理development、deployment跟operation間的議題。

2015年,我剛進公司時發現,公司是隨時都可以佈署,早上可以、中午可以、晚上也可以,然後週一到週日都可以。

按理來說,這是個正常狀態,如果一切都順利的話。不過很可惜的,當時的狀態是佈署問題一大堆,更版後出錯的機率非常高,而且三不五時會把系統搞掛。

「Deploy any time, crash every day.」這或許稍嫌誇大,但每天都有狀況道是不爭的事實。

而且當時我們雖然有stage跟production環境,但兩個環境的相似度大概只有50%,所以在stage上測試正確的程式,上了production可就不一定了。不過當時有些同仁告訴我「放心,在stage上有問題,上production就沒事了。

當我聽到這樣的說法時心裡是冷汗直冒的,所以那時候我們真的實踐了Ant說的「Testing in production」,差別在於我們是不得不這麼做,因此把production搞掛也算是家常便飯了。

我剛進去的前幾個月,我們一直suffer在這種詭異的狀況下,不過我們團隊自己倒是很快就把版控機制建立起來了,也建立了我們自己的測試環境,所以自己團隊內的問題還是比較少的。直到同年的7月份,我自薦去揹維運,因為我覺得我不把整個維運的機制搞好,整個研發團隊都會浪費超級多的時間在這些low value的事情上,一點意義也沒有。

我接任維運負責人沒多久,我就做了一個決定,我開始管制所有部門的佈署時間,從以前的每天都可以佈署,轉變成每週只有二、四這兩天可以佈署

那時,我給團隊、橫向部門以及上級主管的說法是「我們每天耗費在準備佈署、測試、出問題、rollback、重上的時間實在太多了,而且團隊與團隊間還會互卡,因此衍生了更多的問題,我相信這幾個月大家應該都感受到了。所以我想要限制佈署時間,每週只有二、四可以上線,一來降低佈署次數,PG會有更多時間處理開發工作,二來發佈的時間集中,一旦有問題也很容易掌握是否跟發版有關,也可以做盡快的處理。」

當限制佈署的效益大於每天佈署的效益時,限制佈署時間就是一個正確的商業選擇。

面對這個policy,第一個提出疑慮的不是業務部門,而是RD自己,一位RD主管說「這不可行,業務部門不會答應的,他們會把我們修理的滿頭包」,我給他的答覆是「各部門主管那邊我會親自溝通,如果你還有碰到阻礙的話跟我說,我來處理」。

訊息發布當天,行銷部門提出了他們的疑慮「我們行銷的素材常改,landing page也常常換,不可能只有二、四佈署。」,我們討論了一下,後來認為landing page的系統本身與主系統是分割的,而且landing page的修改90%以上都是前端與畫面上的調整,不太涉及後端,找了幾位資深員工討論,大家都認為這部分就算佈署出錯,也不會影響主系統。

所以我給的回覆是「landing page部分不在此限,可以由marketing team直接處理,隨時可以更新,不過marketing的其他系統則依然要依循規則二、四上線。」,marketing team表示沒問題。

第二個提問:「如果業務部門就是要在禮拜三上線怎麼辦?」

我說:「狀況分兩種,第一種,如果這個上線是具有策略性意義的,那太早上或太晚上都不行的話,那我們當然要配合,不可能讓商業目標來遷就技術。第二種,如果是內部系統或不具策略性目的的專案,我相信需求單位不會介意你提早在週二上線,這是規劃問題,不是這個制度造成的問題。」

第三個提問:「如果問題嚴重,今天真的要緊急上線怎麼辦?」

我說:「這些問題肯定是有的,但我相信我們應該能判斷哪些問題具有這麼高的急迫度,如果判斷完後一定得在非佈署日發佈,那務必經過三位最高主管其中一位的同意,並提出佈署需求,我們就走緊急流程處理。」

我們設定了規則,但同時也定義了例外與緊急處理程序,在程序上該顧的基本都顧上了。


之後,新的流程開跑了,不過我們額外做了三件事。因為要推動新的政策,我們必須要確保這個新的政策能獲得好的結果,並且盡可能縮短這個過渡期,畢竟限制佈署只是一個階段性解法,長期來說還是得有隨時佈署的能力。

在那段時間,我們另外做了哪三件事呢?

  • 第一,盤點近期公司內的重要專案,確保這些專案可以準時上線,以免二、四上版的這個新政策到時被拿來當箭靶
  • 第二,push所有的研發團隊建立版控與自動化佈署的機制,確保我們爭取到的這段時間,大家真的是把資源放在解決佈署問題
  • 第三,扮演研發部門與業務部門間的溝通橋樑,藉由一次又一次的溝通成功,來改變研發部門對業務部門的刻板印象(難搞、無理、難以溝通),也改變業務部門對研發部門的印象(聽不懂人話、愛推責任)

所以後來這個政策落實的蠻順利的,不僅僅讓佈署的問題大幅減少,大家花在處理佈署的時間也降低很多,加上版控機制的建立,跨團隊的開發也順暢了很多,當然了,維運的議題也大幅的減少。

三個月後,原先不看好這個政策的研發主管來找我聊,他說:「老大,當時沒想到這件事可以,但竟然這麼順利,到底為什麼以前我們搞不定的,你可以搞定呢?」

我提出了五點原因:

  • 做事沒彈性,設定了作法就不容調整,所以一定會被挑戰,砲火太過猛烈就選擇放棄,
  • 遇事不堅持,遭遇一些挑戰後就全面退讓,但明明只要定義出例外就好,對的事情還是要咬緊牙關堅持,
  • 提案沒說服力,時常都從技術角度出發來提案,對業務部門或老闆來說,是缺乏說服力的,
  • 逆著商業思考,技術是用來解決問題的,在商業組織中,技術得服務商業,但我們卻常常反過頭來要商業遷就技術,
  • 忽略人性,其實橫向部門也好,老闆也好,大家最在意的還是事情能否完成,問題能否解決,至於你們用什麼方法解決,他們真的不在意,不過你們太害怕與他們溝通,這才是雙方誤解愈來愈深的關鍵原因。

最後我總結了一段話:

「阻礙你與團隊的,往往都在你的職務邊界之外。」

你沒有資源處理技術債,很大一部分原因是商業決策上的問題,
別人不能配合你做二、四佈署,主要原因是他們的問題沒有被解決,
老闆不同意你始用心的技術框架,這可能是他看不見必要性…

這些事最終的決策者都不是你,所以這些事基本上超出你的職務邊界,如果你願意跨過邊界去溝通,去了解,去影響對方,那你才有可能突破目前的困境,反之,站在自己的圈圈內不願意往外看看,你永遠都會遭遇一樣的問題。


故事繼續,三個月的時間,我們有了蠻大的推進,不過技術債的問題還是非常嚴重,許多的工程師都是白天趕案子,晚上on-call。這時我決定要招募全職的維運人員,所謂的全職指的是他們的主要任務就是維運,負責做問題處理的一線,也負責值夜班與大夜班,這個維運團隊的成立,為各部門爭取到更多的緩衝與休息時間,也讓大家真的可以更focus在改好系統的技術架構。

不過呢,我們在一開始就說明了,這個全職維運團隊的任務是暫時性的,最終維運責任還是得回到各自部門。

Eating your own dog food.

你自己亂寫的程式,亂搞的架構,隨意的承接需求,不配置時間去修改技術債,然後要維運團隊幫你扛,這一點都不合理。

而且我也相信,一個專業且負責任的研發團隊,應該懂得在開發時同時思考維護與維運的問題,而不是走一步算一步。當我們將標準拉高到這個層級,多數的團隊在半年內都跟上來了。

而當大家的水平上來了,我們就開始放寬限制,對於緊急上線的判斷,開始交由各系統的負責人決定,不用再找最上層主管;對於佈署時間與測試形式,也交由各團隊自行決定,而我們對維運的唯一要求只有「不影響商業推進」,所以後來我們每週只看每個系統的SLA(Service Level Agreement),這個數值基本上是由系統可用時間反推回來的,我們要確保系統的主要功能的可用時間>99.9%,也就是一個月的總異常時間不能超過43.2分鐘。

一開始多數的團隊都做不到,因為這個標準實在蠻高的,但隨著這個目標的頒布,大家思考的不僅僅是佈署問題,也開始檢討架構,包含系統與軟體架構,然後進一步推到需求管理與商業面的議題,這就形成了一個正面的循環,團隊開始學著從源頭來解決問題,而不再等待業務單位來提出需求,然後扮演被交辦任務的一方

解決問題得從源頭下手,但源頭的問題通常都在你的工作邊界之外,你要不跳脫邊界,要不就是繼續在原地踏步。

最後回到Deploy on Fridays這個議題上,其實我的觀點跟幾位大神是一致的。

Deploy on Fridays是難以避免的,因為商業世界是動態的,天天都能發佈才是一種正常狀態,只是在有選擇的狀況下,我們還是會挑選相對有把握的時間進行發布。

能在週五佈署是一種能力,不在週五佈署則是一種選擇。我認為所有的團隊都應該努力讓自己可以在週五佈署程式,因為那會讓你學會跨出邊界思考,也會讓你從源頭來探討問題,這對你將有莫大的幫助。


我相信每個技術人員在成長過程中都會有很多的疑問,對技術債、對優先級、對時程等,而每個疑問背後可能都伴隨著很多商業面的考量。期許大家在每個疑問產生時,勇敢的去探索背後的為什麼,因為那才是你進步的源頭。

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


立刻報名去

發表迴響

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