【經驗分享，歡迎討論】專案管理中需求變更太頻繁，怎麼辦？

需求變更是大家永遠的痛點話題。我們不但不能阻止變化，還要擁抱變化，要做的僅僅是管理變化。我們做過許多銀行專案，他們系統間、各系統的模組間，牽連關係異常複雜。可以借鑑他們的需求管理方法。個人總結了下他們做需求管理的幾個思考維度：

l 從源頭減少變更——保證需求提出質量

許多需求之所以頻繁變更，是因為前期沒做好分析。所以考慮從源頭開始管理，儘量在需求提出時分析清楚來減少後期不 必要 的變更。為了提高需求提出質量，他們做了許多事情，包括：

1.  統一收集需求，設立專人受理。

需求方通常是前端業務人員，提需求不一定能以系統化角度來提， 讓他們按模組或技術標準來提就會對需求方提出更高要求。 目前需求方無法達到這個水準，就需要有專業人員來補齊這塊短板。因此他們會通過統一途徑（比如O A 系統、需求管理系統、專案管理系統等）來收集需求，然後由專業人員進行受理，對需求進行初步稽核和分發。通過這個角色，一是為業務和技術雙方搭建橋樑；二是起到隔離帶的效果，有統一對口人，避免需求方直接找開發人員。

這個角色可以是產品人員或其他對業務與系統都熟悉的人員，重要的是受理的過程，保證需求到達開發之前是經過分析的。

如果需求方依然越過這個角色直接找開發，需要從流程規範上做控制，比如告訴需求方只能通過產品人員來接收需求，否則將不被受理。

2.  總結需求提出規範，給需求方提供模板。

即便需求方無法識別影響的系統模組，但依然可以從業務角度把需求提清楚。比如設定需求模板，要求必須寫上需求的提出背景、應用場景、操作角色、應達到的預期結果等。

甚至一些銀行對需求做了精細的結構化管理，需求提出時通過識別業務型別、場景、條件等，通過系統工具自動識別影響的系統和模組甚至是需求工作量，將需求提出規範做得更加智慧化。但做到這個程度需要對歷史需求做大量梳理，更適用於業務穩定的這類需求，而不適用於創新業務類的需求。

同樣，如果無法做到自動識別涉及的模組，就只能人工替代，讓專業人員來識別。

3.  特殊情況，特殊處理。

雖然需要避免需求隨意提交到開發打亂開發節奏，但確實存在某些需求需要緊急處理。因此需要對需求定義優先順序或緊急程度。最好能明確定義，比如影響到前端業務無法進行的被定義最緊急需求，對於U I 優化等定義為不緊急需求。若不能明確定義，也可以人工分析，在受理時進行溝通確認。

l 在過程中管理變更——管控變更不要隨意發生，即使發生也能得到合理處理。

同樣為了有效管控，他們也想了很多辦法，比如：

1.  每次變更都需要經過審批流程並留痕。

2.  變更同樣要規範提出的資訊，並分析影響。每次的變更都相當於一條新需求來處理。

3.  變更需求必須通知到相關人，以便讓正在完成相關需求的人員都能及時同步到資訊。 其中可能涉及產品人員或專案經理重新評估需求影響，進行工作計劃調整，比如停止正在進行的相關工作按變更後的執行，還是將變更排到下一個開發週期，讓開發團隊遇到變更也能有條不紊的進行。

4.  不論新需求或變更，都儘量通過分解和全鏈路追蹤的方式。 在面對大需求時，需求分解是非常好的方法。需求分解後，每條小需求可以獨立狀態進行跟蹤。變更發生時產品人員或專案經理能馬上跟蹤到原始需求分解了哪些小需求，各個小需求都進行到了哪一步，如還未分析設計，或已開發完成在等待測試，以便工作計劃及時調整。

對於以上，都需要藉助系統工具進行管理，否則只靠人工和線下Excel表格是很難的，特別是這些業務資料間的複雜關係處理。我們接觸過的銀行客戶很多都用的易趨的管理軟體，看起來效果還不錯，希望對題主能有幫助。