變更控制的目的并不是控制變更的發(fā)生，而是對變更進行管理，確保變更有序進行。對于軟件開發(fā)項目來說，發(fā)生變更的環(huán)節(jié)比較多，因此變更控制顯得格外重要。

　　IT項目中引起變更的因素有兩個：一是來自外部的變更要求，如客戶要求修改工作范圍和需求等；二是開發(fā)過程內部的變更要求，如為解決測試中發(fā)現的一些錯誤而修改源碼甚至設計。比較而言，最難處理的是來自外部的需求變更，因為IT項目需求變更的概率大，引發(fā)的工作量也大（特別是到項目的后期）。 　　變更控制不能僅在過程中靠流程控制，有效的方法是在事前明確定義。事前控制的一種方法是在項目開始前明確定義，否則"變化"也無從談起。工作范圍（以前章節(jié)談過）；另一種方法是評審，特別是對需求進行評審，這往往是項目成敗的關鍵。需求評審的目的不僅是"確認"，更重要的是找出不正確的地方并進行修改，使其盡量接近"真實"需求。另外，需求通過正式評審后應作為重要基線，從此之后即開始對需求變更進行控制。 雖然可以事前定義好變更控制流程，但在各種壓力下真正"控制"起來其實非常困難。

　　下面給大家分析一個變更失控的項目案例： 王先生剛出任項目經理，并承接了一個中型軟件項目。上任時公司高層再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，但進入到后期，客戶頻繁的需求變更帶來很多額外工作。王先生動員大家加班，保持了項目的正常進度，客戶相當滿意。 　　但需求變更卻越來越多。為了節(jié)省時間，客戶的業(yè)務人員不再向王先生申請變更，而是直接找程序員商量。程序員疲于應付，往往直接改程序而不做任何記錄，很多相關文檔也忘記修改。很快王先生就發(fā)現：需求、設計和代碼無法保持一致，甚至沒有人能說清楚現在系統(tǒng)“到底改成什么樣了”。版本管理也出現了混亂，很多人違反配置管理規(guī)定，直接在測試環(huán)境中修改和編譯程序。但在進度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題，客戶已經明確表示“失去了耐心”。

　　而這還只是噩夢的開始。一個程序員未經許可擅自修改了核心模塊，造成系統(tǒng)運行異常緩慢，大量應用程序超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的項目管理水平”。更糟糕的是，因為擔心系統(tǒng)中還隱含著其他類似的錯誤，客戶高層對項目的質量也疑慮重重。 　　隨后發(fā)生的事情讓王先生更加為難：客戶的兩個負責人對界面風格的看法不一致，并為此發(fā)生了激烈爭執(zhí)。王先生知道如果發(fā)表意見可能會得罪其中一方，于是保持了沉默。最終客戶決定調整所有界面，王先生只好立刻動員大家抓緊時間修改?？珊髞懋斅犝f因修改界面而造成了項目一周的延誤后，客戶方原來發(fā)生爭執(zhí)的兩人這次卻非常一致，同時氣憤地質問王先生，為什么你不早點告訴我們要延期！早知這樣才不會讓你改呢！"王先生委屈極了，疑惑自己到底錯在哪里了。

　　從上面的案例中可以看到各種變更失控的現象和造成的后果，王先生主要犯了幾個錯誤：
　　1) 沒有明確的授權。事先應該明確客戶方有權提出變更申請的人員和實施方有權受理變更的人員，并要控制雙方人數。這樣做才可以對變更有整體的控制。絕不能進行"私下交易"，而沒有人能完整地知道到底改了些什么。另外，授權雙方接口人的好處是可以屏蔽客戶內部的矛盾，如果只有一個接口人，內部尚未達成一致時變更是無法提出來的。從實際經驗看，授權可以顯著減少變更，特別是那些因內部看法不同而導致的反復變更。

　　2) 對變更沒有進行必要的審核。并不是所有的變更都要修改，也不是所有變更都要立刻修改，審核的目的就是為了決定是否需要修改和什么時候修改。比如案例中提到的界面風格問題，就可以

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

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