怎樣實施高效的專案管理
專案管理是一個很複雜的過程，需要專案組各成員的努力，那麼，怎樣進行高效的專案管理呢?我們一起來探討探討!
一.需求獲取
需求開發在CMMI中有一個專門的過程域來描述，它在專案管理過程中也是很重要的一塊，因為後續的設計、開發等都是基於需求。如果需求獲取不正確或在需求開發過程中很多功能沒有挖掘出來的話，那麼在後期選擇彌補時，將會造成專案延期以及成本的大幅度增加。
需求開發的目的是產生和分析客戶、產品和產品元件需求。需求是客戶在專案立項時就有的一個遠景，在專案管理過程中它得到不斷的變更和細化。客戶根據需求會決定在整個專案的需求中，要承辦方具體要做些什麼，即承辦方的任務，承辦方具體要實現哪些需求。承辦方在明確了需求後，就會開始後期的設計、開發、測試、部署等工作。
需求獲取的目的是通過各種途徑獲取使用者的需求資訊，由於在實際工作中，大部分客戶是無法完整地講述其需求，因此需求獲取是一件看似簡單，做起來很難的一件事情。在需求獲取過程中，主要需要弄清楚3個問題，即：明確需要獲取的資訊(What)、明確所獲取資訊的來源和渠道(Where)和怎樣獲取需求(How)。下面我們分別對這三點進行講述。
1、明確需要獲取的資訊(What)
需求分析師應在需求獲取前明確需要獲取的資訊，以確保在實施需求獲取時有的放矢。
通常需求獲取要獲取的資訊包括三大類：
1)與問題域相關的背景資訊(如業務資料，組織結構圖，業務處理流程等);
2)與要求解決的問題直接相關的資訊;
3)使用者對系統的特別期望與施加的任何約束資訊。
2、明確所獲取資訊的來源和渠道(Where)
接著需求分析師還應確定獲取需求資訊的來源與渠道，以提高需求分析師在需求獲取階段的工作效率，使得所收集的資訊更加有價值、更加全面。
需求資訊的來源通常包括：
1)來自客戶的需求：
a)舊系統的使用者或客戶對系統安裝、使用、維護、管理等方面的需求;
b)系統的潛在使用者或客戶對系統的需求。
2)競爭對手的產品優勢與不足;
3)國家政策、業務規則以及相關行業標準;
4)實施產品設計所需滿足的需求;
5)執行測試驗證工作所需滿足的需求;
6)實施系統安裝、維護所需滿足的需求。
獲取需求資訊的渠道包括：
1)使用者或客戶;
2)公司研發管理部門;
3)公司技術管理部門
4)專案實施部門;
5)營銷管理部門;
6)舊有系統的研發專案組;
7)來自專案組內。
3、怎樣獲取需求(How)
接下來專案經理應選擇至少一種需求獲取技術獲取相關的需求，作為需求分析的依據。需求獲取技術包括但不限於：
1)使用者訪談
使用者訪談的形式包括結構化和非結構化兩種。結構化是指事先準備好一系列問題，有針對性地進行;非結構化是隻列出一個粗略的想法，根據訪談的具體情況進行發揮。有效的訪談需要靈活的結合這兩種方法。
使用者訪談具有很好的靈活性，有較廣的應用範圍，但實際操作時存在許多困難，例如客戶經常很忙，難以獲得充足的訪談時間;客戶訪談需要需求分析師有很強的溝通能力，同時也要求需求分析師有足夠的相關業務領域知識。
2)使用者調查
使用者調查是通過精心設計提問問題形成調查問卷，然後下發到相關人員手中，讓他們填寫答案，來獲取使用者需求。
使用者調查的方法最大的缺點是缺乏靈活性，由於缺乏面多面的交流，所獲取的資訊量也比較有限。因此在實際工作中，我們建議可以先採用使用者調查的方式獲取一定量的資訊，然後有針對性地開展使用者訪談。
3)現場觀摩使用者的工作流程，觀察使用者的實際操作
俗話說，“百聞不如一見”，對於一些較為複雜的流程和操作而言，是比較難以用語言和文字進行表達的，對於這種情況，可以採用到客戶的工作現場，一邊觀察，一邊聽客戶講解，從而更直觀的瞭解客戶需求。
4)從行業標準、規則中提取需求
如果使用者要求所開發的軟體產品必須滿足一定的行業標準和業務規則，需求分析師可以通過閱讀政策法規、業務規則以及行業標準等各類相關的文件，並與相關領域的`業務專家進行業務交流來了解客戶的需求。
這種方法要求需求分析師有一定的行業從業經驗，能夠了解行業的發展動向，這對從技術出生的需求分析師來說是一個巨大的考驗。
5)文件考古
對於一些資料流比較複雜的、工作表單較多的專案，有時是難以通過說或者觀察來了解需求細節的.
這個時候就可以通過對歷史存在的一些文件進行研究，考古一詞非常形象地說明了其主要的工作重心是通過已經填寫完畢的、也就是帶有資料的檔案、表單、報告，獲得所需的資訊。
6)需求討論會
這是一種相對來說成本較高的需求獲取方法，但也是十分有效的一種。它通過聯合各個關鍵客戶代表，分析人員，開發人員，通過有組織的會議來討論需求。
在會議之前，應該將與討論主體相關的材料提前分發給所有將要參加會議的人。在會議開始之後，先針對材料所列舉的問題進行逐項專題討論，然後對原有系統、類似系統的不足進行開放性交流，並在此基礎上對新的解決方案進行構思，在此過程中將所有的想法、問題和不足記錄下來，形成一個要點清單，作為後續需求分析的依據。
7)原型法
原型(prototype)即把系統主要功能和介面通過快速開發製作為“軟體樣機”，以視覺化的形式展現給使用者，及時徵求使用者意見，從而明確無誤地確定使用者需求。同時，原型也可用於徵求內部意見，作為分析和設計的介面之一，可方便於溝通。原型法主要價值是視覺化，強化溝通，降低風險，節省後期變更成本，提高專案成功率。
原型法的優點是：
i)鼓勵業務管理者的積極參與;
ii)有助於解決業務管理者之間的差異; 來源:學優網網
iii)能給業務管理者一個對最終系統的直觀感受;4)週期短;5)成本低;6)使用者較滿意。
但原型法也有缺點，主要為：
i)導致人們認為最終系統將很快產生;
ii)對系統操作許可權的說明較弱;
iii)不適合於開發大系統;
iv)開發過程管理困難。
在實際開發過程中，筆者所在公司一般比較常用的需求獲取方法是使用者訪談、需求討論會和原型法。對於相對較小的專案，筆者極力推薦原型法，因為通過視覺化的介面，可更容易的、更快的挖掘客戶的需求。 來
二、人員配置
在整個專案的生命週期中，可能涉及到開發方的角色如下：
1、需求分析師
完成產品或專案的需求調研和開發，將客戶的需求變成產品需求，參與需求的討論和分析，完成需求規格說明書等的編寫。
2、系統架構師
系統架構師負責理解系統的業務需求，並建立合理、完善的系統體系架構。架構師也負責通過軟體架構來決定主要的技術選擇。這典型的包括識別和文件化系統的重要架構方面，他側重於系統的質量屬性設計，包括系統的可靠性、可測試性、可重用性、可維護性、可重用性、可擴充套件性、效能指標、元件框架設計、共用基礎結構等。
3、系統分析員
該角色是系統設計中的一個主要角色，他參與需求分析、系統功能設計、系統質量屬性設計等過程。
4、專案經理
專案經理是專案溝通的紐帶，他執行專案的進度跟蹤、質量管理、客戶非技術人員業務交流、專案成員共同、非技術風險管理等職責。
5、配置管理員
該角色的職責是完成專案中各文件的管理等。
6、QA
重點關注軟體過程的質量，在專案中，主要執行的是監督的作用，他參與需求評審、設計評審等過程。
7、開發人員
完成系統的編碼，在有些公司，開發人員還需要進行部分功能模組的設計。
8、測試人員
進行系統的測試，例如功能測試、整合測試、系統測試和驗收測試等，在測試前期，需要編寫測試計劃，並編寫測試用例來輔助測試。
9、美工
負責美化系統介面。
10、專案實施人員
職責為進行專案的實施。
根據專案的大小等的不同，上面的人員配置可能有一些合併，例如在一些較小的專案中，可能會將系統架構師、系統分析師、專案經理的職責都統一到專案經理身上。在一些專案中，若具有系統架構師、系統分析師和專案經理三個角色，有一些人也很容易搞混，在網上有人進行了比較明確的區分，下面讓我們來看看下面的表格：
三、專案管理中需要注意的問題
大家都知道，專案管理的四要素為：質量、進度、成本和資源。這四項如果有一項超出控制，專案就可能會失敗。在筆者的實踐過程中，總結了如下注意事項：
1、明確各人員的任務
明確各人員的任務並對其進行確認。例如，對各開發人員任務的詳細分配後，有些開發人員並不一定清楚了自己所要做的事或理解有出入，做到後來，才發現所做的和專案所需要的南轅北轍，到了這個時候才發現問題，補救不及時的話很可能引起進度的拖延和成本的增加，所以專案經理需要進行確認。
2、跟蹤專案情況
很多開發人員都有這樣的情況，前期開發比較輕鬆，一到要驗收的時候，才發現很多功能還不完善，存在很多bug，於是為了在指定時間內完成任務，只得加班加點。其實這也是管理不善引起的，因為沒有定期的跟蹤專案，對專案所處的狀態不太清楚，所以導致了這種情況。
3、進行風險分析和管理
在專案管理過程中，風險分析也是一個很重要的方面，風險包括很多方面，例如技術風險、人員風險等。
若在專案管理不注意風險的管理，那麼當專案中的風險發生時，很可能引起專案管理的四要素的問題出現。例如若專案組盲目引入新技術，在中後期才發現該新技術在該系統中不合適。再例如，若在專案後期主要設計或開發人員跳槽，若沒有風險管理，沒有采取規避或減弱措施，那麼當這些風險產生時，將會帶來很大的影響。
4、重視需求開發
有些專案組對需求開發不太重視，做需求開發時沒有深度挖掘客戶的需求，在中後期還在進行需求的大幅調整，在進度等方面當然也會受到很大的影響。需求是後續開發的根本，後續的設計、開發、測試等都是基於它的，因而也是重中之重，需要引起大家的重視。
