與我們的不同。第二，是開發(fā)者對需求的理解偏差。有可能是由于缺乏知識，開發(fā)者對需求理解錯了；還可能是開發(fā)團隊內(nèi)部造成的偏差，比如需求調(diào)研人員往往同時做好幾個項目，在調(diào)研完成后便不在開發(fā)團隊中，這樣偏差便在所難免。還有就是內(nèi)部溝通、人員更替造成的偏差。因此，在這樣一個三極世界，需求變更是必然的。
　?。?）合同簽訂馬虎，沒有真正明白客戶需求
　　當我以合同上沒有規(guī)定的需求不予開發(fā)時，客戶搬出銷售人員的承諾這一招，更讓我?guī)缀跬卵?。銷售人員在簽訂合同時缺乏對客戶需求的認真對待，導致需求描述不清，為開發(fā)帶來了許多困惑和后患。例如，銷售人員有時為使客戶能夠快速地簽訂合同，往往草率決定和片面同意客戶提出的需求。當客戶提出新的需求時，往往是銷售人員一看“應該”只是一個小小的修改，沒有太大的影響，所以直接答應能變更。
　　該問題的關(guān)鍵是合同簽署得太爛，沒有把需求明確再簽合同，而且也沒有把需求變更的流程寫入合同。如果在簽合同前就把客戶需求弄清楚，后期就根本不需要頻繁地變更需求。簽訂合同時明確定義開發(fā)需求的范圍，可以為以后各項開發(fā)工作的開展奠定好的基礎。
需求變更為何沒完沒了？
    在軟件開發(fā)中，最常抱怨的是這樣一個問題：客戶為什么總是反反復復？造成需求變更沒完沒了的原因，可以是這樣幾個方面存在問題。
　?。?）沒有明確的需求變更流程
　　沒有明確的需求變更管理流程，就會使需求變更變得泛濫，在這一點上我嘗盡了苦頭。并不是所有的變更都要修改，也不是所有變更都要立刻修改，明確需求變更管理流程的目的是為了決定什么類型的變更需要修改和什么時候修改。比如單純的界面風格問題，就可以先不修改，或者規(guī)劃一下修改的時間待到以后進行優(yōu)化。另外，對于核心功能的修改沒有嚴格把關(guān)流程，有些小需求看起來工作量不大，但是哪些銷售人員或者客戶沒有考慮到的細節(jié)問題實際上需要花費開發(fā)人員相當長的時間去完成，從而是撿了芝麻掉了西瓜，得不償失，使開發(fā)進度失控和資源浪費。
　?。?）沒有讓客戶知道需求變更的代價
　　對變更的影響沒有進行成本評估是需求變更泛濫的根本原因，這是我從單純的技術(shù)人員轉(zhuǎn)變到統(tǒng)籌兼顧成本管理的轉(zhuǎn)變點之一，當然為了這一點我也付出了血與淚，為此飽受公司領(lǐng)導和客戶的重重抱怨和責備。變更都是有代價的，應該要評估變更的代價和對項目的影響，要讓客戶了解需求變更的后果。如果客戶不知道需求變更付出的代價，對開發(fā)人員的辛苦就會難以體會。在評估代價（包括成本、時間等多方面）過程中，可以請客戶一起做判斷：“我可以修改，但您能接受后果嗎？”
如何有效控制需求變更？
　　需求變更對軟件開發(fā)項目成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發(fā)生，而是對變更進行管理，確保變更有序進行。
　?。?）明確合同約束，建立需求基線
　　需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與客戶簽訂合同時，可以增加一些相關(guān)條款，如限定客戶提出需求變更的時間，規(guī)定何種情況的變更可以接受、拒絕或部分接受，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更管理流程。雖然軟件開發(fā)合同很難在簽訂之初就能夠精確定義每項需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。
　　明確和樹立需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評審后（客戶參與評審），建立第一個需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線，做到小需求可以變更，但大方向要力保不頻繁變更。例如，對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理。
　?。?）建立變更

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html