系統愈做愈大之後，很多技術問題表面上看起來像架構問題，底下其實藏著組織問題。
一個功能要改動，前端要等後端、後端要等資料庫團隊、部署還要排 DevOps；每個團隊都很忙，交付速度卻愈來愈慢。大家開始增加會議、群組與跨部門同步，結果溝通更多，系統反而更糾纏。
《Team Topologies》處理的，就是這種情況：團隊怎麼分、怎麼互動，會直接影響系統最後長成什麼樣子。
Conway’s Law：系統會長得像組織的溝通方式
Mel Conway 在 1968 年提出一個後來被稱為 Conway’s Law（康威定律）的觀察：設計系統的組織，最後往往會產生和自身溝通結構相似的系統。
如果前端、後端、資料庫、基礎設施被切成四個獨立團隊，一個新功能自然就會跨越四個邊界；久了之後，系統裡也容易形成大量跨層依賴與交接。
相反地，如果一個團隊能從使用者需求一路負責到部署與維運，系統比較有機會沿著完整業務流程形成清楚邊界。
組織圖只是表面，Communication Path 才會影響系統
公司正式組織圖可能寫得很漂亮，但實際影響架構的，是每天真正發生的溝通路徑。
誰必須找誰 Code Review？誰能自己部署？哪個改動需要先開跨部門會議？哪些團隊每天都在同一個群組裡互相等？
如果兩個名義上獨立的團隊，每個需求都得一起討論、一起改、一起上線，它們在實際運作上就沒有形成清楚邊界。
Team Topologies 的預設主角是 Stream-Aligned Team
Team Topologies 定義四種基本 Team Type，其中最核心的是 Stream-Aligned Team（價值流對齊團隊）。
這種團隊直接對齊一條可持續的業務或使用者價值流，能從需求一路負責到交付與營運。
例如：
- 會員註冊與登入。
- 課程購買與付款。
- 學員學習體驗。
- 講師內容發布。
重點是大多數日常變更能在團隊內完成，不必每次都排跨團隊工單。
Platform Team：平台的工作是減少別人的負擔
Platform Team（平台團隊）不是把所有基礎設施集中起來，讓其他團隊排隊等服務。
它更像一個內部產品團隊：提供開發、部署、監控、權限、資料或其他共用能力，讓 Stream-Aligned Team 能更快完成工作。
判斷平台有沒有價值，一個很實用的問題是：它到底替使用平台的團隊減少了多少 Cognitive Load（認知負荷）？
如果使用內部平台比自己處理還麻煩，文件不完整、每次都要開單、還得等人批准，那就只是另一個瓶頸。
Enabling Team：把能力教會之後，就應該離開
Enabling Team（能力支援團隊）是暫時協助其他團隊建立新能力。
例如公司剛開始做 Observability、Automated Testing、Security，可能由一組專家先和各團隊合作，幫助建立方法與實務。
它的成功要看受協助團隊之後能不能自己做，而不是收到多少工單。
如果同一批專家永遠都要替其他團隊操作，Enabling Team 就會慢慢變成永久依賴。
Complicated-Subsystem Team：只留給需要深度專業的子系統
有些子系統需要非常專門的知識，例如機器學習模型、編解碼器、複雜風險模型或特殊演算法。
這時可以建立 Complicated-Subsystem Team（複雜子系統團隊），把高度專業的複雜度包在清楚介面後面，避免每個 Stream-Aligned Team 都必須理解。
但這不應成為「這個元件看起來很重要，所以成立一個專門團隊」的理由。判斷標準還是：這一塊是否需要深度專業，而且獨立出來能降低其他團隊的認知負荷。
四種 Team Type 不是四個固定部門
這套方法很容易被誤用成新的組織圖模板。
這套分類不是要求公司一定要有四種部門，而是讓每一個團隊都有清楚角色；另外三種 Team Type 的存在，都應該有助於 Stream-Aligned Team 更快交付。
如果一家公司成立很多 Platform、Enabling、Subsystem Team，卻只有少數直接面向價值流的團隊，通常代表輔助結構開始膨脹。
三種 Interaction Mode，比「大家多溝通」更有用
| 互動模式 | 適合情境 |
|---|---|
| Collaboration | 兩個團隊暫時密切合作，共同探索未知問題 |
| X-as-a-Service | 一方透過清楚介面使用另一方提供的能力 |
| Facilitating | 一個團隊協助另一個團隊學會新能力 |
問題通常不在跨團隊互動本身，而在互動模式沒有說清楚。
一個團隊以為對方提供的是穩定 Service，對方卻期待一起共同設計；另一邊以為 Enabling Team 只是短期協助，結果半年後所有事情還是丟給它。
Collaboration 很有價值，但成本也最高
當兩個團隊一起探索新邊界或新能力時，Collaboration 很有效。
例如新的 Payment Platform 還不知道介面應該長什麼樣，平台團隊可以先和一個 Stream-Aligned Team 密切合作。
等介面與需求成熟後，再轉成 X-as-a-Service，讓其他團隊能自行使用。
如果 Collaboration 永遠不結束，代表邊界很可能還沒有穩定形成。
Cognitive Load：團隊負責得太多，增加人數通常也救不了
Team Topologies 很重視 Team Cognitive Load（團隊認知負荷）。
一個團隊可能同時要理解業務規則、應用程式、資料庫、雲端部署、監控、安全，以及數個不同產品領域。
當責任超過團隊能掌握的範圍，常見結果就是 Context Switching、Ownership 變淺、交付時間拉長，以及大家只敢碰自己熟悉的一小塊。
這時候不一定要再加更多人，更常見的解法是減少團隊要負責的 Domain，或透過 Platform 把非核心複雜度拿掉。
Long-lived Team：不要每個專案開始就重新拆隊
Team Topologies 偏向長壽命團隊，而不是專案一開始就從各部門抽人組隊，專案結束再解散。
一個團隊要建立信任、共同語言、技術默契與對 Domain 的理解，需要時間。每次重新拆隊，都會把這些已累積的能力一起打掉。
比較理想的思路是 flow work to teams：保留已經磨合好的團隊，再把新的價值流與工作送進團隊，而不是每個專案都把人重新排列一次。
這也能讓 Ownership 更穩定。團隊不只負責做完專案，也要持續面對自己做出的系統、On-call、錯誤與後續演進。
Team-sized Software：軟體也要縮到團隊真的掌握得住
如果一個系統的範圍遠超過單一團隊能理解、測試、部署與維護的能力，問題不一定出在人太少，也可能是軟體邊界本身太大。
Team Topologies 的思路是讓 Software Boundary 和 Team Cognitive Capacity 對齊。團隊不應只「分到一部分工作」，而應能對自己負責的系統片段建立深入理解與完整 Ownership。
當軟體範圍大到必須靠多個團隊長期共同擁有，通常就需要重新找 Fracture Plane，把責任切成更清楚、能由單一團隊持續演進的邊界。
軟體邊界也要符合一個團隊能完整負責的大小
如果某個系統大到沒有任何一個團隊能完整理解與維護，它的邊界就值得重新檢查。
Team Topologies 會尋找 Fracture Planes（斷裂面），也就是可以自然拆分的邊界。
最常見的切法是 Business Domain，但也可能依據法規與合規範圍、不同變更頻率、風險、效能需求、使用者族群或技術限制。
如果你的問題已經進入程式架構層，可以延伸看Clean Architecture：為什麼商業邏輯不該被框架與資料庫綁死。
按技術層切團隊，往往會製造大量 Handoff
「前端一隊、後端一隊、DBA 一隊、DevOps 一隊」看起來專業分工清楚，但每個完整功能都可能跨過所有團隊。
這會造成排隊、需求轉譯、優先級衝突與等待時間。
Team Topologies 更偏向把大多數團隊對齊完整價值流，讓一次變更盡量留在一個團隊裡。
如果系統已經出現大量耦合與交接，也可以再看系統愈做愈慢、愈改愈亂？架構最佳化應該先從哪裡開始。
Inverse Conway Maneuver：先決定想要的架構，再設計團隊邊界
既然 Conway’s Law 會讓組織溝通映射到系統，那麼就可以反過來利用它。
Inverse Conway Maneuver（逆康威操作）的思路是：先想清楚希望系統形成哪些獨立邊界，再讓團隊責任與溝通路徑對齊那些邊界。
例如希望 Payments 成為可以獨立演進、獨立部署的服務，就不能同時讓三個不同團隊共同擁有它。
如果架構圖說「服務獨立」，但每次修改還是需要三個團隊一起開會，最後主導結果的通常會是組織結構，而不是架構圖。
Platform as a Product：內部開發者也是客戶
平台團隊如果只把自己當基礎設施管理者，很容易累積大量功能，卻沒有解決其他團隊的痛點。
Team Topologies 強調把 Platform 當產品經營：理解內部使用者需求、讓常見能力 Self-Service、提供清楚文件與 Team API、追蹤採用率與 Developer Experience，並只建確實能減少負荷的能力。
平台不是越大越好。最小可行平台甚至可能先從文件、標準與現有服務整理開始，而不是立即開發一整套新平台。
Team API 不只是一支技術 API
Team API 是「其他團隊要怎麼和我們合作」的清楚介面。
它可能包含團隊負責哪些 Domain、哪些 Repo 與 Service 歸誰、文件在哪裡、遇到問題找哪個 Channel、On-call 與支援方式，以及哪些事情能自行處理。
如果每次跨團隊合作都要先問「這件事到底找誰」，表示組織介面還不夠清楚。
不要把 Reorg 當一次性專案
Team Topologies 的團隊配置是動態的。
產品、技術與市場改變後，原本合理的邊界可能不再合理。這時可以從幾個訊號判斷：
- 跨團隊等待時間愈來愈長。
- 同一批團隊每天都要密切協調。
- 某個團隊 On-call 壓力持續升高。
- 平台出現大量繞路與 Shadow Platform。
- 一個團隊同時負責太多不同 Domain。
這些都可能表示 Team Topology 需要調整。
等待時間與摩擦，本身就是組織感測器
很多組織只量 Deployment、Lead Time 或事故數，卻很少量「等另一個團隊」花了多久。
如果某類工作每次都卡在同一個跨團隊依賴，或平台使用者大量建立自己的 Shadow Solution，這些現象本身就是很有價值的拓樸訊號，不宜只當成人際合作問題。
Team Topologies 更重視回頭檢查結構，而不是要求大家一再增加協調：這個邊界還合理嗎？互動模式是不是選錯？這個能力應該搬到 Platform，還是應該回到 Stream-Aligned Team？
小公司也能用 Team Topologies，但不用硬湊四種團隊
如果公司只有五到十個人，沒有必要成立 Platform Team、Enabling Team 等完整組織。
更實際的做法是先借用幾個原則：
- 誰完整負責哪一條價值流？
- 哪些共用能力真的降低大家負擔？
- 哪些工作一直需要跨人等待？
- 每個人同時背了多少不同 Domain？
- 合作是短期探索，還是應該建立清楚服務介面？
Team Topologies 的價值在於降低耦合，不在於把組織名字改得更專業。
一張表判斷組織邊界是不是已經開始拖慢系統
| 症狀 | 可能問題 |
|---|---|
| 一個功能常要三、四個團隊才能完成 | 團隊按技術層切得太細 |
| 平台團隊變成工單中心 | Self-Service 不完整 |
| 兩個團隊長期每天一起工作 | 邊界或 Interaction Mode 可能不合理 |
| 某團隊什麼都要懂 | Cognitive Load 過高 |
| Enabling Team 永遠不能退出 | 能力沒有成功轉移 |
| 三個團隊共同擁有同一服務 | Ownership 不清楚 |
常見問題
Team Topologies 是給工程團隊用的嗎？
它主要從軟體與技術組織出發，但核心原則也適合處理跨團隊交接、責任邊界與認知負荷。非技術團隊使用時，不需要硬套軟體術語。
四種 Team Type 一定都要有嗎？
不用。Stream-Aligned Team 是核心，其他三種只有在能降低價值流團隊負荷時才有存在理由，小公司可能完全不需要某些類型。
Platform Team 更強調 Self-Service 與產品思維，目標是降低其他團隊認知負荷；Shared Service 如果主要靠排隊處理工單，很容易成為瓶頸。
Collaboration 是不是越多越好？
不是。Collaboration 適合探索未知問題，但成本高。邊界成熟後，應盡量轉成清楚的 Service Interaction，降低持續協調。
團隊負荷太高，增加人數有用嗎？
有時有用，但如果根本問題是 Domain 太多、依賴太多或平台能力不足，只增加人數不一定能降低認知負荷。
多久需要重新檢查一次 Team Topology？
沒有固定週期。當跨團隊等待、On-call 壓力、重複協調或平台繞路明顯增加時，就值得重新檢查團隊邊界與互動模式。
Team Topologies 的重點，是讓組織邊界幫助系統演進
一個系統最後長成什麼樣子，往往不只由架構師決定，也受到團隊責任、溝通路徑與所有權深刻影響。
Team Topologies 提供的是一套持續調整的方法，而不是固定組織圖：讓多數團隊對齊價值流，用 Platform、Enabling 與 Complicated-Subsystem Team 移除不必要負荷，再用明確 Interaction Mode 限制跨團隊協調成本。
當團隊邊界、軟體邊界與責任邊界開始一致，很多原本靠會議和工單解決的問題，才有機會從結構上消失。
參考資料
Matthew Skelton、Manuel Pais：Team Topologies: Organizing Business and Technology Teams for Fast Flow。
Melvin E. Conway：How Do Committees Invent?，1968。