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