G 觀點

由 FinOps 的權威機構：FinOps 基金會（FinOps Foundation, F2）所訂定的 FinOps 框架在 2024 年迎來了改版，包含更新 FinOps 一詞的定義[1]、擴展參與和關聯的角色等，而最大的變動在於簡化 FinOps 框架中的實踐領域，並更完善各實踐領域下所需具備的執行能力[2]。下圖是 FinOps 基金會官網最新版的框架總覽圖： 資料來源： FinOps 基金會官網：Framework overview 重點更新：FinOps 定義 早期的時候，雲端的財務管理包含了使用 Cloud Cost Management（雲端成本管理）、Cloud Financial Management（雲端財務管理）一詞。 (2021): “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.

在許多場合談到最後負責時刻的時候，總是很容易引來質疑和訕笑的回應。 說到底只不過不想決定；做了再說講這麼多 最後負責時刻（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

這次訪談的對象是在中國設了研發單位的香港公司，由於 Covid-19 的影響使得這個年紀尚輕但又稍具規模的研發單位飽受困擾。該公司原先並未有明確的協作工具。成員之間的溝通靠的是線上會議和電子郵件的往來，但由於並沒有具體存放討論內容或思考內容的工具，彼此之間的知識交流也就靠著有有一搭沒一搭的零星紀錄來達成，而誤會和麻煩也就因此而起，比方說： 工作換手困難； 權責難清； 理解時間長； 資訊遺失。 即便這個新單位一開始就以敏捷的方式配置一切，最終迎接他們的就只剩下爭吵和無法達成目標。為此，他們採用了一個需求追蹤系統，其實就是自建了一個開源的知識管理工具，讓所有的人將各自的想法和平時的討論紀錄下來。這樣簡單的做法改善了他們的討論方式和協作的效率。 關鍵的改善往往勝過千萬個煙火式的實務做法，基於需求的單純解決方案，反而更有力量。當我們面對遠距協作需求時，有兩個很大的要點： 資訊共享； 體諒他人。 資訊驅動著人之間的討論。如果沒有一個共有而且即時的管道，人和人之間的討論將單純的基於假設和主觀認為。這樣的情境就算有爭吵也不會是太意外的狀況。不過，當回到了遠距，直覺上可能覺得大家會偷懶，但實際上大家更可能不知不覺地模糊了工作和生活的邊線，進而導致過勞。 因此，當團隊需要進行遠距協作，務必記得下列幾點： 提供便捷取得必要資訊的方式； 建立彼此之間的即時溝通平台； 尊重隱私並且建立溝通和協作原則； 在限制下，提供最多的團隊實體交流機會； 為他人設想。 當工作自由和生活自由重疊時，有時會造就出的不是更自由，而是更不自由且透支的狀態，而且遠距所造成的資訊不連續更是讓效率低落的元兇。此次的訪談對象透過簡單的工具（基本上沒做任何客製或特別技巧）解決了團隊工作推進的問題，並且降低了爭吵的狀況。這便是專注瓶頸解決問題的重要之處。不過，在訪談過程中，可以觀察到由於長時間遠距而加劇穀倉問題。因為他們原先透過明確職責分配和透過工具指派工作的做法，使得跨域成員之間的交流低落。或許他們接下來應該專注的是讓成員意識到跨域交流和技能學習，以及透過建立通用詞語交流需求的技巧！為此，我們還在與對方積極地保持聯絡，也期待能夠協助他們解決跨職能團隊建立和協作的問題。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.