g也能夠在第一時間處理。調整后，項目團隊有足夠的時間來消化每次迭代的需求，也有足夠的時間對項目進行測試。
盡早發(fā)布原型系統(tǒng)是主動觸發(fā)需求迭代的另一種有效方式。原型系統(tǒng)通?？焖贅嫿?，著重在界面的呈現(xiàn)和功能的模擬，通過虛擬數據模擬真實系統(tǒng)的運行情況。其能夠在很大程度上模擬未來真實系統(tǒng)的呈現(xiàn)，在短時間內將抽象的客戶需求表現(xiàn)出來，作為和客戶進行溝通的有效媒介。相對于一堆抽象的文檔，使用原型系統(tǒng)，客戶更容易盡早發(fā)現(xiàn)真實系統(tǒng)與他們的需求之間的差距，減少未來需求迭代的次數。
因此，在需求抽象過程中，應該通過原型系統(tǒng)作為雙方溝通的橋梁和媒介，雙方應該先就原型系統(tǒng)的呈現(xiàn)展開討論。另外，原型系統(tǒng)的發(fā)布時間也是比較重要的，在項目啟動后應該盡早發(fā)布原型系統(tǒng)。
Claim項目則是一個商業(yè)意外險理賠平臺，為北美客戶提供商業(yè)意外險的在線申報、理賠服務。在項目啟動的初期，項目團隊在理解抽象需求的基礎上，第一時間發(fā)布了原型系統(tǒng)，使用虛擬數據模擬真實系統(tǒng)的界面呈現(xiàn)。這個項目比較有利的是，客戶自己聘請了需求分析人員，能夠最大程度的理解業(yè)務需求，正確的表述客戶的需求，并繪制詳細的原型界面；這點在雙方的溝通和系統(tǒng)開發(fā)過程中發(fā)揮了比較顯著的作用。由于Claim項目的需求迭代節(jié)奏一直在項目團隊的可接受范圍，所以項目一直有條不紊的推進，雖然需求也經過了多次迭代，但終歸還在可控的范圍內。
3、評估每一次迭代的成本和風險
能夠預見到的是，需求的每次迭代都會不同程度的對項目產生影響，對此需要評估由此所帶來的成本。不只是項目經理和需求分析工程師，軟件工程師和測試工程師也應該參與這個過程，評估此次迭代是否會影響現(xiàn)有的技術架構，哪些功能點可能受到影響，哪些系統(tǒng)模塊需要修改，測試用例是否應該重新編寫，團隊需要為此次迭代額外付出多少時間成本，是否會造成項目的延期等等。
評估之后，如果需求迭代對項目的進度可能造成比較明顯的影響，項目經理應該和客戶有效溝通，告知需求迭代的成本，尤其是時間成本。
另外，需求的每次迭代也必然給項目帶來一定的風險，包括技術風險和發(fā)布風險。迭代后的需求可能影響原有的技術方案，尤其是核心業(yè)務邏輯的變更。團隊要重新對技術方案進行梳理，檢查該技術方案是否仍然可以達到既定的目的。需求迭代之后，軟件工程師需要一定的時間調整開發(fā)進度，測試工程師也需要根據新的需求對系統(tǒng)重新測試，這必然影響項目的發(fā)布周期；作為項目經理，應該預見到這一點。
GS項目是某公司重點研發(fā)的一個以政府機關行政審批業(yè)務為服務目標的產品，在其進行產品升級改造的同時，其競爭對手也在著手準備同類產品的新版本發(fā)布，市場的壓力要求產品盡快完成版本的升級。但是在新產品即將進入集成測試階段的時候，公司突然決定對產品的界面進行比較重大的調整。這一次調整導致代碼和測試的返工，使該產品的發(fā)布時間推遲了兩個月，錯過了銷售的黃金期，市場和客戶對于新產品的期待已經逐漸降低，結果產品的銷售量遠遠不如預期。如果公司之前對界面需求迭代有比較清晰的成本和風險評估，那么應該不會這么倉促的觸發(fā)迭代。
Diapers項目團隊意識到Diapers項目的需求迭代的周期是比較短的，因此對于每次迭代的需求，軟件工程師和測試工程師都會協(xié)同項目經理進行評估，判斷消化所有需求并測試所需要投入的工作量，以及由此所可能帶來的時間成本和技術風險，團隊成員已經徹底擺脫了害怕需求迭代的心態(tài)。
4、安撫團隊成員的情緒
項目經理應該把握項目的進展情況以及客戶的真實需求，也要知悉客戶的需求底線，更要在必要的時候安撫團隊