qmchashi：如何應對軟件研發項目中頻繁的需求變更？

2020-03-18

對於(yu) 軟件研發項目管理，需求變更頻繁是一個(ge) 非常讓人頭痛也很無奈的問題，小到某個(ge) 文檔標題的改變，大到一個(ge) 新的產(chan) 品功能需求的提出……一旦需求發生變更，往往容易引起重估、返工，那時就不得不修改設計、重寫(xie) 代碼、修改測試用例、調整項目計劃等等。

任何需求變更的提出，幾乎都會(hui) 增加整個(ge) 研發項目成本，如果控製不好，還會(hui) 導致項目範圍蔓延、進度延遲、質量不過關(guan) 和成本嚴(yan) 重超支等諸多問題，甚至因過多的分歧、變更而半途而廢。麵對不斷的研發項目需求變更，我們(men) 應該怎麽(me) 辦？

研發項目需求變更產(chan) 生的原因

一般來說，軟件開發項目的流程是：需求分析--開發部門架構和開發係統—測試部門測試係統--用戶測試係統--係統上線。需求變更在任何時候都有可能產(chan) 生，產(chan) 生的原因通常來源於(yu) 內(nei) 外部，包括產(chan) 品經理、開發、用戶、公司高層級政策市場變化等。

雖然需求變更的表現形式千差萬(wan) 別，但細細追究起來無外乎以下幾種原因：範圍沒有圈定就開始細化、沒有指定需求的基線、沒有良好的軟件結構適應變化、需求定義(yi) 不明確、對需求的理解分歧、業(ye) 務需求改變、項目實現周期長等。

如何正確應對軟件開發需求變更？

需求變更的控製不應該隻是項目實施過程考慮的事情，而是要分布在整個(ge) 項目生命周期。為(wei) 了將項目變更的影響降低到最小，我們(men) 需要采用綜合變更控製方法，具體(ti) 可以從(cong) 以下幾個(ge) 方麵入手：

3. 在項目收尾的階段，針對項目中事先識別的風險和沒有預料到而發生的變更等風險的應對措施進行係統性分析總結，歸檔保存。

變更請求的提交及審批

項目團隊可通過qmchashi PM的變更管理模塊來處理事務、問題、缺陷報告、改進需求等溝通，每個(ge) 項目都有一個(ge) “變更請求”子頁麵，項目團隊成員或授權用戶都可在此頁麵中提交和此項目相關(guan) 的變更請求，負責人接收請求後可與(yu) 相關(guan) 人員進行溝通，完成“拒絕”、“接受”、“重新委派”等變更請求操作。

嚴(yan) 重性與(yu) 優(you) 先級別隊列

一個(ge) 變更請求的緊急程度可能會(hui) 隨著情況變化而變化，在qmchashi PM中，變更請求可以按照嚴(yan) 重性進行區分，可以排入不同的優(you) 先級別隊列，以便控製訪問權限，也可重新分配優(you) 先級或轉移變更請求。

追溯變更對項目的影響

qmchashi PM將項目計劃、費用和資源分配的變更記錄關(guan) 聯到指定的變更請求，幫助管理者跟蹤項目計劃和執行中的各種變更。係統的審計跟蹤功能還可以自動實時追蹤和記錄所有提交者和評審者的行為(wei) ，研發項目人員在可以計劃與(yu) 執行頁麵清晰地看到每個(ge) 需求變更對哪些項目活動產(chan) 生影響以及如何產(chan) 生影響，能幫助項目人員作出更加有效和準確的決(jue) 策與(yu) 衡量。

寫(xie) 在最後