最近一直在想需求變更控制的事，資料也查了不少，可是查來查去，內容都差不多，無非是需求變更是一定要控制的，并且要經過申請、審批、執行、確認等流程，幾乎所有的資料給出的都是這樣的內容，更多的，除了后面的流程之外，甚至連為什么要做控制都沒說明。下面說說我的理解。因為所管理的項目幾乎都是以合同為基礎的外部客戶項目，所以討論內容僅限于此類項目中，由客戶提出的需求變更的管理。
為什么要做需求變更的管理？
進行需求變更管理的主要原因有兩個，一個是防止范圍蔓延引起的進度、成本、質量上，甚至嚴重時導致項目全面失敗的問題；另一個是為以后留下籌碼，以后要求追加費用也好，或者讓客戶看到我們送給他們的人情也好，總之是為了使以后與客戶相關的工作更順暢。除了這兩個原因之外，當然還有一些不是特別重要的原因，比如使需求、設計、開發、測試之間對變更的理解一直等等。
需求變更管理的流程
需求變更管理的流程，在絕大多數的資料中，第一步都是提出變更申請。事實上，在此之前，還有至少一件事要做，就是與客戶一起，約定變更管理的流程，最好在合同中約定，至少也要在啟動會上約定。而變更申請的提出，也應該按照約定的流程來，不是由客戶的任何一個角色直接提給項目組中的任何角色，而是客戶處提出的所有需求變更，都歸總到客戶處的需求變更負責人處，由負責人判斷哪些需要作為需求變更提出，哪些不需要提出，需要提出的需求變更，由負責人提交給項目經理。
項目經理收到需求變更申請之后，要做的第一件事，不是審批，而是詳細了解需求變更提出的前因后果和客戶想通過需求變更解決什么問題，了解清楚這些之后，首先盡可能尋找系統外解決問題的辦法，若實在找不到，或者系統外解決辦法可行性太低時，再進行變更工作量的評估和影響的分析，分析完之后，才能進行變更的審批。在所有的審批人中，銷售人員起到很重要的作用，因為銷售要給出變更所需費用的來源，并要給出承諾，否則變更沒辦法繼續。其他審批人則根據自己的角色和職責進行審批即可。
審批完成之后，是執行環節。對絕大多數的變更，都可以不用馬上執行變更動作，可以幾個變更作為一批一起執行，一方面可以降低頻繁變更對項目工作的影響，另一方面對一些客戶一時興起變過來過不久又變回去的變更可以起到攔截作用。
再之后是確認，需求變更之后的原型，需要在修改完之后就確認，而最終變更結果，則在系統驗收時，統一確認。