品質天花板：100+ 開發者規模下軟體品質的真正意涵

過去的「軟體品質」等於「程式碼能不能跑」。這個定義會在一個產品團隊從 50 人走到 100 人的過程中悄悄死去。遠在任何團隊負責人察覺之前，程式碼在生產環境是對的，而系統在組織架構中已經碎了——你週二發佈的更動完全跑得通，卻在週一打破了三個團隊之外的某個契約。缺陷並不在程式碼裡。缺陷在接縫上。在 100+ 開發者這個規模上，軟體品質不再是程式碼的屬性，而是接縫的屬性。

本文是一次再框定（reframe），寫給負責「單一應用、100+ 開發者」的工程總監、工程 VP 和工程經理。它建立在三個框上——Conway 定律（1968）、Team Topologies 的認知負載鏡頭（Skelton & Pais, 2025）、DORA 的四個交付指標——並以一份管理者手冊作結：要度量什麼、要改變什麼、要停止度量什麼，以及那個把「真正在改善品質的組織」和「只付錢買品質樣子的組織」分開的那一個問題。

如果你在 30 人的團隊上，本文是天氣預報，不是診斷書。下方四種失敗模式會在 30–50 人的規模上開始顯現，到 100+ 才會急性發作。先讀再框定，做筆記，等接縫開始吱嘎作響時再動手。

品質是系統的屬性

多數工程組織在思考軟體品質時，會穿過三層同心圓；多數工程 leader 在處理 100+ 這個規模轉型時，能夠做對的關鍵，是能在每一個拐點指出哪一層是瓶頸。三層不是同一回事；瓶頸不是同一個；歸屬者不是同一個。

這張圖從內向外讀。每一個內圈都是外圈能正常運作的前提。程式碼品質是系統品質的前提。系統品質是組織品質的前提。本文的核心主張是：系統品質，是在 50 到 200 名開發者同時開發一個產品的規模上，會斷掉的那一層屬性。讀者所管理的應用一旦超過這個閾值，你之所以點開這篇文章，是因為系統讓你失望，而不是程式碼讓你失望——而下方四種失敗模式，是失望的具體形狀。

把這件事做錯的代價是真實的。Consortium for IT Software Quality 在他們最近的估算中，把美國每年因軟體品質低落造成的損失放在超過兩萬億美元。這個數字集中在系統品質那一圈，而不是程式碼品質那一圈。招再多測試工程師也修不好它。

四種失敗模式

在 100+ 開發者共同開發一個產品時，軟體品質失敗不再是一條長尾——它開始變成一個分類法。四種失敗模式解釋了大部分代價。每一個都是診斷性的——讀者應該能夠指著某段話裡的一句話，說「對，這正是我團隊正在發生的事」。

1. Conway 定律漂移

Conway 1968 年的論文只有一句話，之後的五十八年裡，整個領域都在試圖逃離它：組織設計出來的系統，必然是其溝通結構的鏡像。 對 100+ 開發者規模而言，這意味著系統的形狀永遠滯後於上季度的團隊圖。如果團隊圖變化得快，而系統的所有權邊界跟得慢，系統就會意外地漂移成一片多語言亂燉——團隊在哪裡成立，服務就出現在哪裡；團隊在哪裡建牆，契約就碎在哪裡。最常見的一類事故，就是 A 團隊那個健康的更動，呼叫了 B 團隊一個未被記錄的假設。

這種失敗模式是漂移，不是錯誤。Conway 漂移發生在：團隊圖在動，而 CODEOWNERS 檔沒動。接縫已經不在團隊圖說它在的地方。系統已經不是在鏡像組織——它在滯後於組織。

2. 認知負載溢位

Skelton 與 Pais 的 Team Topologies（第二版，2025）給第二種失敗模式起了一個精確的名字。一個 stream-aligned 團隊有認知負載（cognitive load）：管理這個團隊的關注點（concern）所需的總心智努力。負載有三種形式——內在的（intrinsic，團隊領域本身的不可避免的複雜度）、外來的（extraneous，來源不是工作本身，而是系統形狀不對）、與生成性的（germane，團隊真正想要的那種「邊學邊做」的負載）。當三者之和大於團隊的容量，團隊不會放慢——它會從組織速度裡減去自己，因為每一次更動都會變成對其他某個關注點的部分回歸。團隊的實工時產出下降，而回歸的成本在下游複利。

業內的經驗法則是：當一個 stream-aligned 團隊的並行關注點超過大約六個時，它就開始從組織速度裡減去自己。這不是軟偏好。這是 Team Topologies 十年諮詢經驗裡報告的經驗拐點。多數 100+ 開發者規模的組織，每個團隊都跑在 8、10、12 個並行關注點上——他們正在為慢程式碼審查、漏掉的邊緣情況、和「重寫吧」的 PR 付出代價；後者幾乎都是負載溢位的症狀，而不是品質判斷。

3. 聯邦化品質

品質是團隊之間接縫的屬性。如果沒有人擁有這條接縫，就沒有任何一個團隊的 owner 把系統當成自己的關注點——而缺陷會從所有權的缺口裡冒出來。聯邦化品質發生在：每個團隊負責「自己的」程式碼，但沒有任何團隊負責自己程式碼與系統其餘部分之間的契約。團隊各自的程式碼審查都能過；系統在生產環境集體地失敗。

這個框來自 DORA 研究計畫（Forsgren, Humble, Kim——《Accelerate》）。他們提出的四個指標在結構上就是系統級的：你沒法只看一個團隊的 PR 就測出它們。它們是品質被正確聯邦化時的實證信號——或者，當它們很差時，是品質變成一個沒有國家（state）的聯邦。這正是 反模式原文 從工程師視角所警告的那種失敗模式；在 100+ 這個規模上，相同的反模式變成了團隊之間的反模式，單個工程師看不見。

4. 激勵倒掛

第四種失敗模式，是所有其他介入都打不死的那一種。如果團隊級指標是 DORA 的 change fail rate，但管理者級評估的是每個工程師的個人速率（individual velocity），那全域最佳就永遠達不到——團隊被獎勵快速發佈，工程師被獎勵發佈更多，而系統為這種錯位買單。Ron Westrum 的組織文化類型學——2004 年發表在 Complexity 期刊上——把這種動態命名為病態（pathological）組織文化：一種懲罰吹哨者、獎勵「看起來在產出」的文化。

2026 年最常見的版本是：團隊已經接納了 DORA——四個指標在儀表板上，海報貼在牆上——但同時在績效考核週期裡繼續獎勵個人速率。指標說「我們是精英團隊」；組織架構的現實說「我們在獎勵錯的東西」。這正是 Shift-Right, Shift-Left 那篇 隱含地警告的那種失敗模式：DevOps 流水線 ≠ DevOps 激勵結構。一條快速發佈的流水線，配上一套獎勵局部吞吐最佳化的激勵，所產生的矛盾，最終由客戶來承擔。

DORA：唯一的度量框

對軟體交付效能來說，唯一的度量框，是經歷了十年同儕審查複現仍站得住的那個。DORA 計畫——全球持續時間最長的對高績效技術組織的研究——產出了四個指標；它們合在一起，是唯一有實證履歷去支撐「the canonical set」這一稱謂的指標集。

四個指標是：

1. 變更前置時間（Lead time for change）——從一次可合併的提交，到它在生產環境執行。
2. 部署頻率（Deployment frequency）——組織多久向生產環境發佈一次。
3. 復原平均時間（MTTR）——一次生產事故從發生到復原所用的時間。
4. 變更失敗率（Change fail rate）——在生產環境造成服務降級或需要修復的變更百分比。

四個指標在結構上就是系統級的：你沒法只看一個團隊的 PR 測出任何一個。DORA 計畫每年透過 State of DevOps 報告 發佈精英與落後之間的差距。截至撰文時點能取得的最新報告，精英團隊發佈頻率約為落後團隊的 208 倍，復原事故的速度約為 2,604 倍，變更失敗率約為落後團隊的七分之一。定性結論——精英發佈更頻繁、復原更快、失敗更少——才是承重的。

四個指標各自抓到一個失敗模式。變更前置時間抓 Conway 漂移。部署頻率抓聯邦化品質。MTTR 抓認知負載溢位。變更失敗率抓激勵倒掛。四個指標合在一起，是診斷框。

Team Topologies：為什麼人多了沒用了

為什麼過了 100 人，再招人不會讓速度變快？直覺上的答案——溝通成本——對，但不精確。精確的答案是：團隊已經超載，而超載的團隊對新來的邊際貢獻者一無所能。

認知負載框之所以重要，是因為它告訴管理者要修什麼。當「我們發佈得不夠快」時，常規修法是招更多工程師。認知負載框說：問題不在工程師數量，而在團隊內在負載。修法是降負載——拆團隊、削掉外來負載、把關注點移到平台團隊——而不是再招人，讓新人的協調成本本身成為下一輪負載。

這就是 Team Topologies 詞彙體系的位置之所在。四個團隊類型與三種互動模式，給了管理者一個重新設計團隊負載的詞彙表。如果團隊超載，下一輪迭代不是「再招人」——是「重新設計團隊的負載」。

Conway 在 100+ 上的應用

Conway 定律最有用的地方是診斷，最沒用的地方是處方。診斷是更容易的那一步。挑你架構裡的任何一個服務。看團隊圖。問：哪個團隊擁有這個服務？ 如果答案是「兩個團隊共同擁有」或「平台團隊擁有，但 stream-aligned 團隊 X 擁有資料模型」——Conway 漂移已經在動了。修法不是重新設計服務。修法是重新設計團隊圖，讓所有權邊界變得清晰。

最便宜的具體介入是架構決策日誌（ADR）——團隊圖變化時，一條 ADR 記錄它，架構隨之而來。架構決策日誌那篇就是這個論證的操作版。

這張圖是兩條平行路徑。左路徑是紀律——團隊圖與 CODEOWNERS 乾淨對位，服務有穩定的所有權。右路徑是漂移——團隊圖在動，但 CODEOWNERS 沒動，系統正在為漂移付出代價。

用你自己的數字看一看

四種失敗模式認出比度量容易。下方這個計算器是一個快速診斷。它用每個工程經理手上都有的三個代理變數：團隊規模、迭代節奏、缺陷逃逸率。輸出是每位開發者每週的審查負載，紅綠燈是基於 DORA 精英團隊表現的一條已發佈的啟發式。

預設讀數（team_size=100, cadence=2 weeks, defect_pct=8）是一個典型的 100+ 開發者組織。輸出（57.1 → 紅色）不是 bug——它就是診斷。

90 秒自檢

第二個診斷針對的是激勵倒掛——任何其他介入都打不死的那一種。涵蓋四個失敗模式的十二道是非題。輸出是組織在 Ron Westrum 的組織文化類型學（Reactive / Local / Federated / Generative）上的位置。

管理者手冊

四元素表。它把文章從診斷帶到行動。每個元素都裝得進一個季度，且能在管理者現有權限內驗證——不需要重組。

1. 要度量什麼

四個 DORA 指標，按優先順序排序。每個指標抓到一個（或多個）失敗模式。

如果你今天連這四個數字中的一個都報不出來，那這就是要修的第一件事。前置時間與變更失敗率是兩個最診斷性的。

2. 要改變什麼

四個失敗模式按優先順序排序，每一項配一個不需要重組的 ≤ 90 天介入。

這個順序不是隨意的。激勵倒掛排在第一，因為所有四個失敗模式都會被「獎勵錯東西」的激勵放大；把激勵先修對，下三項介入會容易得多。Conway 漂移排在最後，因為它的修法最機械——靠寫 ADR 與更新 CODEOWNERS 的紀律。

3. 要停止度量什麼

四個與品質負相關的反向指標。

四個反向指標之所以誘人，是因為容易度量。四個 DORA 指標更難落地，但回饋形狀是正確的。

4. 那一個問題

一句管理者在 1

「你們團隊最後一次發佈了一個、其他團隊直到生產環境才知道的更動，是什麼時候？」

如果答案是「這個季度」，那失敗模式是 Conway 漂移。如果答案是「這個月」，那就是 Conway 漂移加上聯邦化品質。如果答案是「我們不知道——我們沒在度量這個」，那失敗模式是激勵倒掛。如果答案是「從來沒有」，那團隊就在自檢的 Generative 象限裡，手冊是預防性的。

這個問題被校準為：能放在 1

參考文獻

文章的三層框不是作者發明的。它們是軟體工程領域被複現最頻繁的發現。下方文獻是讓這些主張站得住的最小引用足跡。

1. DORA — DevOps Research and Assessments——產出四指標度量框的計畫；本文把那個框視為唯一的規範集合。年度 State of DevOps 報告是上文精英與落後差距數字的資料來源。
2. Forsgren, Humble, Kim — Accelerate——DORA 研究的學術發表；四個指標的實證基礎。
3. Skelton, Pais — Team Topologies, 2nd Edition (IT Revolution, 2025)——認知負載框；四個團隊類型與三種互動模式。
4. Conway, M. E. — “How Do Committees Invent?” (Datamation, 1968 年 4 月)——原文；一句話，份量很重。
5. Westrum, R. — “A Typology of Organisational Cultures” (Complexity 期刊, 2004)——自檢使用的 Reactive / Local / Federated / Generative 類型學。
6. Consortium for IT Software Quality (CISQ) — “The Cost of Poor Software Quality in the US”——§2 引用的「兩萬億美元」品質低落代價的實證依據。

收尾

100+ 開發者規模上的軟體品質，是接縫的屬性，不是程式碼的屬性。四種失敗模式並不新。手冊並不新。四個 DORA 指標並不新。新的是組合：四種失敗模式一起，DORA 作為診斷框，手冊作為介入——被應用在原始來源未曾專門覆蓋的規模上。

把所有失敗模式裝在同一個詞下的傘，是系統品質（system quality）。這個詞是本文為論證目的而造出來的——品質作為團隊之間接縫的屬性。讀到最後仍然帶著這個問題走的讀者，是把手冊帶走的讀者。