[現代的]組織設計……談的是為協作式技術而設計，為顧客的聲音而設計。
——娜歐米・史丹佛（Naomi Stanford），《Guide to Organization Design》
團隊永遠是未完成品#
團隊永遠處於「進行中」的狀態，但它同時也是你持續且可持久地交付價值的最佳賭注——只要讓它與業務對齊。
理想上，團隊應該長期存續、具備自主性，成員投入其中。然而團隊並不孤立存在：
- 它們需要理解該在何時、以何種方式彼此互動
- 這些互動必須隨時間演化，以支撐產品與技術在生命週期中所經歷的探索期與執行期
換言之，組織不僅要追求自主團隊，也必須持續思考並演化自身，才能快速把價值交付給顧客。本書提供的，正是一套我們在不同成熟度的企業中實際使用並見證有效的組織設計模型：團隊拓撲（Team Topologies）。
團隊拓撲不是建造與營運軟體系統的萬用公式。確實有一些團隊與組織，是以與本書所描述、所建議者相當不同的組織動態獲致成功的——特別是那些文化與最佳實踐早已到位的組織。
團隊拓撲意在提供清晰、讓各種團隊與組織都易於依循和詮釋的樣式，而不是去指揮頂尖高手該怎麼表演。
不妨把團隊拓撲想成管弦樂團或大樂團的分部譜，而非爵士小號名家的旋律線。給大型合奏團的樂譜幫助整個團體成功，卻不會規定演出的每個細節；大量的詮釋空間留給樂手，讓他們因場合、場地或成員組合而調整。同樣地，跨團隊之間就一套連貫的共同語彙與協作方式達成共識，本身就有巨大價值。
這本書寫給誰#
團隊拓撲能幫助兩類組織：正苦於找不到方法最佳化團隊結構的組織，以及尚未意識到團隊設計會對商業成果、特別是軟體系統造成何等影響的組織。
任何在意軟體系統交付與維運成效的人都適合閱讀本書：C 級主管（CTO/CIO、CEO、CFO 等）、經理人、部門主管、軟體架構師與系統架構師，以及任何參與建造或營運軟體系統、希望或需要提升其成效的人。
這本書如何誕生#
本書的源起脈絡
2013 年，史凱爾頓（Matthew Skelton）在英國一家公司導入 DevOps 與持續交付（Continuous Delivery）時，於部落格文章〈What Team Structure Is Right for DevOps to Flourish?〉中提出了最初的 DevOps 拓撲樣式與反樣式。當時那家客戶公司正難以採用現代軟體交付方法，而這些早期的拓撲樣式提供了一種探索不同選項的方式。
2015 年，派斯（Manuel Pais）在倫敦 QCon 軟體開發研討會上訪問了正在講述康威定律與早期 DevOps 拓撲樣式的史凱爾頓。訪談文章〈How Different Team Topologies Influence DevOps Culture〉由 InfoQ 刊出並被翻譯成多國語言。同年稍晚，派斯協助擴充了 DevOps 拓撲樣式，社群也貢獻了內容。
此後 DevOps 拓撲樣式的使用量爆發性成長，在演講、文章與各種討論中被反覆引用，幫助世界各地不同規模、不同產業的組織思考團隊之間的關係，以及這些互動如何同時影響組織文化與軟體架構。
隨著時間推移，兩位作者意識到：最初的 DevOps 拓撲呈現的是團隊相互關係的靜態視角——對初步討論有用，但範疇相當受限。透過在世界各地培訓與顧問工作累積的經驗，他們發現有些團隊在相對隔離、自主的狀態下運作得更好，另一些團隊則在強力協作下表現更佳。追問「為什麼」，並依客戶回饋不斷演化想法，最終形成了本書所呈現的團隊拓撲：一套動態且持續演化的組織設計取徑，奠基於跨地域、跨產業的真實情境。
如何使用本書#
團隊拓撲意在成為一本功能性的書。作者希望內容具互動性，並在有限篇幅內帶來盡可能多的學習。
三個部分的結構#
- 第一部探討康威定律、組織的相互關係如何限制我們所建系統的設計，以及我們如何把這股傾向轉為己用。接著界定「團隊」的定義，並檢視影響有效團隊協作的若干實務限制。
- 第二部檢視業界已被驗證的一組靜態團隊樣式，以及在康威定律與組織脈絡之下，選擇某一樣式而非另一樣式的意涵。這部分也提供了「如何將團隊對齊到系統各區塊」的指引。
- 第三部處理如何演化組織設計，以在快速變動的營運環境中，獲得驅動創新與快速交付的強大能力。作者說明如何用團隊拓撲取徑打造一個能感知的組織（sensing organization），回應市場與使用者需求，並說明這對招募與技能的影響。
每一部的開頭都會列出各章的關鍵重點；章節內則穿插圖表與提示框，並提供易於辨識的情境、案例研究與針對不同狀況的明確建議。書中多數圖表使用的形狀、顏色與樣式，在全書大部分篇幅中維持一致的意涵，圖例如下：
圖 0.1：四種團隊類型與三種互動模式
依你的處境選擇路徑#
要獲得最完整的理解，應當從頭到尾讀完本書，因為主題是逐章堆疊而上的。不過各節寫得相當獨立，也可依當下處境挑選路徑。
| 你的處境 | 建議閱讀順序 |
|---|---|
| 想釐清不同團隊類型、哪些類型有效 | 第 1 章（總覽）→ 第 4 章（靜態拓撲）→ 第 5 章（基本拓撲） |
| 需要拆解龐大的單體軟體系統 | 第 6 章（邊界）→ 第 3 章（團隊） |
| 想改善軟體系統的架構 | 第 2 章（康威定律）→ 第 4 章（靜態拓撲）→ 第 6 章（邊界） |
| 想提升軟體開發團隊的成效 | 第 3 章（團隊）→ 第 6 章（邊界）→ 第 5 章（基本拓撲） |
| 想改善團隊士氣與效能 | 第 3 章（團隊）→ 第 5 章（基本拓撲） |
| 想知道面對成長該把力氣投在哪 | 第 1 章（總覽）→ 第 5 章（基本拓撲）→ 第 8 章（拓撲演化） |
| 想理解如何演化拓撲以因應業務變化 | 第 7 章（動態面向）→ 第 8 章（拓撲演化與組織感知） |
形塑本書的關鍵影響#
四條思想脈絡
除了作者自身經驗，本書深受幾套相關取徑與思路影響。
一、組織是社會技術系統（sociotechnical system）或生態系，由其中個人與團隊的互動所形塑；換句話說，組織就是人與技術之間的互動。在這一點上，本書呼應以下領域的想法：
- 控制論（cybernetics）——尤其是把組織當作「感知機制」來使用，這個想法可回溯至 1948 年維納（Norbert Wiener）出版的《Cybernetics: Or Control and Communication in the Animal and the Machine》
- 系統思考（systems thinking）——特別是戴明（W. Edwards Deming）的研究
- Cynefin 框架——由斯諾登（Dave Snowden）與布恩（Mary Boone）於 2007 年《哈佛商業評論》論文〈A Leader’s Framework for Decision Making〉提出，用於評估領域複雜度
- 調適性結構化理論（adaptive structuration theory）——由德桑克提斯（Gerardine DeSanctis）與普爾（Marshall Scott Poole）在《Organization Science》文章中提出，強調技術的影響並非既定，取決於群體與組織如何感知它
二、「團隊」的行為不同於一群個人的加總，團隊應在其演化與運作中被滋養與支持。這方面借鑑：
- 塔克曼（Bruce Tuckman）1965 年論文〈Developmental Sequence in Small Groups〉提出的團隊發展四階段模型（形成、風暴、規範、表現）
- 佛瑞斯特（Russ Forrester）與德雷克斯勒（Allan Drexler）1999 年論文〈A Model for Team-Based Organization Performance〉
- 奈特（Pamela Knight）2007 年論文〈Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model〉，提出風暴期貫穿團隊整個生命週期的證據
- 藍奇歐尼（Patrick Lencioni）《克服團隊領導的 5 大障礙》（The Five Dysfunctions of a Team）中對常見互動問題的探討
三、康威定律（或其變體）是軟體產品形態的強力驅動因子，組織若能明確處理這條定律的意涵將大有助益。這方面借鑑康威（Mel Conway）本人、軟體架構顧問暨團隊組織設計獲獎者馬蘭（Ruth Malan），以及 ThoughtWorks 技術總監、「反向康威操作」提倡者之一路易斯（James Lewis）等人的著述。
四、大規模開發與營運軟體系統的實務成功案例，來源包括 Adidas、Auto Trader、Ericsson、Netflix、Spotify、TransUnion 等組織。這些組織的規模與速度，讓它們得以在數月至數年內，從組織結構與團隊互動的改變中看見具體收益。
在閱讀本書的旅程中，作者期待你受到啟發，去挑戰自己對團隊、團隊結構，以及團隊如何運作的既有想法。