最近一直在想需求變動控制的事,資料也查了很多,但是查來查去,內容都差很少,無非是需求變動是必定要控制的,而且要通過申請、審批、執行、確認等流程, 幾乎全部的資料給出的都是這樣的內容,更多的,除了後面的流程以外,甚至連爲何要作控制都沒說明。下面說說個人理解。由於所管理的項目幾乎都是以合同爲 基礎的外部客戶項目,因此討論內容僅限於此類項目中,由客戶提出的需求變動的管理。測試
爲何要作需求變動的管理?spa
進行需求變動管理的主要緣由有兩個,一個是防止範圍蔓延引發的進度、成本、質量上,甚至嚴重時致使項目全面失敗的問題;另外一個是爲之後留下籌碼,之後要求 追加費用也好,或者讓客戶看到咱們送給他們的人情也好,總之是爲了使之後與客戶相關的工做更順暢。除了這兩個緣由以外,固然還有一些不是特別重要的緣由, 好比使需求、設計、開發、測試之間對變動的理解一直等等。.net
需求變動管理的流程設計
需求變動管理的流程,在絕大多數的資料中,第一步都是提出變動申請。事實上,在此以前,還有至少一件事要作,就是與客戶一塊兒,約定變動管理的流程,最好在 合同中約定,至少也要在啓動會上約定。而變動申請的提出,也應該按照約定的流程來,不是由客戶的任何一個角色直接提給項目組中的任何角色,而是客戶處提出 的全部需求變動,都歸總到客戶處的需求變動負責人處,由負責人判斷哪些須要做爲需求變動提出,哪些不須要提出,須要提出的需求變動,由負責人提交給項目經 理。blog
項目經理收到需求變動申請以後,要作的第一件事,不是審批,而是詳細瞭解需求變動提出的來龍去脈和客戶想經過需求變動解決什麼問題,瞭解清楚這些以後,首 先儘量尋找系統外解決問題的辦法,若實在找不到,或者系統外解決辦法可行性過低時,再進行變動工做量的評估和影響的分析,分析完以後,才能進行變動的審 批。在全部的審批人中,銷售人員起到很重要的做用,由於銷售要給出變動所需費用的來源,並要給出承諾,不然變動沒辦法繼續。其餘審批人則根據本身的角色和 職責進行審批便可。開發
審批完成以後,是執行環節。對絕大多數的變動,均可以不用立刻執行變動動做,能夠幾個變動做爲一批一塊兒執行,一方面能夠下降頻繁變動對項目工做的影響,另外一方面對一些客戶一時興起變過來過不久又變回去的變動能夠起到攔截做用。原型
再以後是確認,需求變動以後的原型,須要在修改完以後就確認,而最終變動結果,則在系統驗收時,統一確認。博客
此博客來自:http://blog.csdn.net/violet200211/article/details/8612189io
雖然針對需求是如何變動的沒有說具體的流程,配置管理是怎麼管理的,可是以爲文章只是給出一個大題的思路很是好。基礎