這個議題是我在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是難以避免的，因為商業世界是動態的，天天都能發佈才是一種正常狀態，只是在有選擇的狀況下，我們還是會挑選相對有把握的時間進行發布。
能在週五佈署是一種能力，不在週五佈署則是一種選擇。我認為所有的團隊都應該努力讓自己可以在週五佈署程式，因為那會讓你學會跨出邊界思考，也會讓你從源頭來探討問題，這對你將有莫大的幫助。
我相信每個技術人員在成長過程中都會有很多的疑問，對技術債、對優先級、對時程等，而每個疑問背後可能都伴隨著很多商業面的考量。期許大家在每個疑問產生時，勇敢的去探索背後的為什麼，因為那才是你進步的源頭。
