專案經理該如何面對頻繁的需求變更?

cornerstone發表於2020-04-16
對於軟體研發專案管理,需求變更頻繁是一個非常讓人頭痛也很無奈的問題,小到某個文件標題的改變,大到一個新的產品功能需求的提出……

一旦需求發生變更,往往容易引起重估、返工,那時就不得不修改設計、重寫程式碼、修改測試用例、調整專案計劃等等。

任何需求變更的提出,幾乎都會增加整個研發專案成本,如果控制不好,還會導致專案範圍蔓延、進度延遲、質量不過關和成本嚴重超支等諸多問題,甚至因過多的分歧、變更而半途而廢。

面對不斷的研發專案需求變更,我們應該怎麼辦?

首先,要認識到一點就是研發專案中的需求是不可能被完全消除和避免的。
我們所能做的,就是找到需求變更產生的原因,針對性採取行之有效的措施,將需求變更給研發專案帶來的損失減到最小。

image.png

一、研發專案需求變更的原因

一般來說,軟體開發專案的流程是:需求分析—開發部門架構和開發系統—測試部門測試系統—使用者測試系統—系統上線。

需求變更在任何時候都有可能產生,產生的原因通常來源於內外部,包括產品經理、開發、使用者、公司高層級政策市場變化等。

雖然需求變更的表現形式千差萬別,但細細追究起來無外乎以下這些原因:

範圍沒有圈定就開始細化、沒有指定需求的基線、沒有良好的軟體結構適應變化、需求定義不明確、對需求的理解分歧、業務需求改變、專案實現週期長等。

二、如何正確應對研發需求變更

需求變更的控制不應該只是專案實施過程考慮的事情,而是要分佈在整個專案生命週期。
為了將專案變更的影響降低到最小,我們需要採用綜合變更控制方法,具體可以從以下幾個方面入手:
  • 在專案的啟動階段,做好需求分析,詳細清晰定義基準檔案的範圍;
  • 在專案的實施階段,分析變更請求,對需求進行控制,減少需求的來源,過濾不合理的需求。同時,進行文件化管理,做到有備可查,有據可依;
  • 在專案收尾的階段,針對專案中事先識別的風險和沒有預料到而發生的變更等風險的應對措施進行系統性分析總結,歸檔儲存。
需求變更既然不可避免,那麼就必須有一套規範的處理流程,最好透過合適的研發專案管理工具進行需求變更的規範化管理。

在這裡推薦 CORNERSTONE研發專案管理工具,一體化實時的全域性檢視,可幫助管理者作出有效的決策和衡量是否每個需求變更都有意義和可負擔,有效地管理需求的評審與驗收來促進需求溝通。

image.png


三、變更請求的提交及審批

專案團隊可透過 CORNERSTONE的需求模組來處理事務、問題、缺陷報告、改進需求等溝通。

每個專案都有一個“變更請求”子頁面,專案團隊成員或授權使用者都可在此頁面中提交和此專案相關的變更請
求,負責人接收請求後可與相關人員進行溝通,完成“拒絕”、“接受”、“重新委派”等變更請求操作。

四、嚴重性與優先順序別佇列

一個變更請求的緊急程度可能會隨著情況變化而變化。

CORNERSTONE,變更請求可以按照嚴重性進行區分,可以排入不同的優先順序別佇列,以便控制訪問許可權,也可重新分配優先順序或轉移變更請求。

五、追溯變更對專案的影響

CORNERSTONE將專案計劃、費用和資源分配的變更記錄關聯到指定的變更請求,幫助管理者跟蹤專案計劃和執行中的各種變更。

系統的審計跟蹤功能還可以自動實時追蹤和記錄所有提交者和評審者的行為。

研發專案人員在可以計劃與執行頁面清晰地看到每個需求變更對哪些專案活動產生影響以及如何產生影響,能幫助專案人員作出更加有效和準確的決策與衡量。

一個軟體研發專案從啟動到收尾的整個生命週期都會經歷各種變更,為變更做好準備並有效地管理變更的能力是專案成敗的關鍵。

CORNERSTONE研發專案管理系統為專案團隊打造一個透明的溝通與執行平臺,幫助專案人員跟蹤需求變更從提出到完成的整個任務生命週期的所有狀態,更好地把控專案執行,提高專案成功率。 現在申請20人以下團隊即可免費使用。

aeef399ffa8046109e455da2e8c34dc4.png


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69933591/viewspace-2686539/,如需轉載,請註明出處,否則將追究法律責任。

相關文章