軟件項目是需求驅動的典型代表，項目從立項、開發(fā)、測試到交付，需求的變化迭代是很正常的事情，這點對于大型項目尤其明顯。需求迭代如果控制不好，很容易增大項目的風險，導致項目的失敗。與國內(nèi)的很多軟件公司相似，筆者所參與的項目也存在需求迭代的問題。本文從需求迭代入手，結合項目實際，探討需求迭代與項目風險控制的關系，希望項目需求有序迭代。
1、需求迭代，不可避免的輪回
軟件項目的啟動源于市場和客戶的需求，通過對市場的需求調查以及典型目標客戶的需求訪問抽象出需求規(guī)格說明書，進而才開始原型系統(tǒng)的設計，經(jīng)過對原型系統(tǒng)的評估之后啟動真實系統(tǒng)的設計和開發(fā)。
在原型系統(tǒng)設計階段，由于各種各樣的因素，比如客戶沒有將實際需求表達清楚，或者需求分析人員對業(yè)務的理解有偏差，據(jù)此設計出來的原型系統(tǒng)可能與市場、客戶的真實需求不是很匹配，那么隨著原型系統(tǒng)構建的深入，必然觸發(fā)需求的迭代。
在真實系統(tǒng)的設計和開發(fā)過程中，隨著對系統(tǒng)的理解的深入，客戶也可能對需求進行深化、擴展或者變更，研發(fā)工程師對需求的消化，這也會觸發(fā)需求的迭代。
即使真實系統(tǒng)交付使用，隨著業(yè)務的發(fā)展，客戶的需求可能發(fā)生變化；而且客戶在使用系統(tǒng)的過程中，必然會對系統(tǒng)提出進一步改進的要求，修改原有功能的操作方式，增加新的功能，這些也會要求需求的進一步迭代。
在這一系列的迭代過程中，如果沒有很好的控制迭代的過程，評估迭代的成本，有效管理迭代的需求，那么很容易形成需求迭代無窮無盡的假象，項目團隊窮于應付每一次需求迭代，項目開發(fā)高度緊張，發(fā)布日期遙遙無期，這樣必然給項目帶來很高的風險。
Diapers項目是一個面向北美市場的電子商務站點，已經(jīng)運行三年。最近客戶決定對Diapers項目進行升級改造。項目經(jīng)理或者需求分析工程師負責溝通客戶，分析抽象客戶的真實需求，并撰寫需求說明書；軟件工程師根據(jù)需求說明書擬定技術方案，并著手進行編碼；測試工程師根據(jù)需求說明書和測試用例對項目進行測試；項目經(jīng)理引導客戶確認項目的最終功能呈現(xiàn)，并在必要的時候啟動需求迭代過程。
由于Diapers是來自北美的外包項目，雙方的溝通存在時間差，項目團隊也沒有條件與客戶面對面的溝通。在整個項目的升級改造過程中，由于業(yè)務理解的偏差以及溝通不暢，需求經(jīng)過了多次迭代；需求每迭代一次，團隊成員都需要面對一堆冗長的需求說明書。由于Diapers已經(jīng)是正式運營的站點，客戶來自市場的壓力同時也轉嫁到項目團隊身上，項目發(fā)布的壓力一直困擾著團隊成員。從Diapers項目的進展來看，需求的迭代似乎就是無窮無盡的輪回。
2、主動觸發(fā)需求迭代，給予足夠的消化時間
導致Diapers項目的現(xiàn)狀的主要原因是被動的進行需求迭代，迭代被動的由客戶的反饋觸發(fā)。每次需求迭代都可能打亂團隊的開發(fā)計劃，影響項目的發(fā)布，給團隊帶來更大的發(fā)布壓力。因此，必須想方設法掌握需求迭代的主動權。
針對每次需求迭代給予充分的消化時間是一種有效的方式。從Diapers項目的情況來看，上一次需求還沒有消化處理完畢，新的需求迭代又要開始了。項目發(fā)布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步進逼。在這種情況下，測試工程師壓根兒就沒有時間對項目進行全面的足夠的測試。
找到問題的本質，Diapers項目團隊開始調整發(fā)布節(jié)奏，加大人力資源投入，加快消化需求的速度；針對溝通不足的問題，項目經(jīng)理集中精力與客戶溝通，在雙方時間交叉的部分盡量把有疑問的需求溝通清楚；發(fā)布節(jié)奏調整后，客戶就有時間與項目團隊同步開展測試工作，bug也能夠在