一個人還是團隊？如何根據技能、依賴關係與風險決定專案的最小配置

研究並不支持 “團隊越小越好” 或 “團隊越大產出一定越多” 這樣的簡單規則。

一項發表於 2023 年的統合分析匯總了 208 個獨立效應和 21,435 個團隊。總體來看，團隊規模與任務績效之間的關係接近於零，但不同情境之間存在很大差異。作者指出，任務複雜度和協調需求等因素會改變團隊規模所產生的影響。 [4]

另一項針對複雜危機地圖任務的實驗也同時發現了大團隊的收益與成本：隨著團隊規模擴大，協作增加，但個人投入方式也發生變化。在這項具體實驗中，規模最大的團隊優於同等數量獨立工作的個人。但這並不能被當作適用於所有工作的普遍公式。 [5]

實際結論很簡單：人數應由工作的性質決定，而不是由一個神奇數位決定。

2020 年 Scrum Guide 將 Scrum Team 描述為規模較小、跨職能並能自主管理工作的團隊。指南還指出，這樣的團隊通常為 10 人或更少。 [3]

這是 Scrum 情境中的 有用指導，但不是適用於所有專案、服務、行業和交付方式的普遍法律。

建築專案、行銷活動、安全評估、金融系統和小型資訊網站的需求完全不同。不能把一個數位直接套用到所有這些情況。

英國 Service Standard 要求數位服務團隊具有多學科能力，並能夠獲得適當範圍的技能。它還指出，團隊配置應取決於當前階段需要實現甚麼目標。 [1]

另一份 GOV.UK 指南說明，團隊規模和所需角色會隨著服務建設階段變化。 [2]

由此可以得到一個實用原則：

先梳理工作和責任，再確定所需技能，最後才把這些要求分配給具體的人。

如果專案範圍不清楚，就無法合理確定團隊配置。

至少寫清楚：

• 要產出甚麼結果，
• 哪些內容屬於範圍，
• 哪些內容不屬於範圍，
• 最重要的品質要求是甚麼，
• 時間和預算限制是甚麼，
• 誰負責驗收結果，
• 團隊只需要交付解決方案，還是也要持續營運。

“做一個應用程式” 與 “設計、開發、保護、部署並營運一個應用程式一年” 對工作覆蓋的要求完全不同。

不要立即填寫職稱，先列出實際必須完成的工作類型。

對於數位服務，可能包括：

• 理解使用者需求，
• 設計解決方案，
• 構建使用者可見部分，
• 構建伺服器端邏輯和集成，
• 測試，
• 安全，
• 無障礙，
• 部署和營運，
• 協調範圍與決策。

其他類型的專案會有不同列表。

GOV.UK 指出，構建並營運數位服務的團隊需要廣泛能力，包括使用者需求、設計、構建、測試、安全、部署和持續營運。 [2]

並不是每項所需技能都意味著團隊內必須有一位全職人員。

可以把每個領域分成：

持續需要 - 經常使用，並直接影響日常決策。
階段性需要 - 只在特定階段或檢查點需要。
外部可用 - 如果響應時間和責任足夠明確，可以由其他人或其他團隊提供。

GOV.UK 明確允許團隊在需要時獲得專業知識，而不要求專業人士一定是常駐團隊成員。 [1]

這種方式經常可以在不失去重要專業能力的情況下，避免人為擴大團隊。

兩個人合在一起可能擁有全部所需技能，但如果所有工作都排在一條狹窄的依賴鏈上，仍然可能是糟糕的配置。

檢查：

• 哪些任務可以並行，
• 哪些任務必須等待其他任務，
• 誰做出的決定會阻塞後續工作，
• 專案依賴哪些外部團隊或供應商，
• 哪些地方一個人的缺席會同時停止多個領域。

GOV.UK 將管理對其他團隊的依賴關係列為構建數位服務所需能力之一。 [2]

當多個團隊共同負責一項服務時，還需要在團隊之間協調計劃和進度。 [8]

有些必要的專業能力不會出現在產品功能列表裡，但缺少它們可能代價很高。

根據專案不同，可能包括：

• 安全，
• 資料保護，
• 無障礙，
• 法律或行業要求，
• 可靠性，
• 資料遷移，
• 與關鍵系統集成，
• 團隊以前沒有使用過的技術。

GOV.UK 建議在專案需要時能夠獲得專業知識，同時指出團隊配置也應反映當前階段風險最高的假設。 [1]

這並不意味著每一種風險都必須設置一個獨立的全職崗位。它意味著 必須有具備相應能力的人承擔明確責任，並真正能夠影響決策。

一個人可能會設計、開發、測試和部署，但這並不表示他能夠在任何期限內同時完成所有這些工作。

PMI 關於資源規劃的材料強調，應把技能、可用性、成本和經驗與專案需求進行匹配。 [7]

對每個人檢查：

• 實際可以投入多少時間，
• 哪些任務會爭奪同一個人的注意力，
• 哪些工作必須並行，
• 時間表是否假設了在多種工作之間進行不現實的頻繁切換，
• 上線之後是否仍然需要有人營運解決方案。

有技能卻沒有足夠時間，並不等於完整覆蓋了專案。

最小配置也應考慮連續性。

問自己：

• 如果關鍵人員無法工作會怎樣，
• 是否只有一個人理解解決方案中的關鍵部分，
• 決策和知識是否被記錄，
• 是否有人可以接替最重要的工作，
• 在人員缺席期間專案能否安全暫停。

不是所有小專案都需要完整備份。在週期短、風險低的專案中，有意識地接受這種風險可能是合理決定。

但在關鍵專案中，同樣的單人依賴可能無法接受。

專案並不需要為每一個角色名稱安排一個不同的人。

如果一個人確實具備所需技能、有足夠的可投入時間，並且不會造成不可接受的風險，他可以負責任地覆蓋多個領域。

例如，在小型專案中，一個人可以同時負責界面設計和實現。在另一個專案中，一個人也可能同時負責商業分析和範圍協調。

不要僅僅因為 “總得有人來做” 就把責任合併。只有當一個人能夠以所需水平完成兩項責任，並且擁有足夠時間時，這種合併才合理。

當以下條件同時成立時，一個人可能就是合理配置：

• 範圍小且定義清楚，
• 所需技能確實在這個人的能力範圍內，
• 任務不需要大量並行工作，
• 外部依賴有限，
• 風險可以接受，
• 期限與實際可投入時間匹配，
• 沒有替代人員的風險被有意識地接受。

例如，小型資訊內容、簡單分析、一次性咨詢，或者在熟悉環境中的有限實施。

最終仍然取決於具體範圍。僅僅貼上 “小專案” 的標籤，並不能自動得出答案。

當以下情況出現多項時，採用團隊就更有依據：

• 所需技能範圍對一個人來說過於寬泛，
• 許多工作必須並行進行，
• 期限短於現實可行的順序執行時間，
• 專案有大量依賴關係和介面，
• 風險需要獨立專業知識，
• 解決方案必須一邊建設一邊營運，
• 一個人會成為整個專案的關鍵單點，
• 責任覆蓋多個明顯不同的專業領域。

在這些情況下，補齊缺失的能力比單純增加人數更重要。

增加人員會擴大可用知識和潛在可用工作量，但也可能增加依賴關係、工作交接以及協調決策的需要。

Journal of Systems and Software 上一項關於軟體專案的研究發現，團隊規模、生產率、工作量和時間之間的關係很複雜，並不總符合直覺預期。 [6]

關於團隊規模的統合分析同樣表明，結果取決於任務情境以及團隊協作過程產生的成本。 [4]

因此，正確的問題不是 “還能加多少人？”，而是 “增加的下一個人，是否消除的真實專案限制大於其新增的協調成本？”

並不是每項重要能力都必須每天留在團隊中。

常駐參與 更適合這樣的情況：這個人經常做決定、其工作與其他領域有大量依賴，或者需要快速響應。

階段性支持 可能足夠用於只在特定時間點需要專業知識的情況，例如審查、咨詢、風險評估或專業驗收。

有一個前提：可用性必須是真實的，而不是名義上的。應明確：

• 誰負責，
• 甚麼時候可以響應，
• 預期響應時間是多少，
• 可以做哪些決定，
• 發現問題後要怎樣處理。

如果只有“可以聯繫專家”這樣的名義安排，卻沒有明確責任，在組織圖上可能很好看，在真實專案中卻未必有效。

假設目標是上線一個線上預約系統。

方案 A：用於驗證想法的簡單原型
範圍有限，沒有付款或特別敏感的資料，目標是與一小組使用者驗證流程。一個能力較全面的人可能能夠覆蓋設計和實現，並在需要時獲得階段性咨詢。

方案 B：包含帳號、付款和集成的公開服務
專業化、測試、風險、依賴關係和並行工作都會增加。由多人組成的團隊會更加合理。

方案 C：持續運行並要求快速響應問題的服務
除了建設，還需要營運、監測、事故應變和知識連續性。足夠支持上線的配置，未必足夠支持長期穩定營運。

總體產品類型相同，但 不同範圍、風險和營運模式會產生不同的團隊需求。

1. 從現成的職務列表開始，而不是從需要完成的工作開始。

2. 默認每個角色都必須對應一個不同的人。

3. 只看技能，不看實際可投入時間。

4. 只加人，卻沒有減少依賴關係和瓶頸。

5. 因為某些風險能力不會產生可見功能，就把它們忽略。

6. 讓多個關鍵領域依賴一個人，卻沒有有意識地接受這項風險。

7. 把專案開始時的配置視為直到結束都不能變化。

GOV.UK 明確指出，服務開發的不同階段會需要不同的團隊規模和角色。 [2]

這個原則在公開服務之外同樣合理：

• 早期可能需要更多研究和問題定義，
• 實施階段，交付和測試能力的重要性會上升，
• 上線前，安全、品質和營運準備可能需要更多投入，
• 上線後，開發與營運之間的比例會變化。

最小配置取決於階段和範圍，而不是一個從專案開始到結束都固定不變的數位。

對每個重要領域記錄五項內容：

工作領域 - 必須做甚麼？
技能 - 需要哪些知識和能力？
責任 - 誰做決定並對結果負責？
可用方式 - 這項能力是持續、階段性還是外部提供？
缺失風險 - 如果缺少這項能力或相關人員不可用，會發生甚麼？

之後再分配具體人員。

如果一個人覆蓋多行，檢查其時間和依賴關係。如果一行需要多個人，確認原因是可用工作量、獨立控制，還是並行工作。

1. 每一個必需的工作領域都有明確負責人嗎？
2. 每一項關鍵責任都有具備適當能力的人承擔嗎？
3. 有人承擔多個角色嗎？其實際時間真的足夠嗎？
4. 專案是否需要當前配置無法支持的並行工作？
5. 是否已經識別對其他人員、團隊和供應商的主要依賴？
6. 重要風險是否能夠獲得正確的專業知識？
7. 一個人缺席是否可能讓整個專案停下來？
8. 如果範圍包括上線和營運，當前配置是否不僅能建設，也能完成這些工作？
9. 是否已經確定哪些能力可以階段性使用，而不需要常駐？
10. 是否設定了在範圍或階段發生變化後重新評估配置的時點？

團隊設計不應從這個問題開始：

“這種專案通常需要多少人？”

更好的順序是：

結果 -> 工作 -> 技能 -> 依賴關係 -> 風險 -> 實際可用工作量 -> 人員。

如果按照這個順序檢查後，一個人確實能夠完整覆蓋全部需求，那麼一個人可能就是正確選擇。

如果缺少技能、時間、獨立檢查、連續性或並行工作的能力，就需要增加人員，或者建立可靠的專業支持。

目標不是最小的團隊。目標是能夠在所需風險和品質水平下，現實地交付目標結果的最小配置。

[1] GOV.UK Service Standard - Have a multidisciplinary team
打開來源

[2] GOV.UK Service Manual - Set up a service team at each phase
打開來源

[3] The Scrum Guide, 2020 - Scrum Team
打開來源

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
打開來源

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
打開來源

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
打開來源

[7] Project Management Institute - Solving The Resource Puzzle
打開來源

[8] GOV.UK Service Manual - Running more than one service team
打開來源

方法說明： 部分來源討論數位公開服務，部分討論 Scrum Team、專案管理，或者團隊與軟體開發研究。本指南只在每個來源實際支持的範圍內使用其內容。確定最小配置的 7 步方法是對這些原則的編輯性綜合，並不是上述任何機構發佈的正式標準。