如何擴展工程團隊（且不讓一切崩潰）

每個成長到大約十五人以上的工程團隊都經歷過同樣令人不適的過渡期。在五個人的時候，團隊速度快、步調一致且富有成效。到了十五人，事情明顯變慢。到了三十人，人們花在協調上的時間比在開發上的時間還多，而對每個問題的反應似乎都是「我們需要再開個會」。

此時的本能反應通常是歸咎於文化、溝通技巧或個人表現。但實際的原因是結構性的：讓小團隊行之有效的機制無法擴展，如果沒有對新機制進行刻意的投入，每增加一名新員工，都會讓現有團隊的效率遞減。這就是正在實時上演的布魯克斯法則 (Brooks' Law)，且自 1975 年以來就已被記錄在案。

好消息是，這些轉折點是可預測的，而且在每個階段防止崩潰的投入也已被充分理解。

階段 1：5 到 15 名工程師

在五名工程師的規模下，團隊透過共享背景資訊來運作。每個人都在現場參與了每個重要的決策。每個人都了解整個系統。溝通是自然發生的，透過近距離和日常對話進行。文檔是不必要的，因為團隊本身就是文檔。

第一道裂痕出現在十到十五名工程師之間。新員工沒有參與早期的決策，也不具備創始工程師默默承載的背景資訊。系統的發展超出了任何單一工程師所能完全理解的範圍。以前只要轉身問旁邊的人就能解決的問題，現在需要搞清楚該去問誰。

在此階段應投入：

書面的架構決策。 每項重大的技術選擇都應該記錄下來，包括推理過程、考慮過的替代方案，以及推動該決策的限制條件。現在這樣做的成本很低，而以後重新構建的代價極其高昂。架構決策記錄 (ADR) 只需要花十五分鐘編寫，就能為後續省下數小時重複爭論決策的時間。

入職培訓文檔。 在了解這些事情的人還在身邊可以撰寫的時候，寫下系統概述、入門指南和團隊規範文檔。緩慢入職的成本隨招聘速度呈線性增長，而招聘速度即將加快。

可搜尋的知識系統。 儘早決定工程知識將存放在何處。Slack 討論串和口頭解釋無法持久保留。一個能根據您現有活動自動生成的 Wiki 是最理想的，因為它能在不要求任何人做額外工作的情況下捕捉知識。

階段 2：15 到 30 名工程師

這是大多數規模擴充痛點集中的地方。團隊規模已經大到部族知識不再自然流傳，但又小到缺乏正式知識系統的痛苦尚未迫使任何人去建立它們。其結果就是一個痛苦的中間地帶，事情會從六個月前還不存在的漏洞中溜走。

徵兆：

入職培訓需要幾個月而不是幾週，因為沒有完整系統的內容供新員工閱讀。會議倍增，因為背景資訊的傳遞必須同步進行。資深工程師不斷被打斷，因為他們是某些知識的唯一來源。相同的決策會被多次討論，因為最初的推理過程沒有被記錄下來。

在此階段應投入：

團隊邊界與所有權。 拆分為具有明確系統所有權的子團隊。亞馬遜的「兩個披薩團隊」模型行之有效，但前提是團隊之間的知識層要足夠強大，以至於 A 團隊不需要為了獲取 B 團隊系統的背景資訊而打斷 B 團隊。

非同步優先的溝通規範。 預設使用書面的、可搜尋的溝通方式來分享背景資訊和進行日常決策。將同步時間保留給創造性工作、衝突解決和高風險決策。分佈式團隊最迫切需要這一點，但集中辦公的團隊也能從中受益。

自動生成的文檔。 在這個階段，工程活動的數量（PR、Slack 討論、會議、設計決策）超出了任何人手動記錄的能力範圍。能從 GitHub、Slack 和會議中自動生成並維護自身的自動化文檔，是唯一能跟上交付速度的擴充方案。

階段 3：30 到 50+ 名工程師

在這種規模下，工程組織本身就是一個獨立的組織，擁有子團隊、經理、跨功能依賴關係，而且人數多到許多工程師從未直接交談過。

此階段的徵兆有所不同：

團隊之間的知識孤島成為交付速度的主要限制因素。跨團隊專案需要大量的協調會議。機構知識集中在少數資深工程師身上，他們的離職將帶來嚴重的破壞。新員工適應期太長，以至於團隊的實際戰力比員工總數所顯示的要小。

在此階段應投入：

統一的知識層。 所有工程知識、架構文檔、決策記錄、系統文檔、入職指南、團隊 Wiki，都應該可以從同一個地方搜尋。如果 A 團隊的工程師需要了解 B 團隊的系統，他們應該能夠直接搜尋，而不是安排一場會議。

知識留存系統。 在 50 人以上的工程師規模下，人員流動是常態。每次離職都會帶走背景資訊。從日常工程活動中持續捕捉知識，意味著無論人員如何更迭，文檔都能保留下來。巴士因子風險降低，因為知識存在於系統中，而不是在個人的腦袋裡。

AI 準備就緒的文檔。 在此規模下，您幾乎肯定會在整個工程工作流程中使用 AI 工具。這些工具的效果取決於它們能存取的已記錄背景資訊。一個全面、最新且可搜尋的知識庫能讓您工具鏈中的每個 AI 工具發揮更大功效。

反直覺的真相

規模擴展得最好的團隊，並不是招聘速度最快或擁有最多資深工程師的團隊。而是那些在需要之前就投入知識基礎建設的團隊，特別是那些能讓知識在不需要人工中介的情況下即可獲取的團隊。

2026 年的研究支持了這一點：遵循結構化擴展方法的公司降低了 42% 的擴展成本，同時將達到生產力的時間縮短了 37%（德勤科技趨勢）。最關鍵的結構是知識結構，因為它決定了新員工能多快投入生產、團隊協調的效率，以及能為資深工程師保留多少免受打擾的時間。

進行這些投入的最佳時機是在團隊開始成長之前。第二好的時機就是現在，在下一個轉折點到來之前。

常見問題

首先最應該投入的一件事是什麼？ 架構決策記錄和系統概述文檔。這些只需要花幾個小時來建立，但透過防止重複爭論決策並縮短入職時間，能在後續省下數百個小時。其他所有事情（自動生成文檔、正式的團隊邊界、非同步規範）都建立在這個基礎之上。

我們如何在不減緩交付速度的情況下進行這些投入？ 這是最核心的衝突，也是為什麼自動生成文檔如此重要的原因。從已經發生的工程活動中自動生成的文檔，不需要工程師停止開發去撰寫文檔。知識是作為工作的副產品被捕捉下來的，而不是在工作之外增加的額外任務。

團隊達到什麼規模時我們應該開始擔心這個問題？ 儘早投入（5-15 人）時成本最低且最有效。痛苦通常在 15-30 人時變得劇烈。到了 50 人以上，事後補救的投入既昂貴又具破壞性。如果您正在閱讀本文，且您的團隊人數在 15 人以下，那麼您正處於理想的窗口期。

相關閱讀：知識擴展問題、布魯克斯法則依然適用、為什麼您的團隊變得越來越慢、工程入職培訓的真實成本。相關頁面：自動生成文檔、適用於工程團隊、知識留存。