需求變更管理

標籤：style   blog   http   strong   io   art   問題   ar   

  最近一直在想需求變更控制的事，資料也查了不少，可是查來查去，內容都差不多，無非是需求變更是一定要控制的，並且要經過申請、審批、執行、確認等流程， 幾乎所有的資料給出的都是這樣的內容，更多的，除了後面的流程之外，甚至連為什麼要做控制都沒說明。下面說說我的理解。因為所管理的項目幾乎都是以合約為 基礎的外部客戶項目，所以討論內容僅限於此類項目中，由客戶提出的需求變更的管理。

        為什麼要做需求變更的管理？

        進行需求變更管理的主要原因有兩個，一個是防止範圍蔓延引起的進度、成本、品質上，甚至嚴重時導致項目全面失敗的問題；另一個是為以後留下籌碼，以後要求 追加費用也好，或者讓客戶看到我們送給他們的人情也好，總之是為了使以後與客戶相關的工作更順暢。除了這兩個原因之外，當然還有一些不是特別重要的原因， 比如使需求、設計、開發、測試之間對變更的理解一直等等。

        需求變更管理的流程

        需求變更管理的流程，在絕大多數的資料中，第一步都是提出變更申請。事實上，在此之前，還有至少一件事要做，就是與客戶一起，約定變更管理的流程，最好在 合約中約定，至少也要在啟動會上約定。而變更申請的提出，也應該按照約定的流程來，不是由客戶的任何一個角色直接提給項目組中的任何角色，而是客戶處提出 的所有需求變更，都歸總到客戶處的需求變更負責人處，由負責人判斷哪些需要作為需求變更提出，哪些不需要提出，需要提出的需求變更，由負責人提交給項目經 理。

        專案經理收到需求變更申請之後，要做的第一件事，不是審批，而是詳細瞭解需求變更提出的前因後果和客戶想通過需求變更解決什麼問題，瞭解清楚這些之後，首 先儘可能尋找系統外解決問題的辦法，若實在找不到，或者系統外解決辦法可行性太低時，再進行變更工作量的評估和影響的分析，分析完之後，才能進行變更的審 批。在所有的審批人中，銷售人員起到很重要的作用，因為銷售要給出變更所需費用的來源，並要給出承諾，否則變更沒辦法繼續。其他審批人則根據自己的角色和 職責進行審批即可。

        審批完成之後，是執行環節。對絕大多數的變更，都可以不用馬上執行變更動作，可以幾個變更作為一批一起執行，一方面可以降低頻繁變更對項目工作的影響，另一方面對一些客戶一時興起變過來過不久又變回去的變更可以起到攔截作用。

        再之後是確認，需求變更之後的原型，需要在修改完之後就確認，而最終變更結果，則在系統驗收時，統一確認。

 

此部落格來自：http://blog.csdn.net/violet200211/article/details/8612189

雖然針對需求是如何變更的沒有說具體的流程，組態管理是怎麼管理的，但是覺得文章只是給出一個大題的思路非常好。