最小軟體開發團隊探索随筆2014

引論

通過最近幾年的實踐，對于軟體開發的最小團隊模式，有一些新的了解，和大家共享：

• 很多團隊，公司在成本壓力下，總是希望尋求一個最經濟有效的團隊組合，這個是可以了解的，也是該随筆的初衷。
• 最小團隊不是指單純的減少人員，不是把一個需要5個人做的工作壓縮為1個人做。
• 軟體開發本身存在一個衆所周知的弊病，就是隻要存在一個能夠編碼的技術人員，那麼軟體就總是能夠“做”的出來，這也給人一個假象，軟體開發的最小團隊就是一定數量的“碼農”；這個在其他領域比如建築和制造幾乎是不可想象的，究其根源，是因為軟體的品質标準過于的飄渺： 我的意思是，最小團隊絕不是幾個“碼農”。
• 人員可以合并，但角色不能合并；職能可以合并，但能力不能合并: 換言之,擔什麼角色就必須能做什麼事情,就必須具備相應的能力.

總之,我對最小團隊的看法,最小團隊就是最少的角色,而這些角色不能再削減,但人員還是可以以兼任的方式來合并角色,不過在兼任過程中要注意不能有名無實,同時需要具備勝任該角色的能力.

三要素

軟體時開發的三個基本要素是：管理，業務和技術。

管理： 除完全以單人方式進行的開發不在本文讨論的範圍，2人以上就存在一定的團隊管理，人員的協調，工作的安排，流程的部署，進度的監督等等，加上必然存在的客戶管理，“鳥無頭不飛”，說的就是管理者的必要性。

業務： 很簡單，軟體做了半天是為什麼而做，産生什麼效益和結果，這個都需要業務來完成，業務來自于需求，深化為設計，由測試加以驗證, 最後接受者是客戶。

技術： 更容易了解，沒技術能叫軟體開發？軟體開發首先是技術活，但廣義上來說，需求分析，系統設計和開發管理這些也都屬于技術的範疇，隻要需要方法論的地方就需要技術。

是以做軟體先考慮其三大要素，是管理是否成熟，業務是否明确，技術是否過硬，就能知道軟體是否能夠順利完成。

角色

下面我們從3個基本要素的基礎上讨論下，探讨下我心目中的最少角色。

• 管理體系

n  項目經理： 兼顧客戶管理和團隊管理2大職責，在小團隊中，這兩種管理幾乎不可能再拆分。

• 業務體系

n  需求分析：從客戶擷取需求并加以分析，重在和客戶的交流。

n  系統設計：通過軟體的設計方法，把需求升華為軟體系統。由于系統設計是一種非常抽象的升華過程，這裡我認為還是和需求分析分開。

n  測試：對軟體實作業務的确認和評估者。

n  教育訓練：業務的實施者，撰寫系統相關文檔（功能性文檔），另外也需要負責客戶的教育訓練，由于該人員和測試人員有對内和對外之分，目前在角色上還是加以區分。

• 技術體系

n  主程：整個開發技術體系的支援者，就是我們一般了解的“技術高手”，在小團隊中雖然還談不上“構架師”的名頭，但主程除了需要較高的研發能力以外，還必須能教育訓練帶動其他人員進入自己的技術體系。

n  業務開發：一般有被稱為後端開發人員，由于目前的系統都需要大量的資料支援，這樣的人員必然具有極高的資料處理功底。

n  前端開發：由于客戶對界面的要求日益提升，前端人員目前的地位已經大幅提高，不但要熟悉界面構架，界面技術，相當程度也必須熟悉資料查詢和背景技術。

n  界面設計：目前端開發不能達到美觀要求，界面設計人員必須以自己的美術能力加以輔助設計。

目前來看以上9大角色幾乎我認為的最少角色配備（非人員配備），當然其中，教育訓練（如果軟體簡單到不需要教育訓練），主程（技術簡單到不需要高手研發），界面設計（界面簡單到不需要設計），者3個角色為輔助角色，在特定的情況下可以考慮省略，盡管我認為這樣的情況其實并不常見。

人員

有人會說,不是9個角色嗎,我1個人或者2個全包了,這就是最小團隊; 但如果每個角色的工作都要做好,顯然不太現實. 又有人說了,那麼有個角色就馬虎點呗,反正軟體給你做出來就行了: 好,這裡就涉及本文的一個核心問題,我認為這9個角色如果被随意省略,或者根本不做,那麼軟體的品質将會受到極大的影響.

不過9個角色也不是一定需要9個人,那麼最小的人員配備是什麼的, 我談下我的看法:

1. 項目經理可以和需求分析: 這個在很多團隊幾乎是一個标配,由于項目管理和需求分析合并同樣是一種交流為主的工作,這樣的合并并不違和.
2. 系統設計和業務開發: 剛剛說了,需求分析是更偏向于客戶交流的工作,而系統設計則是更多依賴邏輯思維和技術了解的工作,這兩者最好是分開. 而作為系統設計者,對技術構架的了解加上對業務本身的了解,做背景業務開發幾乎是順理成章.
3. 前端開發和界面設計: 在目前日益增長的軟體界面要求下,前端開發的要求越來越高,其工作量和技術要求完全不在業務開發之下. 前後端人員分離是目前比較常見的選擇, 另外, 前端人員業務也需要完成界面布局和一些美觀方面的設計. 當然如果對界面美術要求非常的高, 還是可能需要其他美工的協助.
4. 測試和教育訓練: 測試人員是業務的确認者,那麼就不能由業務的開發者來兼任,系統設計看似是另外一個不錯的選擇,但一方面成本較高,另外一方面兼顧業務開發的系統設計人員可能無暇分身,加上後期教育訓練需要的考慮,加入一個測試人員無疑還是比較劃算的.
5. 主程: 這個人員是可選的, 如果團隊技術架構穩定明确,這個角色可以不加,業務和前端開發人員一樣能夠完成系統的技術實作. 風險也較小, 但如果團隊的技術架構是不成熟的,項目的技術風險特别大的,我強烈建議加入一個獨立的主程人員,為項目的技術實作保駕護航.

 是以我心中的最小團隊這樣的:

• 一個具備管理能力和需求分析能力的項目經理.
• 一個能夠進行系統設計和背景業務開發的業務開發人員.
• 一個具有一定界面設計和較強前端開發能力的前端開發人員.
• 具有測試能力和一定教育訓練和文檔能力的測試人員.

共4人團隊.

如果團隊技術體系不成熟,項目技術風險特别大的時候,請加入

• 一個具有很強研發能力,技術能力過硬,對軟體構架有相當了解的主程人員.

共5人團隊

當然根據項目的規模再适當增加更多的業務開發,前端開發或者測試人員,這裡就不加累述了,而一般項目經理和主程不需要太多人參與.

總結

l  最小團隊指用最少的角色組建團隊,角色可以合并,但工作和能力不能省略.

l  軟體時開發的三個基本要素是：管理，業務和技術

l  軟體團隊最少需要的9個角色是:項目經理,需求分析,系統設計,業務開發,前端開發,測試,教育訓練,界面設計,主程.

l  最小團隊至少包括4-5人: 項目經理,業務開發人員,前端開發人員,測試人員,必要時加入一個主程人員. 

最後，根據我目前的經驗，最小團隊的最大問題不是這個團隊能不能完成任務，而是能不能找到5個合适的人員，最小團隊的确大大削減了人員的數量，但其實是大幅提高了對人員素質的要求，少而精是它的本質，而在實際情況中，既不願意化代價請高手，又不願意化時間教育訓練新人，卻偏偏希望團隊“少而精”，才是這種模式最大的尴尬。

軟體開發,項目管理,開發管理,團隊管理. CMMI,PMP

标簽: 團隊管理, 項目管理, 最小團隊, 軟體團隊