吳勇毅

英國有位經濟學家說過，任何變更，即使是向好的方向變更，也總是伴隨著折磨與痛苦。這句話也恰恰道破了信息化建設過程中需求不斷變更的苦惱。這不僅是軟件廠商實施方的煩惱，也是企業(yè)客戶的煩惱。

需求變更不斷，難言之痛

一旦產生需求變更，往往會引起重估、返工，你不得不修改設計，重寫代碼，修改測試用例，調整項目計劃等，從而影響軟件項目的范圍、時間、質量和成本等多個要素，如果控制不好，還會導致項目范圍蔓延、進度延遲、質量不過關和成本嚴重超支等諸多麻煩與問題，甚至因過多的分歧、變更致使半途而廢。因而需求變更在很多軟件項目中都是一件讓人頭疼的事情。

時常聽到這句業(yè)界常言——“上ERP找死，不上ERP等死”。其實何止是ERP如此，中小型的IT項目如OA、CRM等，其成功率也不足55%，客戶滿意率不到30%，有不少項目成了“食之無味，棄之可惜”的雞肋工程。何以如此？需求不斷變更、盲目更改項目內容導致項目難于驗收、結案，“始亂終棄”。

軟件項目變更原因，總結起來主要有：國家政策的改變，使許多企業(yè)單位的財稅政策、產品標準、服務規(guī)范等跟著發(fā)生變化，用戶單位的業(yè)務內容、流程管理跟著變化；客戶可能一開始對項目內容和需求沒有形成初步看法，或者一開始沒有想法但隨著項目的進行、參考其他單位的做法，就產生了一些新想法、新需求；或因為業(yè)務手續(xù)太繁瑣、流程太復雜，引起用戶反感，要求修改；軟件商系統(tǒng)員經驗不足，沒有捕獲到用戶的關鍵業(yè)務需求或者用戶整理需求能力弱，遺漏了關鍵的需求點，導致需求不合需要重改；或可能是數據易丟失，也可能是系統(tǒng)不穩(wěn)定，或是兼容性問題使用戶反應強烈，要求修改等。

可以說，從IT項目的實務看，幾乎沒有一個項目能夠百分之百按照原訂計劃進行，需求變更是不可避免的，也是正常反應，但如果需求無序無度、變更無常，就易造成甲乙雙方的矛盾、對抗，無疑是種內耗，成了信息化建設的絆腳石。IDC機構調查數據顯示，99.5%的信息化建設都曾有需求變更，需求變更達到“嚴重程度”占38.2%，需求變更“無度”即達到甲、乙雙方無法容忍乃至項目破裂的程度占11.3%，只有28.6%的項目需求是甲、乙雙方可協(xié)調，并滿意的。

所有說，有時項目需求的變化好比是“萬惡之源”，一旦發(fā)生了需求變化乃至無序變更，將為項目的正常進展帶來許多的麻煩。因此解決需求變更尤其解決即將驗收、簽案的項目的需求變更，實際上是一項非常復雜、事關全局的工作，必須引起企業(yè)一把手、CIO和項目組成員的高度重視，積極管理、應對，千萬不能虎頭蛇尾、敷衍了事，最后馬失前蹄、敗走麥城。那么怎樣來解決這個問題？有哪些應對之道呢？

如何診治需求變更不斷之痛？

每做一次項目計劃變更，都會影響到日后的成本估算、活動順序、行程日期、資源需求及風險控管的決策，因此甲乙雙方的項目經理、IT經理都必須以整體的視野、統(tǒng)一的要求，對變更進行控制、確認與記錄。需求變更的控制關鍵在于建立相應的控制組織、變更控制系統(tǒng)及規(guī)范變更流程。

充分做好前期的需求調研、系統(tǒng)培訓等工作。深入企業(yè)一線，全面調查研究，最大限度地挖掘企業(yè)用戶的潛在需求，發(fā)現可能有需求變更的地方，讓企業(yè)用戶盡快做出是否進行需求變更的決定。一般把需求變更或者新需求的確認最遲時間定在系統(tǒng)培訓階段。在系統(tǒng)培訓完成后、開始準備雙線并行前，企業(yè)用戶還可以提出需求變更的申請，但是，當系統(tǒng)開始雙線運行時，就不允許用戶再提出需求變更等類似的請求了，如編碼的內容和規(guī)則、表單的數量和格式、數據流轉和統(tǒng)計方式等，否則就要付出變更的代價。

建立變更控制組織系統(tǒng)。項目啟動時，盡可能地與客戶溝通，盡快建立正式的對變更進行控制的組織，通稱變更控制委員會（CCB)，成員可包括雙方高層（掛名）、甲乙雙方的項目負責人、相關的需求負責人等，負責裁定接受變更內容、方法、步驟等。建立該系統(tǒng)的目的是統(tǒng)一管理需求變更和跟蹤變更的狀態(tài)，便于項目組測試人員、開發(fā)人員、系統(tǒng)分析員以及PM相互間的溝通和交流。建立變更控制系統(tǒng)的目的不是讓用戶不提出變更，而是讓用戶不輕易、隨便的提出變更。

嚴格規(guī)范變更流程。一旦需求分析階段結束，此后如果用戶有新的需求加入到即將交付的軟件系統(tǒng)中，甲乙雙方的項目組或變更控制委員會，要根據角色定義，確定變更流程，規(guī)定嚴格的變更控制流程，并控制新需求提出的頻率。

（1）變更申請。系統(tǒng)界面如按鈕的位置、字段的位置的細微調整，不涉及業(yè)務規(guī)則，對基線基本沒有影響的變更，由測試人員直接在變更控制系統(tǒng)中提出，其他如操作風格的較大變化、編碼內容、業(yè)務規(guī)則的變化等，均要求用戶提出電子和書面的需求變更單。

（2）變更評估。由項目組或變更控制委員會組織人員對變更進行合理性分析和替換方案分析，工作量的估算以及涉及什么模塊、影響什么模塊等影響的分析。

（3）變更實施。由測試人員在變更控制系統(tǒng)中填寫變更信息，由系統(tǒng)分析員填寫處理方法和影響分析后交由開發(fā)人員實施。

需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。

選用適當的開發(fā)模型防止多變更。采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項目。軟件供應商研發(fā)人員先根據用戶對基本需求的說明建立一個系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為詳細的解釋，開發(fā)人員可以根據用戶的說明進一步完善系統(tǒng)原型。這個過程重復幾次后，系統(tǒng)原型逐漸向用戶最終的、比較全面的需求靠攏，從根本上減少需求變更過多的現象。目前業(yè)界較為流行的迭代式開發(fā)方法對工期緊迫的項目需求變更控制較為管用。通常情況下，原型之后的需求溝通就實際得多，雙方的理解迅速向一個全面折中的方案貼近，一個可以指導研發(fā)過程、有針對性的需求說明書就可起到重要作用。

通過合同約束，建立有效的解決沖突機制。用戶、開發(fā)商在實施、驗收軟件項目過程中難免會發(fā)生沖突，而需求變更給軟件項目建設帶來的影響也是有目共睹的，從而可能讓項目建設偏離軌道。關鍵事先是否有明確的項目目標和項目要求，是否建立起有效的沖突解決機制。所以雙方在簽訂合同時，可以增加一些相關條款，主要是要明確今后雙方權責關系，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程，否則自擔變更的代價；而企業(yè)用戶，也可對將來可能發(fā)生的重大事件或不可抗拒事件所引發(fā)可能的實施超期、費用超支、產品價格調整以及服務收費超標等事項、行為及其權責做出預測，并有效約定，從而使信息化項目從開始就按雙方預定的軌道行駛，互為制約、協(xié)調，避免再發(fā)意外。

驗收與發(fā)現、檢驗需求并舉。不少的大型ERP項目是邊實施邊驗收，發(fā)現新問題新需求，再進一步返工完善的，一步一步地把項目向前推進，但許多中小型的ERP項目最好是成功切換后，錄入一個月以上的企業(yè)重要數據，上線運行一個月時間，看看有沒有出現新問題、新需求，如沒有就可以驗收、簽案。畢竟一個月才是一個小的系統(tǒng)周期，如果小的周期都沒有跑順，就更別說一年這樣的大周期了。如果ERP系統(tǒng)能做到平穩(wěn)運行一兩個月以上，并能準確導出各類月度報表，系統(tǒng)應用和各項業(yè)務操作基本正常、順暢，通常而言，就可以認為系統(tǒng)已達到理想效果或者是達到先前預定的目標，也說明企業(yè)不再有管理流程、業(yè)務流程等新需求和新變更了，系統(tǒng)項目上線成功后，就可以放心驗收、簽案了。

通過以上幾種手段，如執(zhí)行實施到位，基本可以有效地把變更置于控制之下。

項目需求變更的注意事項

充分交流、協(xié)商。變更管理的過程很大程度上就是用戶與開發(fā)人員的交流過程。軟件供應商項目經理、技術經理必須學會認真聽取用戶的要求、考慮和設想，并加以分析和整理。同時，軟件開發(fā)方應鄭重向用戶說明，進入設計階段以后，再提出需求變更會給整個開發(fā)工作帶來什么樣的沖擊和不良后果，全面權衡輕重。

區(qū)別對待，折中求同。隨著項目不斷進展，不少企業(yè)用戶會不斷提出一些在項目實施組看來確實無法實現或工作量比較大、對項目進度有重大影響的需求。如果用戶仍堅持實施新需求，可以建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的重要依據。如遇到有些需求需要個把月時間才能解決的時候，就不要硬拼，不要讓項目因此僵住，而要通盤考慮一下，是否有臨時的折中方案可以先“應付”一下？如讓用戶先使用現有系統(tǒng)，等過一段時期，技術解決或二次開發(fā)成功后再給用戶免費升級安裝。

需求變更要盡早。建房子，若在房子快造好時，卻發(fā)現原先設計不對，需要推倒重來，那成本與時間的浪費就會非常大。對于軟件項目而言，也是同樣的道理。若項目快完工時，才發(fā)現原先的需求有紕漏、缺失，需要變更重設，那損失就會很大了。因此，項目臨近收尾階段，再進行需求變更的話，給甲乙雙方造成的損失則越大。因此需求變更要趁早，越早提出越好。

總之，需求變更對項目的影響是非常大的。但是，就像天要下雨一樣，我們很難從根本上消除。我們所能夠做到的，就是采取更多行之有效的工作，或者采取一些補救措施，把需求變更給軟件項目帶來的損失降到最小。