靖本

溝通是一切的起點，而最有效的溝通在於面對面 BizDevOps 的目標在於讓商業人員、管理人員和工程師能夠有一致的目標，並且在具備共同認知的情況下協同達成目標。為了能夠達成目標且提供客觀的基礎，資料驅動是必要的方法，透過資料我們可以將產出、任務、需求、流程和商業關係聯繫起來，從而能夠透過整體的角度來思考需求並且制定權衡的政策。 有了權衡的政策，下一步便是找出需求和制訂計劃，並且透過團隊的工程能力來實現需求。這一連串的過程涉及了不同人事物的溝通和資訊交換。單純地透過文字是很難在第一時間將彼此對齊在同一個認知上，需求的利害關係人必須面對面地確認和協調需求的樣貌。 基於面對面的溝通也才能有效地勾勒出需求的輪廓並且找出具體的實例來協助團隊中的每一個成員，運用自身的能力來實現需求。 完整的團隊仍然是一個關鍵要點 傳統組織按職能區分人員結構，這讓組織人才的技能得以深化且經驗得以順利傳遞，但這也使得面對面的溝通變得困難，甚至是讓不同職能的人對齊組織的價值目標也變得困難。畢竟每個人都專注於一整件事情的某一部分，對該部分負責也對專責的技能負責。 為了突破這種僵局，思考如何在組織內按照價值目標組建一個 5~15 人以內的完整團隊，就變得關鍵，但只是把一群人集合起來就想要獲得一個高效的團隊，這仍然是把事情想得過於簡單！不同的背景、不同的能力、不同的個性和各種不同會讓新組建的團隊深陷在風暴中，難以逃出，所以想要讓團隊快速脫離磨合期並且持續改善成長。團隊務必找出： 團隊協定:人與人之間合作的方式 任務標準:處理事情的標準 透過找尋協定與標準，會幫助團隊更加了解彼此，並且知道團隊內的障礙。 一個團隊就能夠頂全部的產出? 除非公司自行開發的資訊軟體很少或沒有，而且也不太使用軟體服務，否則單靠一個小團隊就要面對各種問題，恐怕團隊也會隨著組織的增長而慢慢吃不消。 因此，我們必須思考如何組建一個有機的大團隊！ 有機的大團隊以拓樸的角度看待每個自組織的小團隊，讓大團隊中的各種能力可以發揮在必要的目標上，而且也不會因為強迫拆分所造成部門牆導致價值目標的破碎和工作依賴所造成的浪費。 不過，就像團隊內需要有協定與標準！團隊之間也需要有協定和標準，以便讓各團隊之間可以快速地進行協作達成目標。團隊期待他人(團隊)與其合作的方式和標準就是團隊的 API。簡單說就是團隊的使用手冊 不管組織是透過自組織方式來組建各種團隊還是透過組織情境與需求來組建團隊，我們都可以透過團隊拓樸1的概念來思考。按照《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一書中所言，組織裡的團隊按照其交付內容的質性可以分為四種基礎類型：

SBOM 雖說 VEX 並不盡然需要依賴於 SBOM，但在討論 VEX 之前，肯定必須先了解一下 SBOM（Software Bill of Materials, 軟體物料清單），因為這樣才能了解 VEX 的必要性和它所想解決的問題。 軟體物料清單提供了軟體組成的相關資訊。這些相關資訊會說明這些組成是由誰提供、由誰開發、包含哪些項目、何時建置和依賴訊息等訊息。這些資訊對於提升軟體的透明度相當有幫助。因為使用者能夠透過這些資訊了解該軟體所採用的套件或其他工具是否存在可被利用的漏洞而需要立即進行修補。 SBOM 之所以受到關注還是要歸因於從 2020 年後的三起重大的資安事件，包括 Solarwinds[1]、燃油管事件[2]和 Log4j[3]。這三個重大資安事件促使美國總統在 2021 年時簽署了行政命令，責令美國商務部和美國國家電信暨資訊管理局（National Telecommunications and Information Administration, NTIA）需要在 60 天內制定 SBOM 的最基本要件。雖然 SBOM 對提升透明度的確有所幫助，但它畢竟仍是一個靜態的資訊。軟體使用者仍需要從軟體供應者處取得該軟體相關組成的漏洞狀態，才能夠進一步確認當前軟體受到漏洞影響的狀態，而 VEX 正是提供此關鍵訊息的機制。

由 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