轉型與變革

什麼是遺留系統？ 遺留系統指的是已經運行多時，具有一定商業價值，但隨著時間推移，逐漸面臨架構、技術、軟體版本等過時問題的系統。 為什麼需要面對遺留系統❓ 由於遺留系統在商業營運上仍然有其必要性，因此往往難以輕易汰換。隨著新的商業需求出現，系統在過時的基礎上變得越來越難以修改或擴充。在某些情況下，即使發展新的系統，甚至會因為系統間的高度耦合，使其無法如預期般的退場。 遺留系統除了面臨維護成本逐漸上升，穩定性往往也會開始下降，最終導致工程團隊疲於應對與維護。因此，我們必須誠實地面對遺留系統所帶來的風險，並尋求長遠的解決策略。 跨出改善的關鍵活動 在 CPHT 進行遺留系統評估與改善輔導案的過程中，除了探尋從過去到現在商業決策的脈絡，同時也包含了挖掘第一線工程人員的認知與想法。其中幾個關鍵的活動： 遺留系統與技術債的評估 團隊拓墣與服務邊界的梳理 日常工作流程的梳理 人員對於負責系統、職務等的掌握度與適應性 每個系統的形成與演變，必然有其歷史背景與脈絡，其中包含當時的商業需求、組織樣貌、技術趨勢等。而從商業到工程之間的分析活動也意味著推動任何的改變都必須彌合商業與工程的落差。否則，即使出發點是為了改善遺留系統，眼前所採取的方案仍可能成為潛在的技術債，並在未來反噬！ 由於輔導的企業涉及上百人團隊與上百個長達五年甚至十年以上的軟體系統，因此透過這些盤點作業來梳理現況也至關重要。在現況盤點後，我們更能針對架構發現與顯著技術債來尋求在商業需求層面、技術層面、治理層面的長遠處置策略，以及在下一階段聚焦關鍵的改善活動。值得一提的是－去年幫助企業進行遺留系統評估與改善規劃後，最近 CPHT 也和客戶一起動起來，努力把改善計畫變成實際行動！ – 如果你也正在思考如何組織內的資訊系統與流程內追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

說到 DevOps 免不了會讓人直接聯想到各式各樣的工具，而這也是 DevOps 之所以能夠加速軟體生產力的方法之一。 工具的使用，如果只限於個人，那麼就只是個人的意願問題而已，但如果把工具引入團隊內，那麼這問題就會稍稍變得複雜！比方說： 團隊內的成員是否熟悉這類工具？ 工具要如何融入團隊目前的工作模式？ 如果是工具舊換新，那麼資料要如何遷移？ 團隊是否有空做出改變？ 工具使用的成本是否可以承擔？ 講到這裡是不是開始覺得一陣頭昏腦脹了呢？不過就用個工具嘛！ 可別在這邊危言聳聽~ 上述的問題，運氣好的話的確有可能經過一陣摩擦後順利落地。運氣好不好這得端看工具影響的範圍和深度而定，結局就又回到上述各個問題。筆者就曾經遇過團隊花了大價錢買了工具全年的訂閱也請了外部講師做了一套培訓，結局是工具從一開始的零星使用到最後無人使用。這樣的故事並不少見，而當工具導入擴及到全組織時，那問題就又顯得更加麻煩。當然講到這邊都還只是提到工具而已，而 DevOps 可不只有工具，還有許多工程上的最佳實務做法… 所以到底該怎辦比較好？ 掌握工具或實務做法的影響範圍是做出任何改變的重要第一步！ 流程說穿就是完成一件事情的一連串活動和做法。如果我們能夠了解導入目標所相關的流程的話，那不就可以順著流程知道哪些活動、人和工具會受到影響，從而掌握影響範圍。因此，筆者在協助企業進行各式 DevOps 導入時，第一件會做的事情就是進行流程對照(Process Mapping)的活動。流程對照名詞聽起來很厲害，但其實就是透過視覺化的方式來把做事過程塑模下來的活動。進行這類活動有以下幾個步驟：

在許多場合談到最後負責時刻的時候，總是很容易引來質疑和訕笑的回應。 說到底只不過不想決定；做了再說講這麼多 最後負責時刻（Last Responsible Moment, LRM）指的是延遲決策造成的代價高於決策成本的時間點。簡單說就是期望在擁有最多必要資訊且還有賺頭時來進行決策，以便讓決策最貼近解答。只不過這個時刻往往是答案呼之欲出的時間，再不做出決策，那就是被決策了！理論上來說，這的確是一個很甜蜜的決策點，然而回到了現實，最後負責時刻彷彿成了拖延病或衝動的理由。 最後負責時刻聽起來很簡單，但基於這個概念做出決策前，其實有兩個要件需要思考，分別是：決策情境和資訊取得方式。 當處在「繁雜（Complicated）」的決策情境時，決策者可以透過分析資訊來了解該採取何種行動，而且在此情境下，想要收集哪些資訊和如何收集是相對清楚的，這是因為因果關係仍然可以理解。因此，最後負責時刻在這樣的情境下有最大的效益和清楚的時機點。至於「明確（Clear）」的情境就更不用說了，相關的資訊可能在映入眼簾的當下就已經清楚明確，而手邊也早有應對之策。從得知到決策到採取行動或許順暢到連決策者都沒有感覺到做了決策。 當情境變得模糊不清且「複雜（Complex）」時，資訊取得的手段往往需要額外採取行動，而無法單純靠既有機制來收集足夠的資訊。比方說，需要透過 MVP 或 A/B 測試來了解真實情況，然後再依據結果來做出最後的決策。這個時候會出現一種先行動再決策的直觀感受。如果決策情境進一步複雜到「混亂（Chaos）」狀態時，打帶跑的現象就會更明顯，而且被推著跑的感受也會跟著明顯。在這些情境下，行動被提前至最終決策之前，甚至最終決策的樣貌都慢慢不易被描出框線。決策和行動之間的界線變得模糊，而使得決策就像是被拖著，然而這卻是情境使然。最終，決策者仍需做出決策，而且必須加緊速度在嘗試仍然有效前做出決斷。 尚不論 Cynefin 的中央區域，其四種情境也只有「繁雜」情境在感受上有較為清楚的決策時刻，其餘要不是過於明確要不就是需要多試試。這讓最後負責時刻感覺起來顯得就像是遲延決策、沒有決策或不用決策做了再說的代稱詞。 在當前的商業與科技進展下，VUCA 就像是一種常態。最後負責時刻其實是相當重要的概念和原則。它能夠降低決策風險，讓組織更容易適應變化。決策終究是要下的，只是有時它需要一些前期的準備。與其埋怨決策被拖延了或沒人要做決策，倒不如思考如何提出一些行動來獲得更多資訊，以便最終決策的進行。不過有時團隊成員對於決策者的不耐煩有可能來自於資訊落差，所以身為決策者應該讓成員了解事情的梗概並且保持必要資訊的透明，而不是忍著而最後成了團隊的瓶頸點，這不僅無法提升決策效率，也會傷了團隊的凝聚力。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

這次訪談的對象很有趣，為什麼有趣呢？主要是因為受訪者是一家證券商的乙方，而此次談論的主體卻是甲方。受訪者並不是因為想八卦或吐苦水，倒不如說他展現了對於甲方環境的認同感。究其原因或許是配合的時間長而且甲方在領導上也有獨到而體貼之處吧！？不過再深入就變成相談所八卦了，讓我們趕緊來聚焦一下今天的主題吧！ 一如常見的配置「業務單位是需求方，IT 單位是實作方」，而這樣配置也出現了一如往常的問題。那就是需求模糊和實作衝突與延遲的狀況。不過，幸運的是甲方領導者對此有所認知，並且也公開支持透過迭代和需求規劃調適等方式來處理，而且還為此制定了需求拆解和評審的機制，然而不幸的是這些做法最終卻在現場撞個粉碎，沒有產生具體的效益。 日子仍然一如往常 價值總會在情境轉換時產生失真和磨耗，透過敏捷的方式能夠讓團隊聚焦於資訊充足且重要的需求上，但這一切都需要商業和工程雙方的搭配 才能夠達成。這不只是工程上的最佳實務做法，也是實現商業價值的最佳實務做法。雖然受訪者單位的領導者支持相關的改善，然而在訪談過程中可以觀察到幾個問題： 商業端最高主管高於工程端最高主管，使得商業端與工程端的衝突並沒有對等的糾紛處理平台，而且也會使得技術人才從組織中流失，或者只寧可轉往做人和商業方向前進，因為這樣才能獲得更好的發展。這種情況對於高度依賴資訊系統的商業體來說是相當危險的事情！這意味著組織裡的資訊系統會因為人才經常性流動而無法培養出具備技術且熟稔該系統的人員，進而使得組織在資訊系統危機處理上相當脆弱。這種不對等狀況也自然會反應在需求分析與調適上，畢竟商業說了算，而且研發人員的經驗相對資淺也難以做出合適判斷。 有條件地忍讓無法為改善做出調整的人。在組織中進行改善是一件涉及所有利害相關人的活動，所以不僅要謹慎地確立目標，而且也需要堅持目標。如果會因為組織中某些較為資深或任何具備特殊條件的人而有所轉彎，會使得其他參與者傾向取得特殊條件或推託執行。改善就只能往失敗的方向前進。 比較讓人感到遺憾的是在訪談過程中也發現了敏捷萎縮的狀況。由於長時間無法達到改善目標，而開始改採評審和各種細節規則的管理措施。倒不是說評審或細節管理不好，而是當制度的設計無視遵守者所處的決策情境時，就會導致制度失效、時間浪費和心理不安全的情況。雖然上述的狀況不容樂觀，但受訪者仍對於所處環境和工作抱持著熱情。訪談就在一來一往過程中接近尾聲，而我們也為訪談過程中的疑問提供了解答和一些改善舉措，並且約定後續保持聯繫來繼續提供建議和支持。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro