處理。調(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)。
3、評估每一次迭代的成本和風險
能夠預見到的是，需求的每次迭代都會不同程度的對項目產(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)。
4、明確項目發(fā)布的需求邊界
軟件不是十全十美的，需求的迭代是永無止境的。需求的迭代周期是不定的，與其在最終版本中包括所有的需求，不妨在這期間發(fā)布