「需求變更」是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。
對於如何應對需求變更，主要的思路有兩條：首先是從源頭做起，提高需求質量，減少變更的可能性；另乙個就是建立流程嚴格控制需求變更.
做任何變更之前，我們都要考慮後果(consequence)。由於需求在開發中所處的中心地位，一旦需求發生變化，影響面是很的。我們通過建立需求追蹤矩陣，來分析需求的衝擊面，即乙個需求如果變更，將導致哪些其他的需求，測試用例、設計、編碼進行變更。這個客觀的資訊將為專案經理提供乙個做出合理判斷的有力依據。
有效管理需求變更有幾個需要特別注意的環節：
1. 建立正式的申請和處理流程
雖然眾多專案管理人員對於變更可能帶來的巨大影響有深刻的理解，但令人不解的是我們常常看到這些變更的提出、討論和執行卻常常停留在口頭上。這樣做有兩個弊端：首先是時間一長，無論是當事人還是開發團隊的其它成員都說不清楚變更是因何發生以及結果怎麼樣了。顯然，這對於提高專案管理質量、改進開發過程是很不利的。其次是由於缺乏形式上的約束和對變更衝擊的定量化分析，變更會被非常隨意地提出、或被草率地執行，大大影響了專案的進展和開發質量。因此建立乙個正式的變更處理流程並真正得以實施非常重要。
2. 定量化的變更衝擊分析
變更作為乙個計畫外的風險因素對專案肯定存在衝擊，只是大小的差別。因此，如果能夠定量化地評估變更帶來的影響就能幫助開發團隊作出正確的應對決策。這就是變更管理中的衝擊分析環節。上面談到了，分析的基礎是追蹤矩陣，它記錄了專案管理要素之間的聯絡關係。從這些關聯關係中我們可以找到每乙個潛在會受到影響的要素，評估對其的影響，從而組合出變更對整個專案可能造成的衝擊。
從上面的例子可以看到，即使是加了乙個看似與其他關係不大的需求，也會造成一系列的潛在影響，更不用說是在需求眾多、關係複雜的大型應用系統開發專案中了。
3. 組成變更控制管理委員（ccb）
作為變更管理的乙個核心控制環節，變更控制委員會（簡稱ccb）起決策和管理作用。它通常由客戶代表和開發團隊代表共同組成，負責評估變更衝擊以及 決定是否要實施這樣的變更。這種綜合了需求方（客戶）和開發方（開發團隊）力量的委員會能夠較好地權衡變更代價，從而減少了單方面考慮變更所帶來的不利影響。
4. 不要忽視變更執行的管理
在實踐中很多開發團隊雖然組成了ccb並有一定的處理流程，卻往往忽視了對於變更執行的管理。而變更實施的好壞、完整性對於專案本身的影響同樣是巨大的。在這方面，根據衝擊分析和變更評審的結果，建立乙個變更任務列表並且追蹤它的執行是乙個很好的實踐。。
如何做好需求變更管理？ 需求變更流程規範
一 引言 由於目前公司內部對產品的需求變動都只是口頭或郵件中進行通知，並沒有進行內部評審和相關需求變動後的記錄，導致後續出的產品某些需求增加了，某些沒有進行增加。這樣就會導致測試得到的資訊不完整，以及後續產品的維護困難。在這裡書寫乙份規範說明書，希望能得到一些改善。二 目的 控制需求變化引起的開發 ...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
專案管理問題之需求變更
案例情景 該專案整個週期為2個月 有3 能測試，當第 3 能測試結束時也就是即將進入預發布階段時，需求提出方才把使用者反饋資訊給了我們，要求我們按使用者的要求去改。改動的地方涉及到頁面的樣式，文案，sql語句，校驗邏輯等，總共可能有 20個左右的檔案要被改動。我們建議只改頁面的樣式和文案，其他部分先...