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

吳勇毅

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

需求變更不斷，難言之痛

一旦產(chǎn)生需求變更，往往會(huì)引起重估、返工，你不得不修改設(shè)計(jì)，重寫代碼，修改測(cè)試用例，調(diào)整項(xiàng)目計(jì)劃等，從而影響軟件項(xiàng)目的范圍、時(shí)間、質(zhì)量和成本等多個(gè)要素，如果控制不好，還會(huì)導(dǎo)致項(xiàng)目范圍蔓延、進(jìn)度延遲、質(zhì)量不過(guò)關(guān)和成本嚴(yán)重超支等諸多麻煩與問(wèn)題，甚至因過(guò)多的分歧、變更致使半途而廢。因而需求變更在很多軟件項(xiàng)目中都是一件讓人頭疼的事情。

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

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

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

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

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

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

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

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

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

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

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

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

需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動(dòng)都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。

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

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

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

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

項(xiàng)目需求變更的注意事項(xiàng)

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

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

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

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