讀完這章你要能回答：我的管理動作，是在凝聚團隊還是在「殺」團隊？衡量團隊健康，我該看哪個指標？
軟體開發失敗，多數時候不是因為技術不夠強，而是因為人的問題沒處理好。把團隊當成一套社會系統來理解，比把它當成一台機器來管理，更接近真相。
軟體專案的主要問題，本質上是社會學的，不是技術的。技術問題通常有解；人與團隊的問題，才是真正讓專案翻車的地方。
心流與生產力#
知識工作的產出，高度依賴一種叫「心流」（flow）的深度專注狀態——但這個狀態極其脆弱。
進入心流大約需要 15 分鐘，而任何一次打斷（一通電話、一個「借一分鐘」）都會把它清零，得從頭再來。
衡量環境品質可以用 E-Factor（環境因子）：
$$\text{E-Factor} = \frac{\text{不受打擾的時間}}{\text{身處工作場所的時間}}$$
E-Factor 太低的團隊，待在公司的時間再長，真正有產出的時間也寥寥無幾。保護「不受打擾的時間」，就是保護生產力本身。
Teamicide：殺死團隊的七種行為#
許多管理動作出於善意，卻在悄悄謀殺團隊的凝聚力。這些行為統稱 teamicide（團隊謀殺）。
| 殺團隊七行為 | 為什麼致命 | 解藥 |
|---|---|---|
| 防衛式管理（不信任下屬） | 處處設防、不授權，傳遞「我不信你」 | 給予以脆弱為基礎的信任，放手讓人決策 |
| 官僚主義（無意義的紙上作業） | 把精力耗在形式而非價值上 | 砍掉不創造價值的流程與文件 |
| 實體隔離（團隊成員被打散） | 切斷自然的協作與默契 | 讓團隊坐在一起、共享空間 |
| 時間碎片化（一人多專案） | 心流不斷被切斷，沒人能深入 | 讓人專注於單一專案 |
| 產品品質被降低 | 工程師以品質為榮，砍品質就是砍士氣 | 守住品質底線，把它當團隊的尊嚴 |
| 虛假死線（製造假緊迫） | 一旦被識破，所有死線都失去公信力 | 設真實、可達成的時程 |
| 不讓凝聚的團隊延續 | 解散好不容易磨合好的團隊，從零開始 | 專案結束後，盡量讓好團隊留在一起接新任務 |
這七種行為的共通點，是都把「短期效率」放在「團隊長期健康」之前。它們和服務型領導的反模式一樣，常常披著「為公司好」的外衣。
衡量團隊健康：看流動率#
一支真正凝聚（jelled）的團隊，會展現出共同的目標感、自發的協作、以及「我們是一夥的」的認同。但凝聚很難直接量測。
凝聚團隊最可靠的外部指標，是最低的人員流動率。人不想離開，往往比任何問卷都更誠實地說明團隊是健康的。反過來，流動率攀升通常是 teamicide 正在發生的早期警訊。
這也呼應了一句老話：人離開的，往往不是公司，而是團隊與主管（敬業度量測見團隊文化的 Q12）。
本章要點#
- 問題是社會學的：軟體專案翻車多半因為人，不是技術。
- 保護心流：進入心流要 15 分鐘，用 E-Factor 衡量並守住不受打擾的時間。
- 別殺團隊：警惕 teamicide 七行為，它們都把短期效率擺在團隊健康之前。
- 看流動率：最低流動率是凝聚團隊最可靠的指標。
- 留住好團隊：磨合好的團隊是資產，別輕易解散。