在IT行業(yè)中，有一個不能忽視的問題。做IT項目，客戶老是喜歡在項目進行過程中修改需求或者增加新需求。在項目一開始的階段，客戶不清楚自己到底需要怎么樣一個系統(tǒng)，往往在項目進行中突然明白或者說清楚自己真正想要個什么樣的系統(tǒng)。
就我以前的經(jīng)驗和思路，我對這個問題的解決思路基本上是這樣的。這個問題就是如何面對那些經(jīng)常在發(fā)生變化的業(yè)務(wù)需求。所以這些在項目過程中提出來的變化需求也并不是客戶在無理取鬧，反而對客戶來說比在項目開始階段那些雙方互相確定的需求更加有意義和重要。
首先，變化就意味著風險。我們當然要把這個問題當作項目中風險的一種來處理。那常規(guī)的處理方法也就這么幾個。風險的量化，風險的監(jiān)控什么的。實際上判定一種風險對我們的影響程度究竟有多大的時候，我們往往只需要問自己一個問題就可以：新需求發(fā)生或者老需求變化時候，我們是否已經(jīng)習(xí)慣處理這樣類似的突發(fā)事件?我總結(jié)了一下，我們以前處理的時候無非也就是這樣五種情況。
1. 我們以前解決過，這對我們沒什么，很正常的事情。(作戰(zhàn)能力強的團隊都有資格這么說)
2. 我們沒解決過，但公司里其他項目組，產(chǎn)品組好像解決過。有專門的解決方案文檔可以查閱。(向公司內(nèi)部尋找?guī)椭莻€好辦法，但在中國行不通，我就看見過有人可以解決但就故意不配合你，讓你自己解決去，而不給予任何幫助。)
3. 公司里沒有這樣的解決方案的資料，但是有很多第三方的資源可以利用。(做JAVA的人好像都喜歡，的確我也聽說這樣一句話：“內(nèi)事不決問老婆，外事不決問google”)
4. 好像聽說過有人解決過，不過記不清楚了。(等于沒說，其實就是沒辦法解決問題)
5. 的確之前沒有解決過這樣的問題。但可以試一下，可以作點有開創(chuàng)性的工作應(yīng)該會有成就感。(以積極的態(tài)度來看待自己從來沒有經(jīng)歷過的工作)
其實當我們面對一個變化的需求或者新需求時候，可以看看我們是采取上面五種情況里那一種來解決。我認為如果能用前面三種情況解決，基本上我們就可以答應(yīng)客戶去做或者更改需求。如果是后兩種，最好還是慎重點為好，特別是最后一種，雖然態(tài)度是不錯的，但態(tài)度有時候并不決定一切。好心辦壞事的事情屢見不鮮。
但是就算這樣，并不能算結(jié)束了。其次我們還要評估一下需要增加或者修改的需求對客戶的重要性問題。對于客戶那邊的業(yè)務(wù)人員來說，這樣一個需求在他們眼里是怎么樣的也決定了我們是否答應(yīng)他們做這個需求。
如果系統(tǒng)中沒有這樣一個功能，業(yè)務(wù)人員是否會注意?或者他們會注意到?jīng)]有這么一個功能但覺得并不影響他們使用系統(tǒng)。又或者是一小部分或者一大部分甚至整個系統(tǒng)都需要依賴這個功能，沒有它影響很大?這個也是我們在評估的時候需要考慮到的。
當我們面臨這樣一個嶄新的或者變化的需求，我們要從過去的風險解決經(jīng)驗，對客戶業(yè)務(wù)人員的重要性和技術(shù)團隊使用技術(shù)水平這三方面來評估。我以前也是經(jīng)常這么做的，說老實話我覺的還湊合，基本上不會讓客戶說閑話。而且有時候我們要頂住客戶的無理需求時候，拿這三個做理由往往都能讓他們無話可說。畢竟我們講的出道理為什么不答應(yīng)做這個新需求。
還有一點就是如果我們這個項目團隊沒有人會完成或者修改這個需求所需要的技術(shù)怎么辦?因為我是做JAVA的，JAVA
的東西是在是太多了，就我看見的技術(shù)人員，沒有一個人是十八般兵器樣樣皆精的。所以這也是需要考慮的。
這樣一個需求所需要用的技術(shù)是否是我們需要一段培訓(xùn)時間才能掌握的?或者有可能我們會，但是掌握的不太熟練，需要用一段時間才能達到熟練水平。當然也有可能我們已經(jīng)很熟練了?；蛘邔ξ覀儊碚f這完全是小菜一碟。