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

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

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

    軟件項目的啟動源于市場和客戶的需求，通過對市場的需求調查以及典型目標客戶的需求訪問抽象出需求規格說明書，進而才開始原型系統的設計，經過對原型系統的評估之后啟動真實系統的設計和開發。

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

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

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

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

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

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