需求變更是一個無法避免的事實，它會導致軟體開發過程中產生成本增加、質量不過關等風險，而且越往後的變更產生的風險將越大。在專案實施過程中，專案經理所要面對的將是一系列和多方面的考驗。經常發生的、也很令人頭疼的恐怕就是需求的變更了。因此解決問題的方法應該以控制風險為出發點， 可能產生越大風險的事情就要越早解決。

需求變更的表現形式及原因

需求變更的表現形式是多方面的，如老闆臨時改變想法、專案預算增加或減少、客戶對功能的需求改變等。在IT專案中，變更可能來自方案服務商、客戶或產品供應商等，也可能來源於專案組內部。雖然需求變更的表現形式千差萬別，但究其根本不外乎以下幾種原因：

1.範圍沒有圈定就開始細化

細化工作是由需求分析人員完成的，一般是根據使用者提出的描述性的、總結性的短短几句話去細化的，提取其中的一個個功能(用例比較專業點)，並給出描述(正常執行時的描述和意外發生時的描述)。當細化到一定程度後並開始系統設計時，範圍會發生變化，那細節用例的描述可能就有很多要改動。如原來是手工添入的資料，要改成根據XX計算出來，而原來的一個屬性的描述要變成描述一個實體等。

2.沒有指定需求的基線

需求的基線是指是否容許需求變更的分界線。隨著專案的進展，需求的基線也在變化。是否容許變更的依據是合同以及對成本的影響，比如軟體整體結構已經設計出來是不容許改變需求範圍的，因為整體結構會對整個專案的進度和成本有初步預算。隨著專案的進展，基線將越定越高(容許的變更將越少)，其過程如下：變更請求->比較基線->變更實現。

3.沒有良好的軟體結構適應變化

元件式的軟體結構就是提供了快速適應需求變化的體系結構，資料層封裝了資料訪問邏輯，業務層封裝了業務邏輯，表示層展現使用者表示邏輯。但適應變化必須遵循一些鬆耦合原則，各層之間還是存在一些聯絡的，設計要力求減少會對介面人口引數產生變化。

如果業務邏輯封裝好了，則表示層介面上的一些排列或減少資訊的要求是很容易適應的。如果介面定義得合理，那麼即使業務流程有變化，也能夠快速適應變化。因此，在成本影響的容許範圍內可以降低需求的基線，提高客戶的滿意度。

4.需求變更的控制策略

按照現代專案管理的概念，一個專案的生命週期分為啟動、實施、收尾三個過程。需求變更的控制不應該只是專案實施過程考慮的事情，而是要分佈在整個專案生命週期的全過程。為了將專案變更的影響降低到最小，就需要採用綜合變更控制方法。

綜合變更控制主要內容有找出影響專案變更的因素、判斷專案變更範圍是否已經發生等。

進行綜合變更控制的主要依據是專案計劃、變更請求和提供了專案執行狀況資訊的績效報告。為保證專案變更的規範和有效實施，通常專案實施組織會有一個變更控制系統。變更控制系統是一個正式和文件化的程式，它定義了專案績效如何被監控和評估，並且包含了哪種級別的專案檔案可以被變更，包括檔案處理、系統跟蹤、過程程式、變更審批許可權控制等。綜合變更控制的結果主要有更新的專案計劃、糾正措施和經驗總結。

5.專案啟動階段的變更預防

對於任何專案，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從專案啟動的需求分析階段就開始了。對一個需求分析做得很好的專案來說，基準檔案定義的範圍越詳細清晰，使用者跟專案經理扯皮的幌子就越少。

如果需求沒做好，基準檔案裡的範圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文件清晰且又有客戶簽字，那麼後期客戶提出的變更就超出了合同範圍，需要另外收費。

這個時候千萬不能手軟，這並非要刻意賺取客戶的錢財，而是不能讓客戶養成經常變更的習慣，否則後患無窮。相對於需求來說，什麼WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。

6.客觀面對需求變更

需求一定會變化，我們也不得不面對這種情況，那麼用什麼辦法改善這種現狀呢?下面我提幾點建議。

(1)加強人員培訓

從客觀方面可以採取的措施來說，首先是加強對需求分析人員的培訓，儘可能增強軟體系統、行業的背景知識，提高與客戶的溝通能力，增強服務意識和責任感， 因為將要開發的系統直接建立在需求分析的基礎上;同時規範需求分析人員和客戶溝通的方式，以及規範需求說明的格式，如果可能的話，儘量採取使用者可以理解的圖例來對需求進行標準、規範的描述，保證雙方對需求達到共同的認識。

(2)加強文件管理

需求文件是相當重要的，可是在做文件時大家普遍流於形式，文件也有，格式也正確，但沒有人關心文件的真正內容是否正確，格式是否真的合理，是否實用，很多情況下是在幾天時間裡趕出來或補上去的。

結果往往是在需要文件時，文件找到了，完全符合格式的要求，可是在裡面能找到的線索是有限的，結果還要花很長時間查詢資料表結構、甚至檢視資料表的內容，詢問當時的開發人員，才分析到所要的關係。這種情況在設計文件裡也存在，所以不管是開發人員、還是專案管理人員都要注意文件的有效性和有用性問題，甚至對文件的格式進行一下合理性檢查。

(3)專案實施階段的變更控制

成功專案和失敗專案的區別就在於專案的整個過程是否是可控的。專案經理應該樹立一個理念—“需求變更是必然的、可控的、有益的”。專案實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準檔案。

能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。許多專案經理不注重經驗教訓總結和積累， 即使在專案運作過程中碰得頭破血流，也只是抱怨運氣、環境和團隊配合不好，很少系統地分析總結，或者不知道如何分析總結，以至於同樣的問題反覆出現。

事實上，專案總結工作應作為現有專案或將來專案持續改進工作的一項重要內容，同時也可以作為對專案合同、設計方案內容與目標的確認和驗證。專案總結工作包括專案中事先識別的風險和沒有預料到而發生的變更等風險的應對措施的分析和總結，也包括專案中發生的變更和專案中發生問題的分析統計的總結。

需求變更既然不可避免，那麼就必須有一套規範的處理流程。對於需求變更的處理流程應該分以下步驟：提出變更->變更評估->實施變更。

CMM提出“分配需求的變更被複審，並加入到軟體專案中來”，其關鍵是在需求發生變更時，沒有必要馬上把這些變更付諸於軟體開發工作之中。

實際上，堅持把需求變更付諸開發努力，企業就會形成一種混亂且不穩定的氛圍，進而嚴重破壞專案的控制和管理。需求管理關鍵過程試圖通過把分配需求的變更囤積到可管理的組中，等到開發工作允許的時候再引入相應的方法，避免產生這種混亂的氛圍。結果，需求管理建立了一個隔絕開發工作與所有真實的、潛在無序的、來自於客戶的變更。

打破模糊的、曖昧的、沒有文件化的需求是一種偉大的挑戰，但是制訂堅持遵守的承諾並實踐它，則是個更加巨大的挑戰。

7.控制需求漸變需要注意的問題

◆需求的變更要經過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。

◆小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不願意為小的需求變更去執行正規的需求管理過程， 認為降低了開發效率，浪費了時間。但正是由於這種觀念才使需求逐漸變為不可控，最終導致專案的失敗。

◆精確的需求與範圍定義並不會阻止需求的變更。並非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恆的，並非需求寫細了，它就不會變化了。

◆注意溝通的技巧。實際情況是使用者、開發者都認識到了上面的幾點問題，但是由於需求的變更可能來自客戶方，也可能來自開發方，因此，作為需求管理者，專案經理需要採用各種溝通技巧來使專案的各方各得其所。

◆ 需求一定要與投入有聯絡，如果需求變更的成本由開發方來承擔，則專案需求的變更就成為必然了。所以，在專案的開始，無論是開發方還是出資方都要明確這一條：需求變，軟體開發的投入也要變。