6人模型
上一篇文章說到了“2條主線和4個步驟”；那么順理成章的，我的軟件開發和團隊“最小模型”就是6人模型。在展開6人模型以前，我必須闡明以下幾個觀點作為6人模型的總則：
l 首先，我之所以要用6人而不是6角色，就是想暗示我認為6人各自獨立的必要性，而反對合並和兼職（雖然我對兼職也有一定的理解――請查看以后的章節：金剛合體和巨人肩膀），我認為6人可以不必全程參與，但不要合二為一。
l 6人是最小模型，6人缺一不可，缺一則傷及軟件質量的根本，或者說，軟件質量會減低到我能容忍的極限以下，但是否達到我的質量標准不等於軟件成功的標准，這個大家要有清楚的認知。
l 6人具有各自的專業領域，各自有獨特的方向和技能。也許我們的團隊暫時找不到6個絕對合適的人，但我們必須承認這是我們的方向。
哪6人？他們需要會什么並做什么？
1. 管理者
2. 構架者
3. 需求者
4. 設計者
5. 編碼者
6. 測試者
管理者
遵循管理主線的團隊領導,引領航行的舵手和船長.
管理者需要軟件項目管理的技能。
管理者是“閑職”嗎，答案肯定是否定的，我們不扯PMP 9大領域，5個環節，我們也不扯CMMI關於各種管理的長篇大論，我就指出我認為管理者不得不做的4件事情，大家來看看我們需不需要這個管理者。
1. 時間管理：計划告訴大家要做什么，監督了解大家正在做什么，做了多少；審核保證大家的工作已經完成。告訴我，如果沒有管理者，誰知道，大家需要做什么，現在做了多少，未來什么時候做完。
2. 溝通管理：軟件開發不是獨立存在，有隨時要求更多的客戶，有期望永遠大於實際的高層，每天都有不同的人希望了解，交流和變更軟件開發的內容和進程，這些交流工作交給只願意帶着耳機悶頭開發的人合適嗎。
3. 團隊管理：3人成黨，4人成幫，人的問題總是比代碼復雜的多，無論組織個小型的飯局，還是解決每個人的煩惱，這里總需要一個協調人的存在。
4. 風險管理：軟件開發有風險嗎，有，而且大到任何人無法相信，從來沒有按時完成的軟件計划，從來沒有符合需求的軟件產品；那么誰來帶領大家未雨綢繆，在風險到來前做好一切准備，把風險的影響降到最低，只能是管理者。
構架者
遵循技術主線的團隊領導,軟件開發最終還是技術活,技術高低決定軟件的層次高低。
構架者需要精通項目相關技術，並具有相當的應用經驗，能夠選擇和駕馭相關技術給出項目的合理解決方案。並且該解決方案可追蹤，可執行，可培訓。
首先構架者需要了解一定規模的該領域的相關技術，以便於根據不同項目要求進行選擇，構架者需要有足夠的技術儲備。
技術選擇了還不夠，構架者需要對其的可執行性具有相當的把握，自己都不會，奢求其他人無師自通？最典型的構架笑話是，大家就按某某構架自己做把，自由發揮，如果大家利用一個構架都沒有你來的透徹，那么你為什么不能先行消化，讓大家少走彎路，減少質量損耗；反之，如果有人對構架的理解比你還高一籌，那么為什么讓你來當構架者。
最后構架不能僅僅考慮能否實現，還需要考慮延伸屬性，比如性能，穩定，並發等等問題。這個就需要積累，非一日之功。
需求者
需求是軟件存在的理由,滿足需要是軟件成功的主要標准,需求者是原始需求的發掘者，並加以整理和抽象，成為軟件的需求.
在整個6人模式中，管理者應該是完全的非技術人員（雖然很多管理者是技術出生，但在我的模型里面他的技術職能幾乎沒有）；而需求者是對半開，為什么怎么說，需求者分2個階段。
l 需求挖掘－客戶交流
l 需求開發－系統分析
需求挖掘需要的是交流能力，邏輯能力。
而系統分析，需要的是邏輯能力和軟件設計，分析和一定的技術功底。
需求人員需要從客戶那邊挖掘（請注意不僅僅是記錄，因為很多客戶不了解自己的實際需求），然后抽象，分析並設計出一個軟件的雛形，給設計者提供前置范圍。同時，需求者需要在構架者的幫助下，基於自身一定的技術功底，保證所設計的軟件系統架設在可執行的技術構架之上。
設計者
承上啟下，軟件最終形態的創造者,同時也是需求的監督者和編碼的指導員.
具有軟件具體表現的設計能力，他是系統分析的后續和細化，但為什么不讓需求者進一步細化設計，這個理由我后面會說：如果沒有設計者，設計也不會消失，而是向需求或開發兩端轉移，一般是向開發轉移，設計和需求或開發合並會出現什么問題，這個我后面會詳細闡述。
很多公司的美工會成隱性的軟件設計者，這個是有道理的，因為界面和人機互動的確是軟件設計最關鍵的一環。但我認為設計者最好還是具有一定的技術背景，無任何技術背景的設計者會給開發者帶來不小的困擾，所以我比較建議美工僅僅作為設計者的一個外部資源來調用。
編碼者:
軟件的最終實現者。
編碼者的能力和事務我這里不加累述了。大家都是對於開發都不陌生。
測試者
軟件質量的守護神,需求,設計和編碼的監督者.
可以這么說即使需求－設計－開發環節是無懈可擊的，測試者的作用依然是存在的，不同角度的需求驗證對軟件的質量起到定海神針的作用，況且，無懈可擊的開發流程，更象是一個神話，不是嗎？
測試人員，需要具備測試的相關的工具和方法，他的主要責任是驗證需求的一致性，但很多時候他們會參與到技術糾正里面去，如果出現了這種情況，他們就更顯得不可或缺，因為如果沒有他們，軟件的質量將會如何？
軟件團隊的標准和缺陷
由上，我們可以得出一個軟件團隊的標准：
有沒有管理
有沒有特定的構架
有沒有專業的需求人員
有沒有中層設計師
有沒有開發（這個不會沒有）
有沒有測試的最終防線，
以此6點，來了解一個軟件團隊有沒有最基本的配備。
這些條件都極大的影響到了軟件的質量和項目的成敗。那么如果達不到這些標准，是否軟件就沒辦法開展了呢，事實也不完全是這樣的，除了開發以外，軟件可以在缺少其他5人的狀態下完成，因為軟件開發是一項神奇的活動――請參考我的《引論-談下我的軟件和團隊之路》，但缺少任何一人，對軟件會造成什么缺陷呢，請讓我慢慢分解：
無管理：整個開發是無序狀態的，開發團隊不受控制難於了解，難以了解項目的計划和進度，無任何信息輸出，大部分風險都無法回避和減輕，各種團隊矛盾難以化解。
無構架：項目的技術風險無法欲知，很容易進入技術雷區，即使勉強度過也很容易留下隱患；每個開發的技術無法統一，造成項目技術選擇混亂，即使僥幸完成項目，該會在項目的維護過程中吃盡苦頭。最后一點，團隊的水平永遠無法提高。
無需求：軟件會迷失於開發者的自我想象，而大部分客戶都沒有確認需求的習慣，大家都希望做完了再看，看完了再改；而最后的結果是，導致開發成果與客戶預期偏差太大，大量修改返工，成本時間增加，程序員無窮壓力，導致團隊陷入泥潭，最終崩潰。
無設計：設計常常有實際開發者獨自完成，其質量，內容完全決定於個人，質量水平，設計標准無法統一，使得項目出現風格迥異，瑕疵不斷的尷尬局面，雖然可能不傷及根本，但難以稱專業。另外開發和設計具有互斥性，設計繁復必然導致開發困難，大多數開發人員，在個人技術弱點和技術難點上，常常趨利避害，簡化設計以減輕自身壓力，造成設計需求服從於開發需求，本末倒置。
無開發：這個大家都很清楚是不可能的，不加累述。
無測試：智者千慮，必有一失；說的是即使開發者具有極強的自律和自檢能力，也需要一個審核者的輔助，何況一個連測試都不具備的團隊，其開發的自律和自檢能力不容樂觀，沒有測試大部分結局只能是錯誤百出。
下面我會陸續推出以下章節：
金剛合體和巨人肩膀： 討論不足6人的一些權益方法和我的看法
簡易團隊構建指南： 圍繞6人模式，來設想構建一個簡單的開發團隊。
6人模式還僅僅是起步： 總結和一些感想。