項目管理：需求管理

需求管理是項目中技術相關的最為重要的內容，項目失敗的主要原因就是需求不清晰，所以需要在項目中對需求特別重視。IT項目執行過程中的需求和售前的需求不同，售前的需求是為了更快的形成有針對性的解決方案，而項目中的需求是真正將客戶的需要形成為客戶提高效率，進行業務操作的IT系統的需求工作，並且有嚴格的需求管理、需求變更等更深深層的內容。有很多書籍對需求的獲取和管理提供了詳盡的指導，但需求的獲取及管理是一種實踐型的方法，只是憑理論是做不好需求的獲取和管理，有如看開車的視頻是不可能在馬路上開好車的。

業務需求放映客戶對系統的目標要求，在項目定義中，項目目標和建設內容概要部分，說明的就是這種業務需求，從客戶和用戶處獲取需求以後所完成的是客戶當前業務及需要，但此時的業務需求還具有一些不確定性，很大可能還需要對業務流程進行改進後才是真正的業務需求。如果業務需求的穩定性較差，則最好採用先諮詢項目後建設項目的方式，避免投資的浪費。業務需求一般用業務流程圖來描述。

用戶需求描述了用戶使用此系統或產品針對日常的工作必須要完成的任務。業務需求很容易對業務描述達成一致，而用戶需求則不同，用戶對實現這個業務方式的方法理解不一致。用戶對如何實現這項業務有了千差萬別的理解，所謂「條條大道通羅馬」，但是我們修路只能修一條，是修高速公路呢？還是修普通公路呢？正因為如此，用戶需求是最不好平衡的，甚至對系統界面上的文字要求都可能起到對整個系統的影響。

n

功能的需求和用戶需求息息相關，有什麼樣的用戶需求，就會有什麼樣的功能。需求不是設計，有時候把系統的原型當成一種需求，實際上可以用原型來引導需求，而不是真正的需求。非功能性需求描述了系統展現給用戶的行為和感受，例如一些操作界面的要求，或者去滿足某些規範和約束。

無論那一種需求，都需要和客戶、用戶充分溝通，進行驗證，這樣會提高需求分析報告的清晰度，另一方面是為後續的工作提供堅實的基礎，無論是設計、開發、測試、驗收，都是和需求緊密相連的。

需求完成以後形成需求規格說明書，同時開始對需求進行管理，需求形成項目範圍，經過審批以後成為範圍基線，就可以正式進行設計和開發了。

用戶需求的影響：

n

公司曾經為客戶開發一個小軟體系統，實現一個非常簡單的流程和數據上報功能。合同簽訂以後，我們提出要進行用戶調研，客戶對我們說，不用調研，直接按照我們的思路和想法實現就可以，我們提出，系統最後要有真正的使用者來用，他們如果不提供，最後系統可能會缺乏信息而有隱患，客戶固執己見，經過公司溝通以後項目繼續。很快系統上線運行，客戶要求用戶來培訓，準備使用系統的時候，系統的數據上報功能遭到用戶的強烈不滿，言辭激烈，客戶負責人等面紅耳赤，啞口無言，項目組在座位上臉色蒼白。雖然從合同簽訂到系統部署上線，只有不到一個月的時間，但是對項目組而言，所有的時間完全浪費了，項目徹底失敗，只能從頭再來。後來凡是客戶再有這種沒有用戶需求的事情發生，我就講解這個教訓，這會讓客戶轉變觀念，積極為我們協調真正的用戶來參與。