行軟體開發中的專案管理 (轉)

行軟體開發中的專案管理
時隔兩年，當我再次坐到電腦面前重新拾起這個話題時，我已經失去了往日的自信和從容。

“IT”往往被圈內人戲稱為“挨踢”，意思是我們常被人踢。老闆踢，市場人員踢，客戶踢，還有老婆踢。老闆怪我們的開發進度慢；市場人員氣我們的東西沒有競爭力；客戶嫌我們的程式BUG多；老婆怨我們沒時間陪她。由此可見，幹我們這一行是多麼地不容易。

下面，我主要談談軟體開發過程中關於專案管理的幾個核心問題。總結成一句話就是：三項調查，二個評審，嚴控變更。

同我們平常做其它事一樣。開發一個專案之前，我們得首先考慮專案的目的、開發時間和大致所需成本。
任何專案都必須有明確的目的。這個專案的任務是什麼？它能為客戶提供什麼樣的產品或服務？它的賣點是什麼？與同型別軟體相比，它有什麼樣的優點？它是否具有充分的擴充套件性……

要想真正得到這些問題的答案，作為專案經理或者稱為專案負責人吧，他在專案立項階段，就得充分調查市場，調查客戶需求，調查自身現有資源，統稱三項調查。只能在充分調查的基礎上，才能做到量體裁衣，開發出適合市場需求的有競爭力的有一定生命力的產品。

調查市場。對一個軟體專案經理來說，他的職責主要在於調查同行業同類產品，分析現有技術，以便構建儘量合量而又有充分擴充套件性的軟體結構。同時，專案經理還有義務協助技術委員會（或者是上級主管）向公司決策層提交專案市場前景分析報告。

調查客戶需求是最關鍵也是最重要的環節。任何一個軟體專案都是針對一定的使用物件而開發的。作為專案經理，你得充分了解客戶的現有資源、工作方式、工作流程以及使用習慣。現有資源又包括客戶的物理裝置、人員素質和經濟實力。值得提出來的是，很多專案經理往往容易忽視客戶的使用習慣，以致於開發出來的產品，雖然功能齊全，介面友好，但卻無法取得使用者的認同。

調查自身資源。主要是調查專案組成員的技術實力，工作狀態，還有其它相關人員的支援度。一個專案的成功，不僅僅需要一個優秀的專案經理，還需要專案發起人、專案組成員和其它相關人員的共同努力，才能實現專案的預期目標。

一個專案有它的開發週期，由專案而產生的產品或服務同樣也有它生命週期。軟體開發週期模型通常有四種：瀑布型、螺旋型、漸進型、原型模型。這些概念，絕大多數開發人員都懂。但在實際開發過程中，隨心所欲的情況還是比較普通。作為專案經理，大有必要根據前面所提到的三項調查來慎重選擇適合自己的開發模式。阿呆的自身經驗證明，隨心所欲開發出來的東西總是漏洞百出。

階段總結和評審。很多公司都搞階段總結和評審。但大多數都被動的階段總結和流行形式的階段評審。

何謂被動的階段總結。一般公司的作為是要求開發人員在規定的時間內（例如一個星期或半個月等）作一次工作總結。偶認為這樣做非常沒有必要，儘管有人認為這樣可以瞭解開發人員的進度等。但這樣做的弊端是很容易引起開發人員的反感和抵制，也無法真正地體現一個專案的實際進展情況。事實也證明了這種措施是非常短命的行政命令。主動的階段總結是由開發人員自行決定總結時間。當然這個時間必須在原定的專案整體完成周期內（甚至可以由專案經理確定總結的條件）。當開發人員認為他手頭的工作已經取得階段性的成果或者有突然性的進展時，由本人主動寫出總結報告提交上一級主管評審。

階段評審。一般來說至少有兩次全體評審。第一次評審是由專案經理完成資訊系統計劃，資訊系統分析、資訊系統設計之後，提交出軟體模型。再交由技術委員會評審。軟體模型必須主體的功能介面。技術委員會的成員包括公司內的主要領導、骨幹技術人員、客戶人員，還要儘可能地邀請典型客戶。典型客戶在其中扮演著重要的角色，只有他們才是最有發言權的評審委員。待專案‘殺青’之後，再由技術委員會對其進行終審。

一個專案在實施過程中，總會遇到很多需要變更的地方。要想有計劃地管理好變更，就必須具備健全的變更控制系統。國內外很多成功的企業都組建了自己的變更控制委員會。由變更委員會來負責專案變更的審批。也由它來決定一個專案是否應該終結。變更委員會通常由專案的直接主管和各專案負責人組成。與技術委員會相比，它更注意成員的專業背景。

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