這些研究表明，效率高和效率低的實施者之間個體差別非常大，經常能夠達到數量級的水平。
The studies revealed large individual differences between high and low performers, often by an order of magnitude...
技而優則管，技術人員晉升爲管理者後，遇到技術問題，往往親力親爲，而不會讓水平更低的下屬來幹。
軟件開發的團隊選擇往往是一個難題，大部分人喜歡一流人才組成的小型、精幹的隊伍。事實上，我也喜歡用精兵強將，在溝通和做事的效率上有明顯的優勢。
誠然，最好的和最差的人在生產率上，往往會有數量級的差距，經驗豐富的程序員能起到以一敵十的效果。但對於大型軟件系統來說，小而美的團隊往往有些力不從心，無法滿足項目時間的需求。
對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發，而對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。如何調和這兩方面的矛盾呢？
外科手術團隊的方式就值得借鑑。
Mills建議大型項目分成小部分，每個小部分由一個團隊解決，而團隊則是以外科手術團隊的方式來構建。也就是說，同每個成員截取問題某個部分的做法相反，由一個人來完成問題的分解，其他人給予他所需要的支持，以提高效率和生產力。
團隊成員的職責如下：
序號 | 團隊角色 | 職責 | 備註 |
| 外科醫生 | 定義功能和性能技術說明書（應該是功能需求和質量屬性），設計程序，編寫源代碼，測試以及書寫技術文檔。 | 需要極高的天分，應用數學，業務數據處理或者其他方面的大量系統知識和應用知識 | |
| 副手 | 主要作爲設計的思考着、討論者和評估者。外科醫生與他溝通設計，但是不受到他建議的限制。副手代表自己團隊與其他團隊溝通功能和接口問題。瞭解所有代碼，並研究設計策略備選方案。 可能編制代碼，但是對代碼的任何部分，不承擔具體開發職責。 | 作爲外科醫生的保險機制。 外科醫生的後備，能完成任何一部分工作，但是相對經驗較少。 | |
| 管理員 | 控制財務、人員、工作地點和辦公設備的專業管理人員，充當與組織中其他管理機構的接口 | 建議在法律、合同、報表和財務方面的需求時，管理員才具有全職責任。 其他情況，可以對多個團隊負責 | |
| 編輯 | 根據外科醫生的草稿或者手術，進行分析和重組，提供各種參考信息和書目，對多個版本進行維護，並監督文檔生成的機制。 | 文檔創建的目的是未來最大透明度的考慮，無論對於內部描述還是外部描述 | |
| 文祕 | 管理員和編輯都需要一個文祕，負責文檔的編寫 | 管理員的文祕負責非產品文件和使項目協作一致。 | |
| 程序職員 | 負責維護編程產品庫中所有團隊的技術記錄； 管理機器碼文件和可讀文件； 進行程序的版本控制，控制程序的運行 | 按時間順序歸檔保存 將程序員從文檔等雜事中解放出來 強化團隊最有價值的財富 - 工作產品 | |
| 工具維護人員 | 維護並保證所有基本服務的可靠性；開發一些實用程序 | ||
| 測試人員 | 負責計劃測試的步驟和爲單元測試搭建測試平臺，作爲外科醫生的對手，對程序設計測試用例；作爲外科醫生的助手，幫助測試 | ||
| 語言專家 | 樂於掌握負責編程語言的人，爲大家提供如何用簡潔、有效的辦法來解決負責、晦澀或棘手的問題的服務 | 爲多個團隊服務 |
外科手術團隊的真正關鍵是“從個人藝術到公共實踐”的編程觀念轉換。它向所有的團隊成員展現了所有計算機的運行和產物，並將所有的程序和數據看做是團隊的所有物，而非私人財產。
我也經常強調，溝通不暢，信息不透明是管理最大的問題。需要協作溝通的人員數量影響着開發成本，因爲成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果（系統調試）。因此，一定要保證一個團隊內部的溝通順暢。
在我們甲方的二開項目團隊，目前仍然是傳統的工作模式，每一位程序員負責一個優化需求，從需求分析，代碼開發，測試和交付等都是由同一個人完成。這麼做有幾個弊端：
1、每一個優化需求只有一個人清楚，團隊其它同事並不清楚。程序代碼上可能會有衝突，以及需要頻繁地合併代碼。
2、每個人都參與功能的設計和開發，每個人的設計理念和風格不一致，水平也良莠不齊，這就導致程序沒有統一的標準。
3、需求文檔，設計文檔，測試文檔等不完善，所有的信息都裝在開發人員的腦袋裏，人員變動時，交接會非常困難，後接手的人需要從代碼入手。
4、從效率上來講，專業化分工是高效的關鍵，成員之間採用非常簡單的交流模式，就類似於工廠的流水線，強制節拍就是簡單高效。前幾年參加一次流程管理的培訓，在課堂實踐案例中，第一次我們採用的方案是每個人從頭到尾負責所有內容，最後的成績是負400多分；流程優化後，第二次我們採用的方案是每個人只負責一小段工作，一段的輸出做爲下一段的輸入，最後的成本是1000多分，前後差距非常大。
對於大型的系統開發，需要將團隊分成若干個外科手術團隊，比如200人的團隊，僅僅需要協調20個外科醫生的思路。
對於協調的問題，還是需要使用分解的技術。整個系統必須具備概念上的完整性，要有一個系統結構師從上至下地進行所有的設計。