關於專案管理的一點體會-轉載

前段時間，我負責了一個專案的管理與開發。在時間短、任務緊，而團隊人員又大部分是沒有經驗的菜鳥的惡劣情況下，我帶領接近40人的團隊，終於在客戶規定的時間範圍內如期交付產品。這其中，經歷了需求變更、人員變動（因為其它任務，先後有近10人離開團隊）等諸多問題，專案仍然取得了成功，不能不說有幾分僥倖，但此外也有一些經驗與教訓可以與大家分享。

專案開發方面

專案應以需求為核心。一個專案是否能夠成功，對需求的準確把握在成功因素中要佔上60%的比例。不管系統的架構設計、團隊管理有多麼的成功，如果需求出現偏差，仍然是南轅北轍。由於EAS專案的特殊性，專案開發過程中能夠與客戶建立有效快速的溝通渠道，是專案成功的關鍵。

需求必須獲得客戶的確認。通過需求調研與分析後獲得的使用者需求說明書，以及軟體需求規格說明書都必須得到客戶的簽字確認。確認的內容包括專案的目標、範圍以及專案需求功能點（用例）。EAS專案在前期對需求不夠重視，導致在需求理解上出現了一些偏差，從而影響了專案的進度。幸而得到了及時的糾正，在專案管理部的協助下，所有需求都得了客戶或客戶代表的簽字確認。從而使得專案在客戶驗收時，有了充分的保證。

專案應確立專門的需求分析師。公司沒有專門的需求分析師，不能不說是人員配備上的一大弊端。（軟體開放工作細分的第一步就是要有專門的系統分析員或需求分析師）從EAS專案的開發過程中，我們就充分地認識到這一問題的嚴重性。需求的不斷更改，客戶遲遲未簽字確認，原因正是在於我們沒有專門的具有豐富經驗的需求分析師。普通開發人員在調研需求以及撰寫需求規格說明書時，總是會出現偏差或理解錯誤的地方。軟體需求分析是一項重要且負責的技術，沒有經過專門訓練的需求分析師，通常會給專案帶來隱患。

專案應指定各個模組的需求介面人。只有這樣，才能有效地保證專案組與客戶的及時溝通，快速響應客戶的請求與反饋。EAS專案在開發早期及時地確立了需求介面人，在一定程度上規避了需求變更給專案帶來的風險。但是，確立的需求介面人未經過系統培訓，在需求調研以及與客戶溝通的過程中，工作表現只能說是差強人意。

注意維護需求調研記錄以及需求跟蹤表。這一工作做得不夠好。由於需求調研人不夠專業，而專案經理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有好的工具或流程來監控這一過程，使得需求調研記錄沒有發揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何專案的需求都不是固定不變的，需求隨時會發生變更，而開發人員實現的需求也可能會與客戶的要求偏差。

注意維護需求矩陣。專案經理對這一內容缺乏足夠的重視與理解，專案開發過程體系中也缺乏好的需求矩陣文件模板。但是在專案中後期，專案及時撰寫了EAS專案需求功能列表，並結合交付版本與客戶進行了溝通和協商，從而規避了需求偏差的風險。(需求追蹤，任何原始需求來有頭就有尾。原始需求->使用者需求->產品需求->軟體需求->設計->測試等一系列的追蹤。需求追蹤的目的一方面是檢查需求是否都已經實現有無遺漏，更多的是為了做變更影響分析使用)

控制需求變更。重視CCB的作用，同時應建立需求變更的響應機制。EAS專案組對於需求變更的響應還不夠及時，這一點專案經理與專案管理小組要擔負一定的責任。（範圍管理中範圍控制的內容，變更管理是配置管理的一個重要內容。需求必須要受到控制，否則容易引起計劃的頻繁調整而發生混亂)

設計

重視架構設計。EAS專案的成功，一定程度是源於我們有個優秀的框架開發小組，我們在專案立項之初就基本確定了整個系統的架構。其中雖然發生了一些變化，但核心架構仍然沒有發生大的變化。由於，我們建立了穩定、簡單的系統框架，可以極大地提高開發效率，規避了對框架的重複編碼。(軟體開發的第二個重要分工就是最好有專門的架構設計人員，架構設計和總體設計要由1-2個人來完成，以保證高度的概念完整性和設計統一)

善於對設計作出取捨。專案開發的三要素是成本、質量與進度。在保證質量的前提下，為了專案進度不出現大的偏差，EAS專案組並沒有過分強調技術，特別是在考慮進度的情況下，犧牲了系統的部分可擴充套件性。雖然這為系統的後期維護帶來一定隱患，但卻能夠有效地保證專案的進度。從EAS最初的架構設計來看，我們引入了 Castle與AOP，試圖簡化ORM以及橫切關注點例如日誌、異常、許可權、事務等功能的實現。同時，希望採用WCF，利用SOA思想建立鬆散耦合的面向服務應用程式。但隨著客戶需求的變化，我們果斷地放棄了採用WCF的構想，同時又克服了技術困難，堅持了對Castle與AOP的使用，併為此成立了框架開發小組。事實證明，在技術的抉擇上我們作出了正確的決定。

重視UI原型設計。系統的原型設計與需求分析相輔相成。如果有好的原型版本交付給客戶，則客戶更能夠理解系統的實現，促進溝通的有效性與準確性。在EAS專案中，我們從一開始就確立了原型設計小組，並在分析需求階段，就開始了原型設計。這一做法無疑在客戶溝通、需求確認、UI設計等方面都發揮了很大的作用。但是，我們在這一點上，由於缺乏專門的UI設計人員，因此，這一工作還存在很大的缺陷，甚至於UI的設計為迭代版本的交付帶來了很大的障礙。在專案後期，關於UI的bug是最多。因此，我們認為在開發類似的WEB應用程式時，應儘早確立UI設計規範，以約束所有的UI設計。同時，必須培養專門的UI設計師，在開始原型設計時，就儘快完成UI互動的設計。並且，必須成立專門的UI 設計小組，在需求階段與需求分析師合作，在編碼階段與開發人員合作。(原型設計是加強前期使用者需求挖掘和減少後期需求變更的重要手段，不一定需要專門的UI設計人員，原型設計可以由需求分析師來完成)

測試

測試成員應瞭解需求。如果不瞭解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導致報告錯誤的bug，影響開發人員效率。加強開發人員與測試人員的合作。開發人員必須及時響應測試人員提交的bug。而測試人員也應跟蹤開發人員對bug的修復情況。(測試人員應該要意識到自己和需求分析人員的區別，測試人員不用想需求分析人員一樣分析和開發業務，但是他們必須和需求分析人員一樣對已經分析出來的需求和業務高度熟悉)

測試之初必須確定測試原則，對bug的嚴重程度進行分級。同時，必須確定修復bug的優先順序別。

進度管理

保證專案進度不出現大的偏差的前提是制定一個好的專案計劃。必須根據專案規模，成員情況，技術難度等多方面考慮整個專案計劃。如果專案的deadline已經確定，則必須採用一些方法來保障專案計劃的完成。首先是選擇符合專案的軟體開發生命週期。通常情況下，並不建議採用瀑布開發方式。最佳的辦法，應該是 RUP或者敏捷開發，然後結合原型法制訂專案計劃。這樣可以規避因為需求變更產生的風險。

其次，要每日跟蹤專案的進展情況。可以通過晨會、週會以及專案日報、專案週報瞭解專案進展情況。同時，需要為各個小組指定進度跟蹤人，根據各個小組長的日報，判斷實際的進度是否與計劃出現偏差。
要制定專案進度偏差的應對方法。一旦專案進度出現了偏差，必須採取相應錯誤解決問題。或者通過加班、增加人手、申請專案進度等方法及時作出響應。

及時向專案成員彙報專案進度情況。只有讓各個專案成員瞭解到專案現狀，才能夠給每個成員增加壓力，不至於鬆懈。同時，也能夠使得每個成員能有一個目標，而不至於茫然失措。

制定專案計劃時，必須考慮階段評審與同行評審的時間。這一點在EAS專案中做得不夠好。其中原因也是由於專案進度本身較緊的緣故。注意維護專案進度跟蹤表與專案進度偏差跟蹤表。讓專案管理部以及QA及時掌握專案進度，有利於對專案進度的管理。

變更管理

變更包括需求變更、人員變更。如果不控制好，兩者對專案的進展都會帶來災難性的後果。需求變更在前面已經敘述，而EAS專案中發現人員變更的情況也非常嚴重，因此這裡重點介紹關於人員變更的管理。

如果發生人員進入的情況，那麼對專案帶來的通常都會是好的影響。但我們也必須注意如何讓新成員更快地融入團隊。整體上講，如果需要新成員加入，發生變更的最佳時機是專案前期。如果在專案中後期加入新成員，無疑則意味著專案出現了災難性的後果。而新增加的成員，由於不熟悉專案，所能帶來好的影響也是有限的。如果不處理好新成員與老成員之間的合作關係，反而會帶來負面影響。

人員的退出很多時候是不可控的，同時對專案帶來的影響也是不可估計的。為了將這些影響降到最低，就必須在專案開始之初就要確立編碼規範。同時，還應該重視對文件的維護與更新。而在人員退出時，必須做好交接工作。同時，還應對這種變更進行合理的評估，並及時報告專案管理部，並與客戶及時溝通。如果對專案進度有嚴重影響，應爭取最大的努力取得客戶的理解，提出專案延期的申請。

風險管理

要在專案開始之初就考慮到專案過程中可能出現的所有風險，是不現實的。但是，我們必須考慮對風險的管理，尤其是在制訂專案計劃以及建立團隊的時候，考慮這一因素。風險有很多，包括需求的風險、進度的風險、質量的風險以及技術風險等。必須制定一套完整的風險管理計劃，而一旦發生了風險，則必須及時響應，組織相關人員解決風險。不能忽略任何一個小的風險，否則一個小的風險到最後會造成大的災難。風險的把握必須要有專案經理與系統架構師把關。

成員管理

不團結的專案組是無法保證專案的成功地。專案經理與專案組長在管理團隊成員時，必須時刻注意成員狀況，即使處理工作出現的矛盾與摩擦，隨時保證團隊合作精神得到最大程度的執行。

持續地保證專案成員的士氣非常重要。專案每取得一個階段性的進展，必須告知全體成員，如此才能收穫成功的信心。專案開發過程需要注意勞逸結合。一味地強制性加班，只能降低專案成員的工作效率。專案過程中，如能適當地開展一些活動，無疑能夠讓團隊成員感受到專案組的集體氣氛。在階段實現的重要時刻，專案經理必須注意通過文字、語言等激勵專案組成員。而專案經理的自信也是保證成員士氣的一個關鍵。

必須注意瞭解團隊成員的心理狀態與工作狀態。專案成員的戰鬥力除了是個人的能力發揮之外，一個好的領導也是至關重要的。因此，必須選擇合適的專案組長，通過他們掌握整個專案團隊成員的工作進展。同時，還要了解每個成員的能力，以安排合適的角色與崗位。

重視開發組與測試組以及專案管理小組的合作。專案組是一個整體，每個成員的角色不同，但大家都是團隊的重要一員。

作者:張逸具有多年的軟體開發與設計經驗，他是兩屆微軟最有價值專家（MVP），著作/譯作包括《軟體設計精要與模式》、《WCF服務程式設計》。張逸熟悉C#，ASP.NET，WCF等技術，同時深諳物件導向領域的相關技術。目前，他主要從事 SOA企業資訊解決方案的設計與研究，以及敏捷方法的推廣與實踐。張逸是捷道

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-421178/，如需轉載，請註明出處，否則將追究法律責任。