做過的項(xiàng)目同軟件，基本上最后的程序同開始時確定的都有些偏差...

總結(jié)下，隨便說3個常常碰到的:

第一類，常見的合情理但不合規(guī)矩的，比如報表增加，文檔格式更改，數(shù)據(jù)的查詢，數(shù)據(jù)統(tǒng)計(jì)更改條件等等,事先沒有考慮進(jìn)來但實(shí)際中存在的;

第二類，頭疼的管理決策層需求同應(yīng)用者的沖突,管理決策要加入他們的管理思想，而這需求有時與軟件終端用戶的需求產(chǎn)生不可避免的矛盾沖突，比如管理者需要一個長的清晰明確的數(shù)據(jù)流過程，寄希望在這一套系統(tǒng)上來完善業(yè)務(wù)的管理制度，這樣不可避免的，系統(tǒng)上就會多了一些內(nèi)容，而對應(yīng)用者來說，方便快捷，才是他們想要的，內(nèi)容越少,流程越短他們的效率才越高；

第三類，最頭大的...需求描述與交流不足，理解上的不一致,導(dǎo)致要大改,這個本來應(yīng)該最能避免的,但常常發(fā)生.

下面講下如何避免發(fā)生這類問題：

第一類的問題在于開始時需求就不確定，客戶自己都沒有碰到過的一些突發(fā)事件的考慮是所有人都沒有預(yù)料的,因此對開發(fā)是按行業(yè)開發(fā)思路還是按使用者的意愿的問題就能明白回答了,在開發(fā)時,在數(shù)據(jù)結(jié)構(gòu)上一定要多考慮,即使一些客戶沒有要求的,也要按一般行業(yè)要求來考慮,要考慮可擴(kuò)展性,不能因?yàn)榭蛻粜枨鬀]有要求,或從系統(tǒng)性能上優(yōu)化上考慮,而放棄一些模塊的措施,這樣能避免很多軟件后期更改需求時對數(shù)據(jù)庫或功能模塊作大的修改;

第二類解決時應(yīng)該避免問題放大，確定局部性范圍. 現(xiàn)在在企業(yè)內(nèi)部搭建ERP,CRM等性質(zhì)系統(tǒng)的企業(yè)還是不多,很多的客戶管理需求只是簡單的管理層個人需求而已,而不是說對企業(yè)進(jìn)行系統(tǒng)分析,再對業(yè)務(wù)流程合理化或重組,制定管理業(yè)務(wù)標(biāo)準(zhǔn)等措施來把信息技術(shù)與先進(jìn)管理集合起來的大工程, 所以一方面要明確用戶需求的來源同優(yōu)先級別,雖然一般參與系統(tǒng)建立的決策人對業(yè)務(wù)流程都比較熟悉，但對細(xì)節(jié)上并不是很了解，一些特性就很少了解,對這些熟悉的還是實(shí)際前臺操作人員,所以在流程同功能模塊上聽取客戶管理層外,交互界面的處理一定要注意同終端用戶進(jìn)行溝通；另一方面,要多讓用戶做測試同培訓(xùn),讓用戶能在系統(tǒng)完善的過程中熟悉操作同流程,參與系統(tǒng)建立,畢竟接受新事物都有一個過程的,這樣當(dāng)正式使用時就不會產(chǎn)生抵觸或被迫的心理.

第三類的問題歸根結(jié)底就是人與人之間的溝通問題,各方面都有自己的想法同考慮. 有時候語言的交流不如用 DEMO來的有效果,一份初期的DEMO能讓雙方少走很多彎路,而且,通過 DEMO能確定下來很多文檔,省了很多功夫,又能讓客戶心中對軟件系統(tǒng)有個一個大致的概念.

最后說下客戶的后期要求,一般除非前期合約說定的很清晰明白,否則,只有妥協(xié),畢竟還沒有交貨收錢...,當(dāng)然客戶的意見也不能完全聽取,并且要適當(dāng)?shù)耐ㄟ^一些相關(guān)行業(yè)的實(shí)例來引導(dǎo)客戶的要求,但也要明白決權(quán)還是在客戶手中，你的期望不是他的期望,即使最后的軟件的質(zhì)量不會高,也許這也算是做軟件的一種悲哀吧.

轉(zhuǎn)載于:https://www.cnblogs.com/Augur/archive/2006/09/12/502590.html

總結(jié)

以上是生活随笔為你收集整理的需求变更的处理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。