溝通是一切的起點，而最有效的溝通在於面對面

BizDevOps 的目標在於讓商業人員、管理人員和工程師能夠有一致的目標，並且在具備共同認知的情況下協同達成目標。為了能夠達成目標且提供客觀的基礎，資料驅動是必要的方法，透過資料我們可以將產出、任務、需求、流程和商業關係聯繫起來，從而能夠透過整體的角度來思考需求並且制定權衡的政策。

有了權衡的政策，下一步便是找出需求和制訂計劃，並且透過團隊的工程能力來實現需求。這一連串的過程涉及了不同人事物的溝通和資訊交換。單純地透過文字是很難在第一時間將彼此對齊在同一個認知上，需求的利害關係人必須面對面地確認和協調需求的樣貌。

基於面對面的溝通也才能有效地勾勒出需求的輪廓並且找出具體的實例來協助團隊中的每一個成員，運用自身的能力來實現需求。

完整的團隊仍然是一個關鍵要點

傳統組織按職能區分人員結構，這讓組織人才的技能得以深化且經驗得以順利傳遞，但這也使得面對面的溝通變得困難，甚至是讓不同職能的人對齊組織的價值目標也變得困難。畢竟每個人都專注於一整件事情的某一部分，對該部分負責也對專責的技能負責。

為了突破這種僵局，思考如何在組織內按照價值目標組建一個 5~15 人以內的完整團隊，就變得關鍵，但只是把一群人集合起來就想要獲得一個高效的團隊，這仍然是把事情想得過於簡單！不同的背景、不同的能力、不同的個性和各種不同會讓新組建的團隊深陷在風暴中，難以逃出，所以想要讓團隊快速脫離磨合期並且持續改善成長。團隊務必找出：

  1. 團隊協定:人與人之間合作的方式
  2. 任務標準:處理事情的標準

透過找尋協定與標準，會幫助團隊更加了解彼此，並且知道團隊內的障礙。

一個團隊就能夠頂全部的產出?

除非公司自行開發的資訊軟體很少或沒有，而且也不太使用軟體服務，否則單靠一個小團隊就要面對各種問題，恐怕團隊也會隨著組織的增長而慢慢吃不消。

因此，我們必須思考如何組建一個有機的大團隊！

有機的大團隊以拓樸的角度看待每個自組織的小團隊，讓大團隊中的各種能力可以發揮在必要的目標上，而且也不會因為強迫拆分所造成部門牆導致價值目標的破碎和工作依賴所造成的浪費。

不過，就像團隊內需要有協定與標準！團隊之間也需要有協定和標準，以便讓各團隊之間可以快速地進行協作達成目標。團隊期待他人(團隊)與其合作的方式和標準就是團隊的 API。簡單說就是團隊的使用手冊

不管組織是透過自組織方式來組建各種團隊還是透過組織情境與需求來組建團隊，我們都可以透過團隊拓樸1的概念來思考。按照《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一書中所言，組織裡的團隊按照其交付內容的質性可以分為四種基礎類型：

  1. Stream-aligned 團隊: 一個能夠實際交付端到端商業價值的團隊
  2. Enabling 團隊: 探索新產品、技術和做法並且可以將這些新事物按照團隊的需要導入到各團隊中，從而消除障礙並且提升交付能力的團隊。這樣的團隊需要注意三件事：
    • 識別障礙
    • 按情境展示新事物
    • 引導而非代勞
  3. Complicated subsystem 團隊: 負責軟體服務中的獨立組件或服務的團隊。這類獨立組件或服務往往高度需要特定領域的技能且具備一定複雜度和穩定性。
  4. Platform 團隊: 此團隊提供必要的開發平台與工具來加速交付和守護組織重要政策(比方說工具鏈中的安全準則)。platform 的重點在於必要性而非全面性。這要點在越是龐大的工程組織更是重要，過度客製化的平台往往會造成另外的浪費，而非增加整體的價值。運用最薄可用平台(Thinnest Viable Platform, TVP) 和政策護欄(guardrails) 是最好的做法

這四類團隊會在組織中以三種不同的方式來互動，分別是：

  1. 協作: 團隊成員之間會彼此緊密合作，此時工作交接很少而且分工也較不明確。由於人數增加且需要磨合。認知負擔會變高有可能導致產出(暫時性)的下降。不過，探索團隊往往會是此類團隊。
  2. XaaS: 團隊彼此的分工明確，而且可能彼此之間是透過各自服務的介面來合作。這類協作重點通常在於介面的設計。
  3. 引導: 如同 Enabling 團隊中所述，這類溝通重點在於識別問題、引入做法和引導落地，所以很需要溝通與協調能力。

團隊 API

這四類團隊和三種互動模式都會需要溝通和協作，而提高溝通和協作的順暢度的最好作法便是稍前所提的團隊 API。

那到底團隊 API 有哪些呢？

從團隊拓樸一書中，可以看到 5+1 種主題，分別是：

  • 程式碼和程式碼相關的產出(Code)
  • 版本與變更方式(Versioning)
  • 文件(Document)
  • 團隊偏好的工作方式(Practices and Principles)
  • 溝通工具
  • 其他: 任何因應各自情境，而有易於團隊之間彼此合作的主題或內容

好啦! 說這麼多~! 要記得一件事就是不管是團隊內或團隊間都要 了解對方原則，並且找尋彼此最好的協作原則。老話一句：若有不清楚的時候，能面對面就不要打電話，能打電話就不要寄信，能寄信就不要枯等著摳破自己的腦袋。

最後小小工商一下

CPHT 對 DevOps 有著最完整的了解與掌握。
如果您想要擁抱 DevOps 或想要追求更好的 DevOps 實現，歡迎聯絡我們！
讓我們與您一同從轉變中找出未來的可能性。

1. 高效能團隊模式：支持軟件快速交付的組織架構 (Team Topologies: Organizing Business and Technology Teams for Fast Flow)