作為一個(gè)軟件項(xiàng)目經(jīng)理，在項(xiàng)目開發(fā)進(jìn)行中,，你是否遇到過(guò)這樣的問(wèn)題：客戶的一個(gè)電話,，就推翻了之前你與客戶、與你自己的開發(fā)團(tuán)隊(duì),，經(jīng)過(guò)再三討論而確認(rèn)定下來(lái)的需求,。之后你就重新開始了和客戶、和你的開發(fā)團(tuán)隊(duì)進(jìn)入新一輪的需求談?wù)撝?，甚至是無(wú)休止的談?wù)?。甚至要重新設(shè)計(jì)現(xiàn)有的架構(gòu)。

　　而面對(duì)這種情況,，作為項(xiàng)目經(jīng)理的你是否會(huì)說(shuō)：“我們無(wú)法拒絕客戶, 但也無(wú)法立即滿足他的新需求,所以只好是推到以后再進(jìn)行完善。”或者,，更極端些的想法：客戶總是在異想天開,，客戶的需求在技術(shù)上根本無(wú)法實(shí)現(xiàn)……

　　在與客戶新的需求論證中，你是否會(huì)對(duì)需求確認(rèn)的重要性產(chǎn)生懷疑,。因?yàn)樵谝婚_始已經(jīng)多次和客戶溝通,也在沒(méi)有任何異議的情況下得到了明確的答復(fù),但當(dāng)開發(fā)項(xiàng)目在不斷演進(jìn),客戶對(duì)系統(tǒng)的理解逐步加深之時(shí), 他們最終還是推翻以前自己想要的需求,。而這時(shí)你會(huì)認(rèn)為對(duì)于需求,只有獲取,沒(méi)有確認(rèn)。

　　而因?yàn)樾枨笞兏脑?，致使?xiàng)目多次的延期后,，客戶仍然說(shuō)這不是他們想要的。你還是在抱怨客戶的需求像天氣一樣一直變個(gè)不停,，最終,，無(wú)論是你的抱怨還是客戶的需求變更只會(huì)令項(xiàng)目組中的開發(fā)人員疲于奔命，無(wú)所適從,。

　　在你的軟件項(xiàng)目進(jìn)行開發(fā)之前,，你和你的項(xiàng)目成員是否有過(guò)這樣的想法，在這次軟件項(xiàng)目開發(fā)中,，一定要消除需求變更,，不讓談?wù)摵玫男枨蟀l(fā)生任何的變更?

　　首先，這種想法和認(rèn)識(shí)是錯(cuò)誤的,，軟件項(xiàng)目開發(fā)中的需求變更是不能被完全消除的,。無(wú)論是項(xiàng)目經(jīng)理還是項(xiàng)目開發(fā)人員,，最好在項(xiàng)目開始之前就消除這種想法。需求變更是不可能被消除的,，而“消除需求變更”的想法卻需要被消除,。消除需求變更的所有的努力和想法，在項(xiàng)目開發(fā)進(jìn)行中通常都是費(fèi)力不討好,。

　　項(xiàng)目開發(fā)過(guò)程中,，需求的變更是不可避免的。

　　雖然一般情況下,，項(xiàng)目經(jīng)理花費(fèi)了大量的心力和氣力去避免需求變更,，可最后需求變更總是會(huì)出現(xiàn)。但這并不意味著項(xiàng)目不應(yīng)該做這方面的工作,，無(wú)論是項(xiàng)目經(jīng)理,，還是開發(fā)人員對(duì)于需求變更的正確態(tài)度應(yīng)該和對(duì)待軟件測(cè)試的態(tài)度一樣，在需求變更發(fā)生之前盡量減少需求變更發(fā)生的情況,，以將需求變更帶來(lái)的風(fēng)險(xiǎn)降到最低,。

　　二、需求變更的產(chǎn)生原因

　　在軟件開發(fā)項(xiàng)目中,，需求變更可能來(lái)自方案服務(wù)商,、客戶或產(chǎn)品供應(yīng)商等，當(dāng)然,，也可能來(lái)源于項(xiàng)目組內(nèi)部,。

　　對(duì)于需求變更發(fā)生的原因，細(xì)細(xì)追究起來(lái)無(wú)外乎以下幾種原因：

　　1,、范圍沒(méi)有圈定就開始細(xì)化

　　細(xì)化工作是由需求分析人員完成的,，一般是根據(jù)用戶提出的描述性的、總結(jié)性的短短幾句話去細(xì)化的,，提取其中的一個(gè)個(gè)功能,，并給出描述(正常執(zhí)行時(shí)的描述和意外發(fā)生時(shí)的描述)。

　　當(dāng)細(xì)化到一定程度并開始系統(tǒng)設(shè)計(jì)時(shí),，范圍會(huì)發(fā)生變化,，那細(xì)節(jié)用例的描述可能就有很多要改動(dòng)。如原來(lái)是人工手動(dòng)添加的數(shù)據(jù),，要改成根據(jù)信息系統(tǒng)計(jì)算出來(lái),，而原來(lái)的一個(gè)屬性的描述要變成描述一個(gè)實(shí)體等。

　　2,、沒(méi)有指定需求的基線

　　需求的基線是指是否容許需求變更的分界線,。

　　隨著項(xiàng)目的進(jìn)展，需求的基線也在變化,。是否容許變更的依據(jù)是合同以及對(duì)成本的影響,，比如軟件整體結(jié)構(gòu)已經(jīng)設(shè)計(jì)出來(lái),，是不容許改變需求范圍的，因?yàn)檎w結(jié)構(gòu)會(huì)對(duì)整個(gè)項(xiàng)目的進(jìn)度和成本有初步預(yù)算,。隨著項(xiàng)目的進(jìn)展,，基線將越定越高(容許的變更將越少)。

　　3,、沒(méi)有良好的軟件結(jié)構(gòu)適應(yīng)變化

　　組件式的軟件結(jié)構(gòu)就是提供了快速適應(yīng)需求變化的體系結(jié)構(gòu),，數(shù)據(jù)層封裝了數(shù)據(jù)訪間邏輯，業(yè)務(wù)層封裝了業(yè)務(wù)邏輯,，表示層展現(xiàn)用戶表示邏輯,。

　　但適應(yīng)變化必須遵循一些松耦合合原則，各層之間還是存在一些聯(lián)系的,，設(shè)計(jì)要力求減少會(huì)對(duì)接口入口參數(shù)產(chǎn)生變化,。如果業(yè)務(wù)邏輯封裝好了，則表示層界面上的一些排列或減少信息的要求是很容易適應(yīng)的,。如果接口定義得合理,，那么即使業(yè)務(wù)流程有變化，也能夠快速適應(yīng)變化,。因此,，在成本影響的容許范圍內(nèi)可以降低需求的基線，提高客戶的滿意度,。

　　三,、需求變更控制

　　前面已經(jīng)說(shuō)過(guò)了，在軟件開發(fā)項(xiàng)目開始之前,，就要消除“絕不允許發(fā)生需求變更”的思想。在項(xiàng)目進(jìn)行,，一旦發(fā)生需求變更,，更不要不一味的抱怨，也不要去一味地迎合客戶的“新需求”,，而是要管理和控制需求變更,。

　　1、 分級(jí)管理客戶需求

　　軟件開發(fā)項(xiàng)目中,，“客戶永遠(yuǎn)是對(duì)的”和“客戶是上帝”并不完全的正確,，因?yàn)樵谝呀?jīng)簽定的項(xiàng)目合同中，任何新需求的變更和增加除了影響項(xiàng)目的正常進(jìn)行以外,，還影響到了客戶的投入收益,，所以有的時(shí)候項(xiàng)目經(jīng)理反倒應(yīng)該為客戶著想。

　　對(duì)于項(xiàng)目中的需求,，可以實(shí)行分級(jí)管理,，以達(dá)到對(duì)需求變更的控制和管理,。

　　一級(jí)需求(或變更)是關(guān)鍵性的需求，這種需求如果不滿足,，意味著整個(gè)項(xiàng)目不能正常交付使用,，前期工作也會(huì)被全部否定。這個(gè)級(jí)別的需求是必須滿足的,，否則就意味著否定自已的項(xiàng)目成員和成員的所有努力,，所以定為“Urgent”。 這通常是屬于補(bǔ)救性的debug類型,，要救火,。

　　二級(jí)需求(或變更)是后續(xù)關(guān)鍵性需求，它不影響前面工作內(nèi)容的交付,，但不加以滿足,，新的項(xiàng)目?jī)?nèi)容無(wú)法提交或繼續(xù)，所以是“Necessary”,。一般新模塊關(guān)鍵性的基礎(chǔ)組件,，屬于這個(gè)級(jí)別。

　　三級(jí)需求是后續(xù)重要的需求,，如果不被滿足會(huì)令整體項(xiàng)目工作的價(jià)值下降,，為了體現(xiàn)項(xiàng)目?jī)r(jià)值，也是開發(fā)人員自已的技術(shù)價(jià)值的證明,，所以定為“Needed”,。一般性的重大的有價(jià)值的全新模塊開發(fā)，屬于這個(gè)級(jí)別,。

　　以上三個(gè)等級(jí)是應(yīng)該實(shí)施的,，但時(shí)間性上可以作優(yōu)先級(jí)的排列。

　　四級(jí)需求是改良性需求,，沒(méi)有滿足這類需求并不影響已有功能的使用,，但如果實(shí)現(xiàn)了則會(huì)更好，定級(jí)為“Better”,。界面和使用方式的需求,，一般在這個(gè)檔次。

　　五級(jí)需求是可選性需求,，更多的是偶是一種設(shè)想,，以及一種可能，通常只是客戶的的一種個(gè)人喜好而已,，定級(jí)為“Maybe”,。

　　對(duì)于四級(jí)需求，如果時(shí)間和資源條件都允許的話，不妨做下去,。對(duì)于五級(jí)需求,，正如對(duì)它的描述一樣，做與不做是“Maybe”,。

　　2,、全生命周期的需求變更管理

　　各種規(guī)模和類型的軟件項(xiàng)目的生命周期大致可以分為三個(gè)階段，即項(xiàng)目啟動(dòng),、項(xiàng)目實(shí)施,、項(xiàng)目收尾。不要以為需求變更的管理和控制只是發(fā)生在項(xiàng)目實(shí)施階段,，而是要貫穿在整個(gè)項(xiàng)目生命周期的全過(guò)程中,。

　　站在全局角度的需求變更管理，需要采用綜合變更控制的方法,。

　　(1) 項(xiàng)目啟動(dòng)階段的變更預(yù)防

　　正如前面強(qiáng)調(diào)的,，對(duì)于任何軟件項(xiàng)目，需求變更都無(wú)可避免,，也無(wú)從逃避,，無(wú)論是項(xiàng)目經(jīng)理還是開發(fā)人員只能積極應(yīng)對(duì)，而這個(gè)應(yīng)對(duì)應(yīng)該是從項(xiàng)目啟動(dòng)的需求分析階段就開始了,。

　　對(duì)一個(gè)需求分析做得很好的項(xiàng)目來(lái)說(shuō),，基準(zhǔn)文件定義的范圍越詳細(xì)清晰，用戶跟項(xiàng)目經(jīng)理提出需求變更的幾率就越小,。如果需求沒(méi)做好,，基準(zhǔn)文件里的范圍含糊不清，被客戶發(fā)現(xiàn)還有很大的“新需求空間”,，這時(shí)候項(xiàng)目組往往要付出許多無(wú)謂的犧牲,。

　　如果需求分析做得好，文檔清晰且又有客戶簽字,，那么后期客戶提出的變更就超出了合同范圍,，需要另外收費(fèi)。這個(gè)時(shí)候,，項(xiàng)目經(jīng)理一定要據(jù)理力爭(zhēng)，此時(shí)這并非要刻意賺取客戶的錢財(cái),，而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣,，否則后患無(wú)窮。

　　(2) 項(xiàng)目實(shí)施階段的需求變更

　　成功的軟件項(xiàng)目和失敗項(xiàng)目的區(qū)別就在于項(xiàng)目的整個(gè)過(guò)程是否是可控的,。

　　項(xiàng)目經(jīng)理應(yīng)該樹立一個(gè)理念,，即“需求變更是必然的、可控的，并且是有益的”,。項(xiàng)目實(shí)施階段的變更控制需要做的是分析變更請(qǐng)求,，評(píng)估變更可能帶來(lái)的風(fēng)險(xiǎn)和修改基準(zhǔn)文件。

　　控制需求漸變需要注意以下幾點(diǎn)：

　　需求一定要與投入有聯(lián)系,，如果需求變更的成本由開發(fā)方來(lái)承擔(dān),，則項(xiàng)目需求的變更就成為必然了。所以,，在項(xiàng)目的開始,，無(wú)論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投人也要變,。

　　需求的變更要經(jīng)過(guò)出資者的認(rèn)可,，這樣才會(huì)對(duì)需求的變更有成本的概念，能夠慎重地對(duì)待需求的變更,。

　　小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理流程,，否則會(huì)積少成多。

　　在實(shí)踐中,，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過(guò)程,，認(rèn)為降低了開發(fā)效率，浪費(fèi)了時(shí)間,。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽?，最終導(dǎo)致項(xiàng)目的失敗。

　　精確的需求與范圍定義并不會(huì)阻止需求的變更,。

　　并非對(duì)需求定義得越細(xì),，就越能避免需求的漸變，這是兩個(gè)層面的問(wèn)題,。太細(xì)的需求定義對(duì)需求漸變沒(méi)有任何效果,。因?yàn)樾枨蟮淖兓怯篮愕模⒎切枨髮懠?xì)了,，它就不會(huì)變化了,。

　　注意溝通的技巧。

　　項(xiàng)目開發(fā)過(guò)程中的實(shí)際情況是用戶,、開發(fā)者都認(rèn)識(shí)到了上面的幾點(diǎn)間題,，但是由于需求的變更可能來(lái)自客戶方，也可能來(lái)自開發(fā)方,，因此,，作為需求管理者，項(xiàng)目經(jīng)理需要采用各種溝通技巧來(lái)使項(xiàng)目的各方各得其所,。

　　(3),、項(xiàng)目收尾階段的總結(jié)

　　能力的提高往往不是從成功的經(jīng)驗(yàn)中來(lái)，而是從失敗的教訓(xùn)中得來(lái)。許多項(xiàng)目經(jīng)理不注重經(jīng)驗(yàn)教訓(xùn)總結(jié)和積累,，即使在項(xiàng)目運(yùn)作過(guò)程中碰得頭破血流,，也只是抱怨運(yùn)氣、環(huán)境和團(tuán)隊(duì)配合不好,，很少系統(tǒng)地分析總結(jié),，或者不知道如何分析總結(jié)，以至于同樣的問(wèn)題反復(fù)出現(xiàn),。

　　事實(shí)上,，項(xiàng)目總結(jié)工作應(yīng)作為現(xiàn)有項(xiàng)目或?qū)?lái)項(xiàng)目持續(xù)改進(jìn)工作的一項(xiàng)重要內(nèi)容，同時(shí)也可以作為對(duì)項(xiàng)目合同,、設(shè)計(jì)方案內(nèi)容與目標(biāo)的確認(rèn)和驗(yàn)證,。項(xiàng)目總結(jié)工作包括項(xiàng)目中事先識(shí)別的風(fēng)險(xiǎn)和沒(méi)有預(yù)料到而發(fā)生的變更等風(fēng)險(xiǎn)的應(yīng)對(duì)措施的分析和總結(jié)，也包括項(xiàng)目中發(fā)生的變更和項(xiàng)目中發(fā)生問(wèn)題的分析統(tǒng)計(jì)的總結(jié),。

　　3,、 需求變更管理原則

　　雖然需求變更的內(nèi)容和類型有各種各樣，但需求變更管理的原則卻是萬(wàn)變不離其宗,。實(shí)施需求變更管理需要遵循如下原則：

　　(1) 建立需求基線,。需求基線是需求變更的依據(jù)。在開發(fā)過(guò)程中,，需求確定并經(jīng)過(guò)評(píng)審后(用戶參與評(píng)審),，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后,，都要重新確定新的需求基線,。

　　(2) 制訂簡(jiǎn)單、有效的變更控制流程,，并形成文檔,。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí),，這個(gè)流程具有一定的普遍性,，對(duì)以后的項(xiàng)目開發(fā)和其他項(xiàng)目都有借鑒作用。

　　(3) 成立項(xiàng)目變更控制委員會(huì)(CCB)或相關(guān)職能的類似組織,，負(fù)責(zé)裁定接受哪些變更,。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi),。

　　(4) 需求變更一定要先申請(qǐng)然后再評(píng)估,，最后經(jīng)過(guò)與變更大小相當(dāng)級(jí)別的評(píng)審確認(rèn)。

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

　　(6) 妥善保存變更產(chǎn)生的相關(guān)文檔。

　　四,、需求變更應(yīng)對(duì)之道

　　需求變更控制一般要經(jīng)過(guò)變更申請(qǐng),、變更評(píng)估、決策,、回復(fù)這四大步驟,。如果變更被接受，還要增加實(shí)施變更和驗(yàn)證兩個(gè)步驟,，有時(shí)還會(huì)有取消變更的步驟,。針對(duì)變更控制流程，有幾點(diǎn)應(yīng)對(duì)之道,。

　　相互協(xié)作——很難想像遭到用戶抵制的項(xiàng)目能夠成功,。在討論需求時(shí)，開發(fā)人員與用戶應(yīng)該盡量采取相互理解,、相互協(xié)作的態(tài)度,，對(duì)能解決的問(wèn)題盡量解決。即使用戶提出了在開發(fā)人員看來(lái)"過(guò)分"的要求,，也應(yīng)該仔細(xì)分析原因,，積極提出可行的替代方案。

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

　　安排專職人員負(fù)責(zé)需求變更管理——有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與用戶的隨時(shí)溝通,，因此需要一名專職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流,。

　　合同約束——需求變更給軟件開發(fā)帶來(lái)的影響有目共睹,，所以在與用戶簽訂合同時(shí),，可以增加一些相關(guān)條款,，如限定用戶提出需求變更的時(shí)間,，規(guī)定何種情況的變更可以接受,、拒絕接受或部分接受,，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程,。

　　區(qū)別對(duì)待——隨著開發(fā)進(jìn)展,，有些用戶會(huì)不斷提出一些在項(xiàng)目組看來(lái)確實(shí)無(wú)法實(shí)現(xiàn)或工作量比較大,、對(duì)項(xiàng)目進(jìn)度有重大影響的需求,。遇到這種情況,，開發(fā)人員可以向用戶說(shuō)明，項(xiàng)目的啟動(dòng)是以最初的基本需求作為開發(fā)前提的,，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求),，會(huì)使項(xiàng)目不能按時(shí)完成,。如果用戶堅(jiān)持實(shí)施新需求,，可以建議用戶將新需求按重要和緊迫程度劃分檔次,，作為需求變更評(píng)估的一項(xiàng)依據(jù),。同時(shí),，還要注意控制新需求提出的頻率,。

　　選用適當(dāng)?shù)拈_發(fā)模型——采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項(xiàng)目。開發(fā)人員先根據(jù)用戶對(duì)需求的說(shuō)明建立一個(gè)系統(tǒng)原型,，再與用戶溝通,。一般用戶看到一些實(shí)際的東西后,，對(duì)需求會(huì)有更為詳細(xì)的解釋，開發(fā)人員可根據(jù)用戶的說(shuō)明進(jìn)一步完善系統(tǒng)原型,。這個(gè)過(guò)程重復(fù)幾次后,，系統(tǒng)原型逐漸向最終的用戶需求靠攏,，從根本上減少需求變更的出現(xiàn),。目前業(yè)界較為流行的疊代式開發(fā)方法對(duì)工期緊迫的項(xiàng)目的需求變更控制很有成效。

　　用戶參與需求評(píng)審——作為需求的提出者,，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一,。實(shí)際上,，在需求評(píng)審過(guò)程中,，用戶往往能提出許多有價(jià)值的意見,。同時(shí),，這也是由用戶對(duì)需求進(jìn)行最后確認(rèn)的機(jī)會(huì),，可以有效減少需求變更的發(fā)生,。