概念地圖・團隊拓撲
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
團隊拓撲：團隊怎麼切，交付才不會卡
《團隊拓撲》（Team Topologies）提出一個很省事的主張：不要每次改組都重新發明組織圖，長期有效的團隊型態其實只有四種，而團隊之間的關係也只有三種。這張圖把四種型態與三種互動畫在同一張結構圖上——中間那排直接對客戶交付、上面兩種提供深度支援、底下那條是讓所有人自助取用的平台。它真正在處理的問題只有一個：讓每個團隊背得動自己那份認知負荷。
四種型態，各自在解一個不同的問題
這套分類的價值在於它很窄——只有四種，逼你替每個團隊做出明確歸類，而歸不進去的那個團隊通常就是組織裡最混亂的地方。
| 團隊型態 | 它負責什麼 | 做對了長這樣 | 常見的走樣 |
|---|---|---|---|
| 流動對齊 | 一段完整的客戶價值 | 不必等別組就能上線 | 每個需求都要跨三組排程 |
| 平台 | 把底層能力包成自助服務 | 別人不必開單就能用 | 變成新的守門人與排隊窗口 |
| 賦能 | 短期進駐、把能力留下 | 幾週後就退場 | 長期常駐，變成代工 |
| 複雜子系統 | 深度很高的專門模組 | 真的需要專才才成立 | 為了保住編制而硬切出來 |
最後一列的警告值得特別記住：複雜子系統團隊是四種裡最容易被濫用的。它的成立門檻應該很高——那塊東西要複雜到「如果不是專才，任何流動對齊團隊都學不會」。演算法核心、影像處理、財務清算引擎算；只是「比較難的那個模組」不算。
切團隊之前，先把四件事問清楚
組織圖怎麼畫都行，難的是讓它真的降低摩擦。四個自問，順序由內而外。
一、這個團隊背得動它負責的範圍嗎。《團隊拓撲》整本書的支點是認知負荷：一個團隊能理解與維護的東西有上限，超過了就會出現「沒人真的懂這一塊」的黑洞。判斷方式跟程式碼行數無關，要看團隊成員能不能講清楚自己負責的每個部分在做什麼。當你發現團隊裡開始出現「那塊只有某某人知道」，而且不只一塊，那就是負荷已經超載。自問：團隊裡任兩個人，能不能互相說明對方負責的那一塊？
二、它能不能自己把東西送到客戶面前。流動對齊團隊的核心定義是「端到端」——從需求到上線，中間不需要等別的團隊排程。實務檢查很直接：翻出最近五次交付，看每一次分別卡在誰身上。如果五次裡有三次都在等同一個外部單位，那條邊界就切錯了，該把那個能力併進來，或把它平台化成自助服務。自問：上一次上線，我們等了幾個團隊？
三、平台是自助的，還是要開單的。平台團隊的成敗只有一個判準：使用者能不能在沒有平台團隊參與的情況下把事情做完。如果每次用平台都要先發訊息、填表單、等排程，那它只是換了名字的共用資源池，而且會成為整條線的瓶頸。好平台的訊號是它像產品——有文件、有預設值、壞掉時使用者自己看得懂訊息。自問：新人不問任何人，能不能靠文件把平台用起來？
四、每一對關係，是不是只挑了一種互動模式。三種互動各有適用時機：協作用在「兩邊都還在摸索、需要一起發現」的階段，代價是溝通成本高；X 即服務用在介面已經清楚的時候，代價低但需要先投資把介面做好；促進用在「一邊要把能力交給另一邊」的時候，本質上是短期的。麻煩幾乎都出在混用或停留——兩個團隊長期協作，通常代表邊界沒切好，該把它推向服務化。自問：這兩個團隊的協作，已經持續幾個月了？
一家生鮮電商，把「前端組、後端組、App 組」重新切了一次
一家做生鮮宅配的公司，技術部門約四十人，原本依技能分成前端組、後端組、App 組、維運組。每個新功能都要四個組同時排到檔期才動得了，平均一個中型需求從提出到上線要五到七週，其中真正在寫程式的時間不到兩週。
- 原本的樣子：依技能分組，每個需求橫跨四組，四份排程要對齊。等待佔了七成的時間
- 切法改動：改成三個流動對齊團隊——訂購、配送、供應商後台，各自含前端、後端與測試。一個需求只在一個團隊裡
- 維運組怎麼辦：轉成平台團隊，把部署、監控、環境開設做成自助工具與文件。半年後開單量降九成
- 冷鏈排程演算法：確認只有兩位專才懂，成立複雜子系統團隊，與配送團隊以協作方式合作三個月。介面談定後轉成服務
- 資安與測試自動化：成立一個兩人賦能團隊，每次進駐一個流動對齊團隊六週再退場。能力留在團隊裡
- 一年後：中型需求從五到七週降到約兩週，跨團隊會議減少一半以上。人數幾乎沒變
這次改組最反直覺的地方，是全公司技術人數幾乎沒有增加，交付速度卻快了兩三倍——省下來的全是等待。第二個值得注意的是維運組轉平台團隊那一段：前三個月大家覺得更慢了，因為平台團隊在做工具，暫時沒空接單，而流動對齊團隊還不熟悉自助流程。這段低谷是常態，也是多數組織半途放棄的地方；撐過去之後，開單量才會真的掉下來。至於冷鏈演算法那一塊，值得注意的是它從協作走向服務化用了三個月——協作本來就該是階段性的，長期停在協作，那條邊界遲早要重畫。以上為說明結構用的示意情境，數字僅供比例參考。
這套模型，有三個地方會被誤用
《團隊拓撲》最常見的誤用，是拿它當重組的正當性來源，忘了它本來是一支診斷工具。
- 換了名字，沒換溝通路徑，等於沒改。康威定律說系統架構會長成組織溝通結構的樣子，反過來也成立：你改了組織圖，但每天還是同一群人在同一個群組裡討論同樣的事，那系統不會改變。真正的改動一定伴隨著「誰不再需要跟誰對話」——如果重組之後沒有任何一對關係被切斷，那多半只是換了名牌。
- 平台團隊很容易長成新的官僚。這是實務上最高頻的失敗模式：平台團隊為了品質與一致性，開始要求所有人走它的流程、填它的表單、等它的審核。從平台團隊的角度看每一條規定都合理，但整體效果是把原本分散的等待重新集中成一條隊伍。防線只有一條——用「使用者不需要我們也能完成」當唯一的成功指標，而不是用「大家都照規範走」。
- 它是為軟體組織寫的，搬到別的場域要翻譯。四種型態的原始語境是軟體開發與維運。搬到行銷、業務、內部服務單位時，概念大多成立（流動對齊＝對一段客戶旅程負責、平台＝共用素材與工具、賦能＝內部教練），但細節要重新想，尤其是「端到端交付」在非軟體場域的定義。硬套詞彙而不重新定義交付單位，通常會得到一套很時髦但沒人知道怎麼用的組織圖。
用痛點的眼光，再看一次那條中間排
一個團隊能不能自己把東西交出去，決定了它離客戶的痛有多遠。
依技能分組的組織有一個很隱蔽的副作用：沒有任何一個團隊真正擁有客戶。前端組交出畫面、後端組交出介面、維運組把它推上線，每個人都完成了自己的部分，而「客戶到底有沒有變得比較不痛」不在任何人的績效裡。當交付被切成好幾段，責任也會跟著被切成好幾段，最後沒有人需要為結果負責。P.A.I.N. 那把尺的第一格問「誰在痛」，這個問題在組織內部同樣要問一次：你的團隊說得出自己在替誰解決什麼痛嗎？答不出來，多半跟努力無關，而是那條邊界把他們跟客戶隔開了。這也給了一個很土但有效的檢查：問團隊裡的每個人「我們上一次讓客戶少痛一點，是哪一件事」——如果得到的答案是專案名稱而不是客戶的處境，這條邊界就值得重畫。今晚可以做的一件小事：把最近三次交付卡住的地方列出來，看它們是不是都卡在同一條交界線上。
關於團隊拓撲，常被問到的幾件事
團隊拓撲跟一般的組織架構圖差在哪？
傳統組織圖畫的是彙報關係——誰向誰報告。團隊拓撲畫的是交付與互動關係——誰替誰做事、用哪一種方式。兩者可以並存，因為它們回答不同問題。實務上的價值在於：彙報線的改動政治成本很高、也很慢，但互動模式的改動可以馬上開始（例如把某一對長期協作改成明確的服務介面），而且往往就足以解決大部分的卡頓。所以與其一開始就重畫組織圖，通常先把互動模式盤一遍效益更高。
團隊要多大？
書裡沿用鄧巴數的概念，建議單一團隊以五到九人為主，最多不超過十五人，理由是超過這個規模就無法維持共同的認知。更實用的判準是認知負荷：這個團隊負責的範圍，成員能不能都講得清楚？如果只有一兩個人懂全貌，那不論人數多少都已經超載。這也連到另一條經驗——團隊該分裂的訊號通常是「開會時有一半的人跟這個議題無關」。
小公司只有十幾個人，用得上嗎？
用得上，但方式不同。十幾個人通常就是一到兩個流動對齊團隊，不需要平台團隊與複雜子系統團隊——那些能力用外部服務買。真正有價值的是那個提問本身：我們這個團隊，能不能不靠任何人就把東西送到客戶手上？小公司的答案常常是「不能，因為卡在老闆」，那就是一條要處理的邊界。等到規模到三、四十人，平台的需求才會自然浮現，那時再切。
賦能團隊跟顧問、內部教練有什麼不同？
最大的差別是退場條件。賦能團隊的成功定義是「它離開之後，那個團隊自己做得到」，所以它一開始就要講好進駐多久、留下什麼。顧問與代工模式則是持續提供服務，離開之後能力也跟著走。這個差別在實務上很容易失守——賦能團隊被拉去救火，救著救著就常駐了。防止的方法是每次進駐都明訂週期與交付的能力清單，並且在退場後追蹤那個團隊有沒有真的接手。
怎麼判斷要不要成立平台團隊？
看重複。當三個以上的流動對齊團隊都在做同一件底層工作（各自架環境、各自寫部署腳本、各自接同一個金流），那就是平台的訊號。反過來，只有一兩個團隊需要的東西不值得平台化，因為維護一個平台本身有成本，使用者太少會划不來。另一個判準是介面能不能穩定：如果那塊東西每個團隊的需求都長得不一樣、很難標準化，硬做成平台會變成一個沒人滿意的最大公約數。
想理解這套模型底下那個支點，認知負荷那張圖把「一個團隊背得動多少」拆得更細；如果你要比較的是傳統的功能式、事業部式等切法，組織結構三型提供對照。想看一家公司的交付流程如何從全面塞車走到順暢，《鳳凰專案》的拆書是最有畫面的延伸。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。