本文轉自JavaEye的“黑暗浪子”的帖子，原文鏈接見此如何處理軟件項目中發生的需求變化。
看完后覺得有感觸，最近負責的一個項目就碰到這種情況，由于對技術風險的初始估計不足，給后期帶來了不小的壓力。雖然最終順利完成，但付出的時間和精力比預期的要遠遠大得多。看了這篇文章后，我意識到我至少范了里面提到的第一點忌諱和第三點忌諱。血的教訓啊！以后千萬不能在沒有仔細評估的情況輕易答應客戶的需求變更。
===================================================================
在IT行業中，有一個不能忽視的問題。這個問題就是如何面對那些經常在發生變化的業務需求。做IT項目，客戶老是喜歡在項目進行過程中修改需求或者增加新需求。誠然，在項目一開始的階段，客戶不清楚自己到底需要怎么樣一個系統，往往在項目進行中突然明白或者說清楚自己真正想要個什么樣的系統。所以這些在項目過程中提出來的變化需求也并不是客戶在無理取鬧，反而對客戶來說比在項目開始階段那些雙方互相確定的需求更加有意義和重要。
就我以前的經驗和思路，我對這個問題的解決思路基本上是這樣的。
首先，變化就意味著風險。我們當然要把這個問題當作項目中風險的一種來處理。那常規的處理方法也就這么幾個。風險的量化，風險的監控什么的。實際上判定一種風險對我們的影響程度究竟有多大的時候，我們往往只需要問自己一個問題就可以：新需求發生或者老需求變化時候，我們是否已經習慣處理這樣類似的突發事件?我總結了一下，我們以前處理的時候無非也就是這樣五種情況。
1． 我們以前解決過，這對我們沒什么，很正常的事情。(作戰能力強的團隊都有資格這么說)
2． 我們沒解決過，但公司里其他項目組，產品組好像解決過。有專門的解決方案文檔可以查閱。（向公司內部尋找幫助是個好辦法，但在中國行不通，我就看見過有人可以解決但就故意不配合你，讓你自己解決去，而不給予任何幫助。）
3． 公司里沒有這樣的解決方案的資料，但是有很多第三方的資源可以利用。（做JAVA的人好像都喜歡，的確我也聽說這樣一句話：“內事不決問老婆，外事不決問google”）
4． 好像聽說過有人解決過，不過記不清楚了。（等于沒說，其實就是沒辦法解決問題）
5． 的確之前沒有解決過這樣的問題。但可以試一下，可以作點有開創性的工作應該會有成就感。（以積極的態度來看待自己從來沒有經歷過的工作）
其實當我們面對一個變化的需求或者新需求時候，可以看看我們是采取上面五種情況里那一種來解決。我認為如果能用前面三種情況解決，基本上我們就可以答應客戶去做或者更改需求。如果是后兩種，最好還是慎重點為好，特別是最后一種，雖然態度是不錯的，但態度有時候并不決定一切。好心辦壞事的事情屢見不鮮。
但是就算這樣，并不能算結束了。其次我們還要評估一下需要增加或者修改的需求對客戶的重要性問題。對于客戶那邊的業務人員來說，這樣一個需求在他們眼里是怎么樣的也決定了我們是否答應他們做這個需求。
如果系統中沒有這樣一個功能，業務人員是否會注意？或者他們會注意到沒有這么一個功能但覺得并不影響他們使用系統。又或者是一小部分或者一大部分甚至整個系統都需要依賴這個功能，沒有它影響很大？這個也是我們在評估的時候需要考慮到的。
還有一點就是如果我們這個項目團隊沒有人會完成或者修改這個需求所需要的技術怎么辦？因為我是做JAVA的，JAVA的東西是在是太多了，就我看見的技術人員，沒有一個人是十八般兵器樣樣皆精的。所以這也是需要考慮的。這樣一個需求所需要用的技術是否是我們需要一段培訓時間才能掌握的？或者有可能我們會，但是掌握的不太熟練，需要用一段時間才能達到熟練水平。當然也有可能我們已經很熟練了。或者對我們來說這完全是小菜一碟。
所以當我們面臨這樣一個嶄新的或者變化的需求，我們要從過去的風險解決經驗，對客戶業務人員的重要性和技術團隊使用技術水平這三方面來評估。
我以前也是經常這么做的，說老實話我覺的還湊合，基本上不會讓客戶說閑話。而且有時候我們要頂住客戶的無理需求時候，拿這三個做理由往往都能讓他們無話可說。畢竟我們講的出道理為什么不答應做這個新需求。
-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要盡力打好一手爛牌。
posted on 2009-06-02 09:40
Paul Lin 閱讀(362)
評論(0) 編輯 收藏 所屬分類:
軟件過程與軟件方法