一移国、令人煩惱的需求變更

作為一個軟件項目經(jīng)理，在項目開發(fā)進行中荷逞，你是否遇到過這樣的問題：客戶的一個電話媒咳，就推翻了之前你與客戶、與你自己的開發(fā)團隊种远，經(jīng)過再三討論而確認(rèn)定下來的需求涩澡。之后你就重新開始了和客戶、和你的開發(fā)團隊進入新一輪的需求談?wù)撝凶狗螅踔潦菬o休止的談?wù)撁钔踔烈匦略O(shè)計現(xiàn)有的架構(gòu)。

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

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

而因為需求變更的原因长豁，致使項目多次的延期后，客戶仍然說這不是他們想要的忙灼。你還是在抱怨客戶的需求像天氣一樣一直變個不停匠襟，最終，無論是你的抱怨還是客戶的需求變更只會令項目組中的開發(fā)人員疲于奔命该园，無所適從酸舍。

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

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

項目開發(fā)過程中兜挨，需求的變更是不可避免的竞阐。

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

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

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

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

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

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

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

2陪竿、沒有指定需求的基線

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

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

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

三喉钢、需求變更控制

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

1伯复、分級管理客戶需求

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

對于項目中的需求想暗，可以實行分級管理，以達到對需求變更的控制和管理帘不。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　(2)項目實施階段的需求變更

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

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

控制需求漸變需要注意以下幾點：

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

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

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

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

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

并非對需求定義得越細(xì)，就越能避免需求的漸變筷狼，這是兩個層面的問題瓶籽。太細(xì)的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的埂材，并非需求寫細(xì)了塑顺，它就不會變化了。

△注意溝通的技巧俏险。

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

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

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

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

3懂算、需求變更管理原則

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

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

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

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

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

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