客戶今天要求變更需求，加某某功能，“這個應該不難吧，某某公司的產品都有這個功能的。”客戶的需求一直在變，煩惱。。。
開始是需求不明確，客戶都不知道要做成什么樣，只有一個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的......客戶方和開發方在一起（ 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、需求功能點列表的書面確認?，F在簽的只是非常粗略的大體需求，定性而沒有定量，以后扯皮發生的可能性非常大；
4、適當時候應該拒絕客戶的要求。雖然用戶有眾多的理由，比如他認為改動不大，競爭對手已經擁有該功能，或是新的業務需要，但如果評估后的結果是沒有必要，或不合理，或優先級不高，或風險大于必要，則堅定的拒絕。另外一種變通的方法是，根據優先級重要性有條件的答應，比如放在下一次版本之后。
5、需求Scope的管理，不僅要明確做什么，而且要明確不做什么。什么是我們負責的，什么不是我們應該負責和提供的。
另外在需求變更管理中，和客戶有效的溝通、協調和教育非常重要。說的好點，就是“要講究溝通的藝術”，“多引導客戶”；說得俗點，就是“擺平客戶”。如果能夠對客戶進行很好的客戶教育，很多時候客戶是可以理解開發過程中的困難，從而達到妥協或折中。比如客戶理解了項目后期進度緊張，技術架構難以大改，就會在資源、進度、功能上做一些折中的選擇，比如把功能分主要功能先實現，次要功能后實現；核心業務保穩定，次要業務不能犧牲核心業務的穩定性等等。反之，如果沒有和客戶有效的溝通、協調和教育，則會雙方各執一詞，搞業務的只講業務、流程和功能，不考慮技術可行性，不考慮資源和時間表；搞技術的只講技術，沒有傾聽客戶的正當的商業需求，不能滿足客戶利益的最大化，這樣雙方就很難達成雙贏的結果。所以，有效的溝通是軟件項目成功的關鍵。