英國有位經(jīng)濟學家說過，任何變更，即使是向好的方向變更，也總是伴隨著折磨與痛苦。這一語也恰道破了信息化建設過程中需求不斷變更的苦惱。這種煩惱不僅是軟件廠商實施方所有的，企業(yè)客戶也照樣有這煩惱。
需求的變更，對于項目的影響是非常大的。但是，就如同天要下雨一樣，我們難于從根本上加以消除。我們所能夠做的，就是采取更多行之有效的工作，把這個幾率降至到最低，或者采取一些補救措施，把需求變更給軟件項目帶來的損失減到最小。
1、需求變更不斷，難言之痛
一旦需求變更，往往會引起重估、返工，你不得不修改你的設計，重寫你的代碼，修改你的測試用例，調(diào)整你的項目計劃等，從而影響軟件項目的范圍、時間、質(zhì)量和成本等多個要素，如果控制不好，還會導致項目范圍蔓延、進度延遲、質(zhì)量不過關和成本嚴重超支等諸多麻煩與問題，甚至因過多的分歧、變更而半途而廢。因而需求變更在很多軟件項目中都是一件頭疼的事情。
時常聽到這句業(yè)界常言——“上ERP找死，不上ERP等死”。其實何止ERP如此，中小型的IT項目如OA、CRM等，其成功率也不足55%，客戶滿意率不到30%，有不少項目成了“食之無味，棄之可惜”的雞肋工程。何以如此?需求不斷變更、盲目更改項目內(nèi)容導致項目難于驗收、結(jié)案，“始亂終棄”。
軟件項目變更原因，總結(jié)起來主要有：國家政策不斷改變，三天兩頭一個紅頭文件，使許多企業(yè)單位的財稅政策、產(chǎn)品標準、服務規(guī)范等也要跟著變化，用戶單位的業(yè)務內(nèi)容、流程管理也要跟著變;客戶可能一開始對項目內(nèi)容與需求沒有形成初步看法，或者一開始沒有想法但隨著項目的進行、參考其他單位的好做法，就產(chǎn)生了一些新想法、新需求;或因為業(yè)務手續(xù)太繁瑣、流程太復雜，引起用戶反感，要求修改;軟件商系統(tǒng)員經(jīng)驗不足，沒有捕獲到用戶的關鍵業(yè)務需求或者用戶整理需求能力弱，遺漏了關鍵的需求點，導致需求不合需要重改;或可能是數(shù)據(jù)易丟失，也可能是系統(tǒng)不穩(wěn)定，還可能是兼容性問題，用戶反應強烈，要求修改，等等。
可以說，從IT項目的實務看，幾乎沒有一個項目能夠百分之百按照原訂計劃進行，需求變更是不可避免的，也是正常反應，但如果需求無序無度、變更無常，就易造成甲方、乙方的矛盾、對抗，無疑是種內(nèi)耗，成了信息化建設的絆腳石。IDC機構(gòu)調(diào)查數(shù)據(jù)顯示，99.5%的信息化建設都有過需求變更，需求變更達到“嚴重程度”達到38.2%，需求變更“無度”達到甲、乙雙方無法容忍乃至項目破裂的程度也占11.3%，只有28.6%的項目需求是甲、乙雙方能協(xié)調(diào)、滿意。
所有說，有時項目需求的變化好比是“萬惡之源”，一旦發(fā)生了需求變化乃至無序變更，將為項目的正常進展帶來了不盡的麻煩。因此解決需求變更尤其解決即將驗收、簽案的項目的需求變化，實際上是一項非常復雜重大、事關全局的工作，必須引起企業(yè)一把手、CIO和項目組成員的高度重視，積極管理、應對，千萬不能虎頭蛇尾、敷衍了事，最后馬失前蹄、敗走麥城。那么怎樣來解決這個問題?有哪些應對之道?
2、項目需求變更的幾項須注意事項
需求變更要盡早。若你項目快要完工時，才發(fā)現(xiàn)原先的需求有紕漏、缺失，需要變更重設時，那損失就會大了。建房子，若在房子快造好時，卻發(fā)現(xiàn)原先設計不對，需要推倒重來，那成本與時間的浪費就大得不得了。因此，項目越接近收尾階段，再進行需求變更的話，給甲乙雙方造成的損失則越大。因此需求變更要趨早，早提出早好。
充分交流、協(xié)商。變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件供應商項目經(jīng)理、