軟件項目是需求驅(qū)動的典型代表，項目從立項、開發(fā)、測試到交付，需求的變化迭代是很正常的事情，這點對于大型項目尤其明顯。需求迭代如果控制不好，很容易增大項目的風險，導致項目的失敗。與國內(nèi)的很多軟件公司相似，筆者所參與的項目也存在需求迭代的問題。本文從需求迭代入手，結(jié)合項目實際，探討需求迭代與項目風險控制的關(guān)系，希望項目需求有序迭代。

    需求迭代，不可避免的輪回

    軟件項目的啟動源于市場和客戶的需求，通過對市場的需求調(diào)查以及典型目標客戶的需求訪問抽象出需求規(guī)格說明書，進而才開始原型系統(tǒng)的設(shè)計，經(jīng)過對原型系統(tǒng)的評估之后啟動真實系統(tǒng)的設(shè)計和開發(fā)。

    在原型系統(tǒng)設(shè)計階段，由于各種各樣的因素，比如客戶沒有將實際需求表達清楚，或者需求分析人員對業(yè)務(wù)的理解有偏差，據(jù)此設(shè)計出來的原型系統(tǒng)可能與市場、客戶的真實需求不是很匹配，那么隨著原型系統(tǒng)構(gòu)建的深入，必然觸發(fā)需求的迭代。

    在真實系統(tǒng)的設(shè)計和開發(fā)過程中，隨著對系統(tǒng)的理解的深入，客戶也可能對需求進行深化、擴展或者變更，研發(fā)工程師對需求的消化，這也會觸發(fā)需求的迭代。

    即使真實系統(tǒng)交付使用，隨著業(yè)務(wù)的發(fā)展，客戶的需求可能發(fā)生變化；而且客戶在使用系統(tǒng)的過程中，必然會對系統(tǒng)提出進一步改進的要求，修改原有功能的操作方式，增加新的功能，這些也會要求需求的進一步迭代。

    在這一系列的迭代過程中，如果沒有很好的控制迭代的過程，評估迭代的成本，有效管理迭代的需求，那么很容易形成需求迭代無窮無盡的假象，項目團隊窮于應付每一次需求迭代，項目開發(fā)高度緊張，發(fā)布日期遙遙無期，這樣必然給項目帶來很高的風險。

    Diapers項目是一個面向北美市場的電子商務(wù)站點，已經(jīng)運行三年。最近客戶決定對Diapers項目進行升級改造。項目經(jīng)理或者需求分析工程師負責溝通客戶，分析抽象客戶的真實需求，并撰寫需求說明書；軟件工程師根據(jù)需求說明書擬定技術(shù)方案，并著手進行編碼；測試工程師根據(jù)需求說明書和測試用例對項目進行測試；項目經(jīng)理引導客戶確認項目的最終功能呈現(xiàn)，并在必要的時候啟動需求迭代過程。

    由于Diapers是來自北美的外包項目，雙方的溝通存在時間差，項目團隊也沒有條件與客戶面對面的溝通。在整個項目的升級改造過程中，由于業(yè)務(wù)理解的偏差以及溝通不暢，需求經(jīng)過了多次迭代；需求每迭代一次，團隊成員都需要面對一堆冗長的需求說明書。由于Diapers已經(jīng)是正式運營的站點，客戶來自市場的壓力同時也轉(zhuǎn)嫁到項目團隊身上，項目發(fā)布的壓力一直困擾著團隊成員。從Diapers項目的進展來看，需求的迭代似乎就是無窮無盡的輪回。

    主動觸發(fā)需求迭代，給予足夠的消化時間

    導致Diapers項目的現(xiàn)狀的主要原因是被動的進行需求迭代，迭代被動的由客戶的反饋觸發(fā)。每次需求迭代都可能打亂團隊的開發(fā)計劃，影響項目的發(fā)布，給團隊帶來更大的發(fā)布壓力。因此，必須想方設(shè)法掌握需求迭代的主動權(quán)。

    針對每次需求迭代給予充分的消化時間是一種有效的方式。從Diapers項目的情況來看，上一次需求還沒有消化處理完畢，新的需求迭代又要開始了。項目發(fā)布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步進逼。在這種情況下，測試工程師壓根兒就沒有時間對項目進行全面的足夠的測試。

    找到問題的本質(zhì),Diapers項目團隊開始調(diào)整發(fā)布節(jié)奏，加大人力資源投入，加快消化需求的速度；針對溝通不足的問題，項目經(jīng)理集中精力與客戶溝通，在雙方時間交叉的部分盡量把有疑問的需求溝通清楚；發(fā)布節(jié)奏調(diào)整后，客戶就有時間與項目團隊同步開展測試工作，bug也能夠在第一時間處理。調(diào)整后，項目團隊有足夠的時間來消化每次迭代的需求，也有足夠的時間對項目進行測試。

    盡早發(fā)布原型系統(tǒng)是主動觸發(fā)需求迭代的另一種有效方式。原型系統(tǒng)通?？焖贅?gòu)建，著重在界面的呈現(xiàn)和功能的模擬，通過虛擬數(shù)據(jù)模擬真實系統(tǒng)的運行情況。其能夠在很大程度上模擬未來真實系統(tǒng)的呈現(xiàn)，在短時間內(nèi)將抽象的客戶需求表現(xiàn)出來，作為和客戶進行溝通的有效媒介。相對于一堆抽象的文檔，使用原型系統(tǒng)，客戶更容易盡早發(fā)現(xiàn)真實系統(tǒng)與他們的需求之間的差距，減少未來需求迭代的次數(shù)。

    因此，在需求抽象過程中，應該通過原型系統(tǒng)作為雙方溝通的橋梁和媒介，雙方應該先就原型系統(tǒng)的呈現(xiàn)展開討論。另外，原型系統(tǒng)的發(fā)布時間也是比較重要的，在項目啟動后應該盡早發(fā)布原型系統(tǒng)。

    Claim項目則是一個商業(yè)意外險理賠平臺，為北美客戶提供商業(yè)意外險的在線申報、理賠服務(wù)。在項目啟動的初期，項目團隊在理解抽象需求的基礎(chǔ)上，第一時間發(fā)布了原型系統(tǒng)，使用虛擬數(shù)據(jù)模擬真實系統(tǒng)的界面呈現(xiàn)。這個項目比較有利的是，客戶自己聘請了需求分析人員，能夠最大程度的理解業(yè)務(wù)需求，正確的表述客戶的需求，并繪制詳細的原型界面；這點在雙方的溝通和系統(tǒng)開發(fā)過程中發(fā)揮了比較顯著的作用。由于Claim項目的需求迭代節(jié)奏一直在項目團隊的可接受范圍，所以項目一直有條不紊的推進，雖然需求也經(jīng)過了多次迭代，但終歸還在可控的范圍內(nèi)。

    評估每一次迭代的成本和風險

    能夠預見到的是，需求的每次迭代都會不同程度的對項目產(chǎn)生影響，對此需要評估由此所帶來的成本。不只是項目經(jīng)理和需求分析工程師，軟件工程師和測試工程師也應該參與這個過程，評估此次迭代是否會影響現(xiàn)有的技術(shù)架構(gòu)，哪些功能點可能受到影響，哪些系統(tǒng)模塊需要修改，測試用例是否應該重新編寫，團隊需要為此次迭代額外付出多少時間成本，是否會造成項目的延期等等。

    評估之后，如果需求迭代對項目的進度可能造成比較明顯的影響，項目經(jīng)理應該和客戶有效溝通，告知需求迭代的成本，尤其是時間成本。

    另外，需求的每次迭代也必然給項目帶來一定的風險，包括技術(shù)風險和發(fā)布風險。迭代后的需求可能影響原有的技術(shù)方案，尤其是核心業(yè)務(wù)邏輯的變更。團隊要重新對技術(shù)方案進行梳理，檢查該技術(shù)方案是否仍然可以達到既定的目的。需求迭代之后，軟件工程師需要一定的時間調(diào)整開發(fā)進度，測試工程師也需要根據(jù)新的需求對系統(tǒng)重新測試，這必然影響項目的發(fā)布周期；作為項目經(jīng)理，應該預見到這一點。

    GS項目是某公司重點研發(fā)的一個以政府機關(guān)行政審批業(yè)務(wù)為服務(wù)目標的產(chǎn)品，在其進行產(chǎn)品升級改造的同時，其競爭對手也在著手準備同類產(chǎn)品的新版本發(fā)布，市場的壓力要求產(chǎn)品盡快完成版本的升級。但是在新產(chǎn)品即將進入集成測試階段的時候，公司突然決定對產(chǎn)品的界面進行比較重大的調(diào)整。這一次調(diào)整導致代碼和測試的返工，使該產(chǎn)品的發(fā)布時間推遲了兩個月，錯過了銷售的黃金期，市場和客戶對于新產(chǎn)品的期待已經(jīng)逐漸降低，結(jié)果產(chǎn)品的銷售量遠遠不如預期。如果公司之前對界面需求迭代有比較清晰的成本和風險評估，那么應該不會這么倉促的觸發(fā)迭代。

    Diapers項目團隊意識到Diapers項目的需求迭代的周期是比較短的，因此對于每次迭代的需求，軟件工程師和測試工程師都會協(xié)同項目經(jīng)理進行評估，判斷消化所有需求并測試所需要投入的工作量，以及由此所可能帶來的時間成本和技術(shù)風險，團隊成員已經(jīng)徹底擺脫了害怕需求迭代的心態(tài)。