在自己的軟件項目管理職業(yè)過程中，幾乎天天面對用戶的需求變更，切身感受到，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，用戶的耐性漸漸消逝，研發(fā)人員的士氣也越來越低落，最后所有的人都在等待一個結果：項目最好馬上結束。

　　在軟件項目的研發(fā)過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發(fā)，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業(yè)的新動態(tài)，都為軟件帶來不斷完善功能，優(yōu)化性能，提高用戶友好性的要求。我在自己的軟件項目管理職業(yè)過程中，幾乎天天面對用戶的需求變更，切身感受到，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，用戶的耐性漸漸消逝，研發(fā)人員的士氣也越來越低落，最后所有的人都在等待一個結果：項目最好馬上結束。所幸，在不斷的學習和實踐中，我總結了幾點比較有效的方法，在軟件研發(fā)階段能夠較好地解決這方面的問題。

　　1．需求分析階段采用原型方法明確用戶需求。

　　2．需求分析之后的研發(fā)過程采用嚴格的需求變更管理流程。

　　一旦需求分析階段結束，此后如果用戶要求有新的需求加入交付的軟件系統中，需要走需求變更管理流程。這個流程必須在軟件項目成立之初與用戶約定好，一般的軟件企業(yè)內部有需求變更的管理流程，可以向用戶解釋這種管理的必要性，直至與用戶就此問題達成共識為止。不必擔心用戶不會接受，有過多次成功研發(fā)軟件項目經驗的需求變更管理流程，有著它不容置疑的合理性，這正是軟件企業(yè)的經驗和價值所在，用戶最終會理解和同意的。

　　需求變更管理流程各家企業(yè)有各家的做法，借用CMM的需求管理KPA來講，需要兩級需求變更管理委員會（以下簡稱CCB）來處理，即產品CCB和項目CCB。產品CCB處理涉及到產品一級的需求變化，主要體現在需要多個職能部門，多個軟件項目，以及與其他產品線的協調等問題；項目CCB處理本項目內部的需求變更，如不同小組之間的協調，接口變化等等。每一個需求都要經過CCB的審批，決定這個需求的各種屬性描述是否合適，如時間緊迫性，采用的技術是否有風險，對系統的重要程度，需求變更的波動分析，需求實現的資源狀況。在與會人員對需求屬性取得共識之后，規(guī)劃需求實現的版本，確定時間計劃。

　　在此提醒大家，切忌對用戶提出的需求拍胸脯，在此之前可以捫心自問：“如果拍了胸脯，以后不能按時完成，我能不能負擔全部責任？”這樣冷靜一下就不會胡亂應承了。有一個比較好的方式減少這樣的麻煩，就是在需求分析階段之后，與用戶不要親密接觸，而是按照軟件項目的周期，或者雙方在初期的約定，定時通報軟件研發(fā)的進展。如果軟件研發(fā)采用迭代式開發(fā)，就可以在每一期交付產品發(fā)布時做這個事情，征詢到的用戶需求將納入以后某期的軟件版本中。

　　3．為將要頻繁改動需求的軟件項目進行版本規(guī)劃。

　　如果考慮到軟件項目比較大，周期比較長，如超過一年，其間的需求變化必然多得不可勝數，建議采用迭代式開發(fā)，為每個階段的產品進行版本規(guī)劃。第一個版本一般是包括了軟件系統最基本的功能，用戶最關心的功能，它的研發(fā)過程實際上還為后續(xù)版本提供了系統構架和新技術探索。一個按時交付、質量較好的版本可以讓用戶保持對項目成功的信心，并給了用戶在最終產品未出來之前逐漸接近最終產品的機會，這個過程將使用戶需求更加明確和完善，以提高最終產品的一次成功的幾率。所以第一個版本的完成是項目的重要里程碑，建議項目組在此時舉行慶祝會來提高凝聚力，鼓舞員工士氣。后續(xù)的版本規(guī)劃，一般是需求的分期完善，對系統的缺陷做持續(xù)改進。這個過程將一直持續(xù)到軟件的生命周期結束。

　　需求管理是CMM二級就開始關注的KPA，可見其重要性。關于這方面的書籍多種多樣，不過最好的還是行之有效的實踐經驗。我在自己的項目管理中，充分應用上述經驗，可以從容面對我的客戶，希望它對您的項目成功有所幫助。