軟體開發中專案管理的注意事項（轉）

引言：軟體行業從20世紀60年代開始作業系統的研發，到20世紀90年代中期行業快速發展。從原有的作坊式開發到目前團隊協作完成，從早期的技術力量競爭到現有的專案成本控制競爭，從面向結構到物件導向再到面向服務架構，專案管理被提到一定的高度，如何有效的經營專案來降低風險、控制成本，確保專案進度流暢，在有效的時間內保質、保量的完成驗收。成為不少專案管理人士的追求目標。結合個人專案管理實踐，本人有幾點管理注意事項與大家一起分享。

二、專案管理注意事項

開發模型確定

一個專案的好壞，開發模型優良是專案成功重要保障，有了好的開發模型我們可以很好的控制專案進度、降低風險。所以我們在專案開始前首先需要確定專案的開發模型。這裡我們建議採用迭代式的開發模型。我們知道原有早期傳統的開發模型是一個文件驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務後才能夠進入下一個階段。專案開始首先完成系統需求規格說明書，之後才能夠進入概要設計階段，編碼則在系統設計完成之後進行。這就意味著只有當所有的系統模組全部開發完成之後，我們才進行系統整合，對於一個由很多個模組組的複雜系統來說，這是一個非常艱鉅而漫長的工作，且存在著潛在的風險。

如：需求或者設計中的錯誤無法在專案早期發現，只有在系統交付客戶之後才能發現原先對於需求的理解是錯誤的，系統設計的錯誤也只有在測試階段才能被發現。

對於專案風險的控制能力較弱，往往專案風險只能隨著專案結束才能逐步降低，同時也只有經過系統測試之後，才能確定設計是否能夠真正滿足系統需求。

軟體專案常常延期完成或開發費用超出預算專案開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發週期，造成專案延期或費用超支。

專案管理人員專注於文件的完成和稽核來估計專案的進展情況所以專案經理對於專案狀態的估計往往是不準確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個專案80%的開發資源。

在傳統的瀑布模型中，早期是無法發現，需求和設計中的問題，只有當系統第一次整合後，這些設計缺陷才會在測試中暴露出來，需求缺陷則需要等到系統與使用者見面後，方可暴露。從而導致一系列的返工：重新設計、編碼、測試，進而導致專案的延期和開發成本的上升。

為了解決傳統軟體開發流程中的問題，我們建議採用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟體系統開發這個大目標。在迭代化的方法中，我們將整個專案的開發目標劃分成為一些更易於完成和達到的階段性小目標，這些小目標都有一個明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據專案當前的狀態和所要達到的階段性目標制定迭代計劃，整個迭代過程包含了需求調研、軟體設計、軟體實現、版本整合、軟體測試、軟體釋出和產品交付等各種型別的開發活動，迭代完成之後需要對迭代完成的結果進行評估，並以此為依據來制定下一次迭代的目標。

開發計劃制定

確定好專案的開發模型，一整套配套可行的專案開發計劃是開發過程中進度控制的標準，同樣是使用者、公司管理層瞭解專案進展的依據。通常專案管理人員、需求人員和使用者根據使用者原始需求（可以是專案方案書或者是建議書），一起定義整個專案過程中的專案迭代過程個數以及每個迭代過程的開發目標和範圍。

如何進行迭代過程的劃分和範圍有效定義呢？是我們迭代開發計劃制定的首要任務，我們這裡推薦兩種劃分原則。

一、使用者需求至上原則，也就是根據使用者需求的優先順序，進行逐個模組擊破，每一個迭代是使用者需求一個的模組，當然模組小時或者人員充足時，也是在一個迭代中完成兩個或者三個模組。

二、當使用者需求沒有鮮明優先順序時，我們可以採用功能逐步求精開發法，類似於我們早期採用快速原型開發，劃分多個迭代，確定每個迭代需要達到的功能的完善層次，例如，首先第一個迭代僅完成系統的原型開發，第二迭代則緊接著完成各業務基本功能，然後逐步完善直至滿足使用者需求。

無論怎樣劃分我們的迭代過程，總之需要把握一個原則，框架儘早規劃，版本快速整合。專案只要進入軟體實現過程早期,建議實現周版本的概念，確保一週一個版本，一來方便專案管理人員瞭解專案進度、質量，從而根據前期專案完成情況和近期的使用者需求變動及時調整計劃。二來可以儘早將系統與使用者見面，及時發現對於使用者需求理解不正確之處，同時還可以激發使用者潛在需求，細化需求。在軟體實現過程後期，則可以根據需要調整整合版本頻率。所以，雖然每個迭代開發過程中的開發活動是可以選擇性的裁減，但通常軟體實現、版本整合和軟體測試是每個迭代不可缺少的活動，否則迭代過程將失去它的含義。

迭代過程個數和範圍確定後，則需要與每個迭代過程中的開發活動相關者協商討論進度安排，先明確各開發活動的起始、截至時間，然後在根據開發活動的具體需求進行任務細化。如果希望能將專案進度控制在計劃之中，任務越細越好，每個任務跨度不要太大，一天一個任務最好。當然這種情況是很能實現的。確實，我這裡說的是一種比較理想的情況，但並不是不可能。在這裡我們就可以瞭解到迭代開發計劃給我們帶來的好處。專案開始了需求通常都是很泛，不太明確。與使用者交流，可能他認為自己已經表達了所有需要。實際也許他確實已經充分描述了他所知道的需求（業務需求），但完善我們的系統，除了基本業務需求外還有很多非功能性需求，比如：系統效能需求、介面顯示需求、系統操作流程需求等等，尤其是目前B/S架構的開發模式，介面需求已經越顯示出它的重要性。而這些需求在專案早期，在沒有任何可見事務的情況下，使用者很難意識到它的重要性。

我們只有逐個迭代的細化，每一個迭代過程完成既是需求進一步細化的依據又是一個新系統的開始，每個迭代開始前都要根據上個迭代的成果和所要達到的階段性目標細化定製。

組內成員配置

專案啟動之前除專案管理者著手計劃制定外，同時也需要對其專案組那成員配置進行規劃，界定其職責。通常我們需要幾種角色：
技術組長：負責技術難題攻關，組間溝通協調。
需求人員：負責將使用者需求轉換成專案內的功能需求和非功能需求，編制專案需求規格說明書，針對每個迭代整合版本與使用者交流獲取需求的細化。
設計人員：負責對需求規格說明書，進行系統設計。
開發人員：實現設計，完成使用者功能。
整合人員：負責整套系統的編譯整合，督促小組系統功能提交，及時發現各模組整合問題，起到各小組之間的溝通的紐帶。
測試人員：對於整合人員整合的版本進行測試，儘可能的發現程式缺陷，以及未滿足需求的設計。
文件整理人員：負責對小組內產生文件的整合，統一。
系統環境人員：負責系統編譯環境、執行環境規劃。編制系統環境說明書。
維護人員：系統驗收後，維護人員，建議維護人員早期進入專案參與專案測試以便順利承擔起專案維護職責。

專案組啟動初期需求人員首先根據迭代計劃第一個迭代計劃進行需求調研編制功能需求規格說明書，透過專案下到工序人員評審後進入軟體設計、編碼。注意，這裡需求確認並不是指專案中的整體需求，僅僅是指該迭代過程中體現的需求。整個過程類似如專案開發流程，這裡只是細小流程，逐步完善，漸進提交。

五、專案中溝通

通常專案中口頭溝通是最為常見的，包括專案組內部、外部溝通，這種溝通快捷、方便。一般的小問題或者是簡單問題的理解非常有效，但問題複雜或是此次溝通需要後續使用，那麼該種溝通則存在問題，則需要以書面方式加口頭相結合最為有效。即可在本次溝通中方便、快捷的領會，也可以為後續工作提供依據。

通常使用者對於專案進度卻是有要求，不僅需要提交周計劃和總結，還需要定期彙報專案的完成情況，對於即將延時的里程碑，需要提前至少三天時間提出專案延時申請。那麼從這裡我們可以吸取，與使用者的溝通間隔除每週進行專案計劃和總結外，對於使用者認可的專案開發計劃，需要在里程碑需要向使用者彙報，對於即將延時的開發進度，儘可能早的通知使用者方的專案負責人知道，方便使用者方的專案負責人有準備的與其領導溝通，可以有效預防工作被動狀態出現。

專案組內部溝通不是越多越好，你會發現當內部的溝通時間沒有規律或是溝通時間過長，這樣其實也會嚴重影響專案成員的開發進度，但溝通又是必不可少，何種間隔最為適宜了？這是不好定的，我們通常以評審作為溝通的基礎，平日的溝通建議專案組成員在每天工作過程遇到問題，將其記錄下來，然後在以郵件方式傳送給需要溝通或者詢問者。大家可以每天下班之前收取郵件，對於可以直接回答的問題則直接以郵件方式回覆，對於無法直接答覆而只需與提出問題者討論的問題，則可以在第二天上班前進行商議確定。而需要眾人一起討論的問題，則放到每週會議上討論。非常緊急的話則可以馬上約齊人員討論，通常有良好的溝通方式話，這種非常緊急的問題是不常見的。
[@more@]