需求迭代與項目風險控制[2]

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

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

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

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

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

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

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

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

原文轉自：http://www.anti-gravitydesign.com