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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　2、沒有指定需求的基線

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

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

　　3、沒有良好的軟件結(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ì)要力求減少會對接口入口參數(shù)產(chǎn)生變化。如果業(yè)務(wù)邏輯封裝好了，則表示層界面上的一些排列或減少信息的要求是很容易適應(yīng)的。如果接口定義得合理，那么即使業(yè)務(wù)流程有變化，也能夠快速適應(yīng)變化。因此，在成本影響的容許范圍內(nèi)可以降低需求的基線，提高客戶的滿意度。

　　三、需求變更控制

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

　　1、 分級管理客戶需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　精確的需求與范圍定義并不會阻止需求的變更。

　　并非對需求定義得越細(xì)，就越能避免需求的漸變，這是兩個層面的問題。太細(xì)的需求定義對需求漸變沒有任何效果。因?yàn)樾枨蟮淖兓怯篮愕?，并非需求寫?xì)了，它就不會變化了。

　　注意溝通的技巧。

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

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

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

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

　　3、 需求變更管理原則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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