客戶今天要求變更需求，加某某功能，「這個應該不難吧，某某公司的產品都有這個功能的。」客戶的需求一直在變，煩惱。。。
開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。。。客戶方和開發方在一起( workshop) 還好，如果分開在兩地就更糟糕。。。
永遠不變的就是變化，這個大家都知道，但關鍵是如何合理的控制需求變更？
我以前做的上百人一年多乙個的大專案，完全按照
cmmi level3
規範來控制需求變更的。起初有雙方簽字的經過評審的需求基線，以後需求變更的時候有需求變更委員會（
ccb）或專門負責的角色（通常由客戶方需求人員來收集和評估最初需求並提交給qa，
qa牽頭需求變更流程）來處理需求變更，具體做法是：
1.先是客戶或專案組成員提出的需求申請，填寫《變更申請單》並提交給專案經理。
2.專案經理組織專案相關人員對需求變更進行評估和調研，然後組織
需求變更評審。
3.如果同意變更則由
ccb授權配置管理員檢出配置項由專案組成員對相關的文件（使用者需求說明書、需求規格說明書）進行修改，修改後評審（同時
填寫《變更管理記錄表》）通過後由高層經理審批，然後提交使用者確認，最後納入配置庫，更新《需求追蹤矩陣》，確保需求和工作產品的一致性；
4.如果不同意變
更，則專案經理、部門經理與客戶共同協商，協商後同意變更，則對相關的文件進行修改。協商後依然不統一，則需求變更結束。
5.所有的需求變更都需要總經理理進
行審批。需求變更的影響：利用《需求跟蹤矩陣》對變更影響進行評估；估計對專案引數的影響
—規模、工作量、進度影響；超出閥值（整個專案進度的
10%- 15%
，里程碑
30%）的，應提交高層評審
/批准。
6.妥善儲存變更產生的相關文件。
現在公司做的專案規範較小，完全按照
cmmi
的規範來有點多餘，所以我們基本上類似於敏捷開發的模式。敏捷程式設計是擁抱變化，持續重構和改進，迭代開發，頻繁交付。在需求變更管理上我們還沒有一套完整的合適的流程，具體做法是：
1.客戶提出新需求;
2.開發人員或專案經理評估後答應了;
3.繼續開發，時間表按照重新評估後的進行;
4.
基本上很少拒絕客戶；一方面是為了維護客戶關係，另一方面對自己
team
的開發能力很自信
; 結果是上頭答應了客戶，下頭的只能加班加點趕工。
另外還有一些控制需求的做法：
1.
專案前期會首先快速開發乙個產品原型(prototype)給客戶，有介面的先用visio畫個介面，以驗證業務規則、業務流程和大概gui等。另外，產品原型也有助於進一步挖掘使用者的需求。
2.
會粗略的列出大體的需求並簽字
3.
頻繁交付給客戶，短週期的交付可工作的產品，以印證需求與實現是否一致，同時兼做客戶教育工作。
問題是如果需求變更無休止，則需求變更幾乎就不可控，專案開發也無休止。所以我覺得我們公司在需求管理上還缺乏：
1.
需求基線管理，經過評審的雙方確認簽字的需求基線。以後如果要超出或修改需求基線，則必須有專門的人員對此提出異議，由ccb審核後方可修改；
2.
專門的需求控制負責人。現在基本上是技術人員或是專案經理收到客戶需求變更，然後自己評估下就答應了。缺乏專門的需求控制負責人，因而沒有需求評審，沒有一套專門的嚴格可控的需求變更流程。
3.
需求功能點列表的書面確認。現在籤的只是非常粗略的大體需求，定性而沒有定量，以後扯皮發生的可能性非常大；
4.
適當時候應該拒絕客戶的要求。雖然使用者有眾多的理由，比如他認為改動不大，競爭對手已經擁有該功能，或是新的業務需要，但如果評估後的結果是沒有必要，或不合理，或優先順序不高，或風險大於必要，則堅定的拒絕。另外一種變通的方法是，根據優先順序重要性有條件的答應，比如放在下一次版本之後。
5. 需求scope的管理，不僅要明確做什麼，而且要明確不做什麼。什麼是我們負責的，什麼不是我們應該負責和提供的。
另外在需求變更管理中，和客戶有效的溝通、協調和教育非常重要。說的好點，就是「要講究溝通的藝術」，「多引導客戶」；說得俗點，就是「擺平客戶」。如果能夠對客戶進行很好的客戶教育，很多時候客戶是可以理解開發過程中的困難，從而達到妥協或折中。比如客戶理解了專案後期進度緊張，技術架構難以大改，就會在資源、進度、功能上做一些折中的選擇，比如把功能分主要功能先實現，次要功能後實現；核心業務保穩定，次要業務不能犧牲核心業務的穩定性等等。反之，如果沒有和客戶有效的溝通、協調和教育，則會雙方各執一詞，搞業務的只講業務、流程和功能，不考慮技術可行性，不考慮資源和時間表；搞技術的只講技術，沒有傾聽客戶的正當的商業需求，不能滿足客戶利益的最大化，這樣雙方就很難達成雙贏的結果。所以，有效的溝通是軟體專案成功的關鍵。
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的.客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕.永...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...