Team Topologies - 團隊優先思考模式

Source: Team Topologies Chapter 3

 

距離上一次聽到作者的演講，並且寫了一篇：微服務架構或單體式架構?先從團隊認知負擔談起，也經過了一年多了，一直都沒時間靜下心來好好讀這本書。

直到最近漸漸開始感受到切身之痛，是時候該好好把這本書讀完（臨時抱佛腳的概念），隨著組織業務增長，團隊也越長越大，團隊之間需要更有效的橫向溝通與協做模式，此外組織為了要在業界佔有一席之地，也必須不斷的加強 domain knowledge 與技術深度，團隊成員都有種要爆的感覺，但是卻又無法具體的描述具體原因出在哪裡？因為人力資源不夠？這是每間公司都會遇到的問題阿，有哪間公司會說自己人太充足的？是因為團隊成員能力不足？其實團隊成員的能力也都是一時之選，那究竟問題出在哪裡呢？很有可能就是在於組織架構和協做溝通的方法。

Conway's law 橫跨本書的康威定律

首先先從康威定律開始講起，所謂的康威定律就是：

組織內團隊組成的架構，就會直接影響你的軟體系統架構會長成什麼樣子。因為團隊架構決定溝通模式，溝通模式就會影響軟體系統架構。

如果要讓團隊進入高效的 fast delivery flow ，首先就是要規範（限制）團隊的溝通模式，這讓我想到網路上流行的這張圖，這也很可能反映了這間公司的軟體系統架構。

 

 

除了康威定律，本書的另一個重點就是鄧巴係數....

Dunbar 鄧巴係數

根據社會學家 Dunbar 的研究，團體中可以深入互相信任且 share working memory 得人數基本上大概是 5 個人左右，極限就是是 15 人，而能互相信任的上限大概就是 50 個人，當超過 150 人時就已經高過了社交認知的上限，就連要記住對方的名字都很難。

所以根據 Google 內部長時間的研究，各個 Team 之間得 dynamic （動態互動）對於產出的影響，遠遠大於有某個大大在某個團隊裡面。而會影響團隊動態互動的因素有哪些呢？

• Team Size 團隊大小
• Team Lifespan 團隊能固定在一起工作的時間
• Team Relationship 團隊成員之間的關係
• Team Cognition 團隊的認知
  

所以本書的第一個前提就是，好的團隊基礎就是『小巧精幹且長存的團隊』

這邊小的定義就是 5~9 人，固定的團隊成員一起為了一個目標工作得時間至少一年以上。

為什麼這邊提到至少要一年以上呢？因為根據 Tuckman's stages of group development 提到一個團隊到組成到真的可以產出績效，至少都會經歷以下四個階段：

1. Forming 組成階段：英雄來自四面八方，人員陸續補充進來，很少一步到位
2. Storming 磨合風暴階段：八國聯軍要怎麼變成利益共同體，需要花時間習慣彼此
3. Norming 形成團隊階段：團隊逐漸演化出標準的流程方法與默契
4. Performing 績效產出
   

 source: The Five Stages of Team Development

但要知道的是，從 2 ~ 3 其實是會一直持續發生的，因為每次有人離去和新人加入，團隊成員的家庭和生理狀況變化，以及隨著團隊成熟度與業務量的變化，都會產生新的化學變化，這也是團隊的績效產出為什麼會一直變化。不是可以簡單用缺人加人就可以解決的問題。

 Team Fist Mindset 團隊優先思考模式

所以什麼是團隊優先思考模式？

• 團隊對某個軟體（系統）負責，並且持續的關注與改善
  
• Daily 要承諾參與並且不要遲到
• 團隊對於內部事務要持續討論
• 專注在 Team Goal
• 幫助他人移除 blocking thing
• Mentor 新人，互相幫助成長
• 避免爭輸贏的爭論，要能包容探索各種可能性的言論
  

 

此外如果要讓團隊能以高效的模式運作，首先要以小巧精幹的長存團隊為單位，並且限制與減少不必要的溝通，這邊所謂限制不是說讓團隊互相 silo 老死不相往來，而是並不是所有的交流的都是好的和必要的，其實就跟系統開發一樣，一開始也許大家都可以互相 call 來 call 去，但是隨著系統變大邏輯變複雜，團隊與團隊之間要建立溝通的規範與 API Interface 就跟軟體一樣。

為什麼會要定 API Interface 這引出下一個話題：Cognitive Load（認知負擔）

Minimal  Cognitive Load （最小化的認知負擔）

話說我們每個人的 working memory 其實是很有限的，所以要慎選佔用我們記憶體的事物，而書中提到 Cognitive Load （認知負擔）其實還可以分成三個種類：

• Intrinsic Cognitive Load （內在認知負擔）：比如說瞭解 Code 怎麼寫
• Extraneous Cognitive Load（外在認知負擔）：比如說要怎麼 deploy
• Germane Cognitive Load（有意義的認知負擔）：比如說 Service 之間怎麼溝通

 

 

根據我的理解，舉幾個軟體工程師的認知負擔例子（但不同角色例子可能就剛好相反）：

Intrinsic Cognitive Load （內在認知負擔）

比如說瞭解 Code 怎麼寫，Go 的語法 ，該用哪些 Design Pattern，如何透過 TDD refactor ，比較像工程師的本質學能。

 Extraneous Cognitive Load（外在認知負擔）

比如說要怎麼 deploy，deploy 的流程是什麼，要去哪裡下載 Code？ CI / CD 的流程該怎麼設定？k8s 的環境設定要怎麼設？要去哪裡看 debug log ? 某個系統 reboot 致百病的 workaround 方法？

Germane Cognitive Load（有意義的認知負擔）

Service 要怎麼切分？ DDD 怎麼幫助設計？ 開發系統的 Domain knowledge....

那該如何最小化認知負擔呢？就是把稀缺的腦力放在有價值的地方，我們可以透過使用好的 IDE 和 tool 或是教育訓練 / Pair programming 來有效降低 Intrinsic Cognitive Load。

透過 SOP 或是專屬的 Infra Team / DevOps Team 來幫助建置優化開發部署流程，消滅工程師的 Extraneous Cognitive Load（外在認知負擔）

讓工程師更專注在於產生價值的 Germane Cognitive Load（有意義的認知負擔），設計更好的系統來解決客戶的問題帶來價值。

所以當隨著業務量變大以及團隊成長，但是團隊的績效和產出卻開始下滑，並且同仁們開始怨聲載道時，這時候可能不能簡單的認為，應該是人力資源不足加人就好，而是應該是要先從團隊的認知負擔開始檢討。是不是單一團隊承載太多認知負擔了？

切分團隊

團隊的切分也是一門藝術，傳統的思考模式是，某個 domain / project  變大變複雜，那就找多一點人或團隊一起加入幫忙，於是到處開始資源盤點和借人....

 

 

 

此外另一個常見的場景就是，某團隊把某個案子或產品做的有聲有色，於是就會有更多的工作和事情塞給他們，由於績效不錯又幫公司賺錢，所以工作更多的狀態下，老闆也會同意讓他們補更多的人，但是也就越增加他們的認知負擔.....

 

但是這本書告訴我們，應該要先從把大 domain / project 切分成許多 sub domain / sub project 開始，在考慮這些 sub domain 之間的關係，要分別切分給哪些團隊處理。

 

 

 

 

切分完 domain 和團隊完後，也要思考團隊間的協作性，某些團隊之間可能更需要緊密的合作，某些團隊可能只需要維持最小程度的 sync

 

 

這不就像是 Monolithic application 切分成 micro service 的過程一樣嗎？所以這就回扣到康威定律，團隊的切分與組織的溝通模式會決定你的系統架構。

 

團隊間的 API

 

當團隊切分完了就好了嗎？當然不是，如果沒處理好溝通模式，可能反而會造成穀倉效應。那團隊之前的 API 究竟是什麼呢？包含以下產出物：

• Service 間實體的 API 文件
  
• Document （wiki）
• 好的 User experience （讓別的團隊好懂好用）
• Versioning （版本規劃與向下相容）
  
• Best Practice & Principle （如何使用與規範）
• Communication method （透過什麼管道溝通？開票？開會？）
• Work info （ feature roadmap 與 bug fix time ）
  

 

此外最重要的就是把其他團隊當成顧客！要不斷的教育客戶，選傳自己的服務，測試和演化服務。

 

這邊提到 AWS 更極端的例子，每個 Team 的 Service 之間都還會設定 DoS rule 包含（SLA / Quota / API Call Throttling ）

 

更多內容讓我們繼續看下去....

有興趣的也可以先下載這本 mini-book 來看