跨職能小隊加平台團隊，是把產品、設計與工程放在同一個小組，直接負責一條使用者價值的流程；部署、資安防護、數據監控與系統維運這類共用能力，則交給另一個平台團隊提供。小組人少，彼此的溝通路徑就少；共用能力有人專責，小組不必每次從零處理。這篇文章整理這個做法的理論依據，對照傳統分工的差異，並說明 AI 讓團隊縮小這件事目前能說到哪裡，以及哪些情況不適用。
跨職能小隊與平台團隊是什麼？
跨職能小隊是能獨立交付一條價值流的小組；平台團隊則提供共用服務，目的是讓小隊更快交付，而不是取代小隊。
《Team Topologies》把團隊分成幾種類型，其中兩種最常被引用：流程對齊團隊（stream-aligned team）專注於一條業務流程的持續交付；平台團隊（platform team）提供內部服務，加速流程對齊團隊的工作（Team Topologies，Key Concepts）。同一套說法也強調認知負荷：一個團隊能同時掌握的事情有限，所以要把不屬於它核心任務的工作，交給能專責處理的團隊。
用蓋房子比喻：小隊是負責一棟樓從設計到交屋的工班，平台團隊是供電、供水與消防的共用管線，工班不用每次自己拉一條電纜。
為什麼小團隊的溝通成本比較低？
團隊人數增加時，兩兩之間的溝通路徑以平方速度成長；人數少、角色齊全的小隊，需要來回轉達的環節也比較少。
佛瑞德・布魯克斯（Fred Brooks）在《人月神話》提出，任務如果需要成員彼此溝通，增加人手會增加溝通成本，兩兩之間的路徑數是 n(n−1)/2（Martin Fowler，Mythical Man-Month 條目）。
| 團隊人數 | 兩兩溝通路徑數 |
|---|---|
| 5 人 | 10 條 |
| 10 人 | 45 條 |
| 20 人 | 190 條 |
亞馬遜的「兩個披薩團隊」做法也把人數放進設計：AWS 的說明指出，理想的團隊人數少於十人，較小的團隊能減少溝通線，讓成員把心力放在目標上（AWS，Amazon's two-pizza team）。
康威定律提供另一個角度。梅爾文・康威（Melvin Conway）在 1968 年的論文指出，設計系統的組織，其產出的設計會複製組織自己的溝通結構（Melvin Conway，Conway's Law，Datamation，1968 年 4 月）。需求要經過產品、設計、前端、後端、測試好幾道交接才能完成，系統也容易出現同樣的切割與落差。
溝通路徑變少，不代表溝通不重要。小隊需要的是更頻繁、更直接的溝通，而不是更少。
傳統分工與小隊加平台，差在哪裡？
傳統分工依職能切組，需求要跨組傳遞；小隊加平台依價值流切組，共用能力由平台專責，兩者的溝通路徑與責任歸屬不同。
下表是我對兩種做法的比較，用來說明概念，不代表每家公司的實際情況。
| 比較項目 | 傳統職能分組 | 跨職能小隊加平台團隊 |
|---|---|---|
| 分組方式 | 產品、設計、前端、後端、測試各自一組 | 每個小隊都有產品、設計與工程，負責一條價值流 |
| 需求怎麼走 | 依序在各組之間傳遞，每一站轉譯一次 | 同一組內直接討論，用原型確認 |
| 工程師的角色 | 照需求文件實作 | 參與需求討論，並負責技術判斷與品質 |
| 部署、資安、監控 | 各專案自己處理，或等維運組排程 | 由平台團隊提供標準化服務，小隊自助使用 |
| 主要風險 | 交接多、等待多、責任不清 | 各小隊各自為政、平台變成新的瓶頸 |
上表的比較，與本分類另一篇文章討論的現象一致：程式寫得更快，專案仍可能很慢，因為瓶頸在等待與交接，詳見〈程式寫得更快，專案為什麼仍然很慢？〉。
平台團隊要負責什麼？
平台團隊負責自動化部署、資安防護、數據監控與系統維運這類共用能力，讓小隊專心處理使用者問題與業務邏輯。
共用能力的共同特點是：每個小隊都需要，做錯的代價高，而且不會因為產品不同而有太大差異。
| 共用能力 | 平台團隊提供什麼 | 小隊省下什麼 |
|---|---|---|
| 自動化部署 | 標準化的上線流程與環境 | 不用每次手動設定伺服器 |
| 資安防護 | 權限、金鑰管理與基本掃描 | 不用各自摸索資安規範 |
| 數據監控 | 統一的紀錄與警示 | 不用各自搭建查詢工具 |
| 系統維運 | 備援、備份與故障處理流程 | 不用自己值班處理基礎設施 |
在本分類的案例中，有人遇到工具一天做完、上線卻卡了近一個月，原因多半在部署與資安的檢查。如果有平台團隊提供標準流程，這類等待可能縮短。完整經過見〈AI 一天寫完工具，為什麼上線卻卡了近一個月？〉。
AI 會讓團隊縮小嗎？目前能說到哪裡？
AI 可能降低某些職能的進入門檻，但是否因此能把團隊縮小，目前沒有定論，需要看實際流程的瓶頸在哪裡。
支持縮小團隊的論點是：AI 協助非工程背景者做出原型，需求不必先轉譯成文件，交接次數可能減少。本分類有案例顯示，領域專家先做原型，再由工程師整合，確實改變了分工，例如〈社工先做出原型，再交工程師整合〉與〈老闆先用 AI 驗證想法，核心工程師再整合〉。
但這些是個案自述，不能推論成一般規律。另一方面，也有研究提醒，個人寫得更快不等於交付更快，詳細的來源與討論整理在〈程式寫得更快，專案為什麼仍然很慢？〉。
所以本文的立場是：小隊加平台是一種降低交接的組織設計，AI 可能讓它更容易做到，但不是縮編的理由。
什麼情況不適用？
產品很小、沒有共用需求，或團隊缺乏能做技術判斷的人，跨職能小隊加平台的設計可能增加成本，而不是降低成本。
下表是我整理的不適用情況，用來提醒評估，不是公開研究的結論。
| 情況 | 為什麼可能不適用 |
|---|---|
| 公司只有一兩個人 | 不需要分小隊，平台團隊更不需要 |
| 只有單一產品、單一團隊 | 沒有共用能力，平台團隊會變成多餘的角色 |
| 小隊裡沒有人能做技術判斷 | 原型能跑不代表資安、權限與測試已完成 |
| 平台團隊變成審核關卡 | 如果小隊要等平台排程才能上線，反而新增一道瓶頸 |
| 各小隊缺乏共同的產品方向 | 小隊各自做出彼此衝突的功能，產品變成拼裝品 |
平台團隊的目的是加速，如果它變成新的審核窗口，就背離了原本的設計。
常見問題
跨職能小隊就是敏捷開發嗎？
不完全是。敏捷是一組做法與價值觀，強調頻繁交付與商業人員和開發者每天一起工作（Agile Manifesto，Principles）。跨職能小隊是組織設計，常與敏捷搭配，但兩者不是同一件事。
小隊一定要少於十個人嗎？
不一定。AWS 的兩個披薩團隊說明以少於十人為理想，但實際人數應看任務與溝通需求調整。
平台團隊是不是就是維運組？
不一樣。傳統維運組常被當成接收需求的窗口；平台團隊的目標是提供讓小隊自助使用的服務，提升小隊的交付速度。
沒有技術背景的人加入小隊，風險是什麼？
最大的風險是原型能跑，就以為產品已經完成。資安、權限、測試與維運仍要有人負責，詳見〈用 AI 做產品要過哪五關？〉。
AI 時代一定要重組團隊嗎？
沒有證據顯示一定要。先找出現有流程中的等待與交接，再決定調整的範圍，比先縮編更穩妥。
資料來源與說明
團隊類型與認知負荷引自 Team Topologies 官方網站，溝通路徑公式與康威定律引自康威本人與 Martin Fowler 的公開文章，兩個披薩團隊引自 AWS 的公開說明，查閱日期為 2026 年 10 月 19 日。傳統分工與小隊的比較表、平台團隊負責項目的整理以及不適用情況，是我的整理，沒有經過大規模驗證。
參考資料
- Team Topologies，〈Key Concepts〉，現行頁面，存取日期：2026 年 10 月 19 日。
- Martin Fowler，〈Mythical Man-Month〉，現行頁面，存取日期：2026 年 10 月 19 日。
- Melvin Conway，〈Conway's Law〉，原文發表於 Datamation，1968 年 4 月，存取日期：2026 年 10 月 19 日。
- Amazon Web Services，〈Amazon's two-pizza team〉，現行頁面，存取日期：2026 年 10 月 19 日。
- Agile Manifesto，〈Principles behind the Agile Manifesto〉，現行頁面，存取日期：2026 年 10 月 19 日。
延伸閱讀
- Vibe Coding 是什麼？三種定義、適用範圍，與企業及個人案例的閱讀路徑：先釐清定義與適用範圍，再依情況挑選本分類的文章。
- 程式寫得更快，專案為什麼仍然很慢？從等待、交接與審查找瓶頸：為什麼人多與交接多會讓專案變慢。
- 用 AI 做產品要過哪五關？給非工程師的上線前檢查表：小隊裡的非工程師，上線前該檢查什麼。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19