原文鏈接：http://www.51testing.com/?103489/action_viewspace_itemid_70804.html

之前一個朋友問起我，說做了那么多年開發，談談有些項目為何失敗。朋友說項目失敗很大的原因是在合同問題，合同沒有很好的列出項目范圍。其實，合同的范圍只是一般的范圍，詳細內容應該不屬于合同的一部分。所以我覺得項目最大的問題還是需求沒做好。需求沒有做好，主要表現在以下幾個方面：

一、需求采集與分析

  1、需求采集分析時，沒有從完整的業務流程出發，容易關注主要業務需求，而造成次要業務需求塊的遺漏。

   之前檢查了我們公司一個重要項目的需求做得咋樣，光看需求提問單，就發現大部分問題是關于功能需求的。而問起業務需求時，他們說都很清楚了，但問起業務上細節處理時，大家都恍然大悟：“哦，這里需要再問下客戶...”。

  2、開發人員除了關注采集功能需求、外部接口需求、性能需求和一般的標準需求外，往往容易忽略系統領域的背景、操作環境需求、用戶特殊需求（例如用戶熟練使用的工具與方法）等。

二、需求定義與確認

   需求規格說明書是將人們思想中的概念和目標轉換成正式的文檔，在這個過程中，很容易產生錯誤，例如表達不完整，不正確的事實，不一致或模糊的需求等。因此，一定要正確詳細的進行需求定義與驗證，確保規格化的內容確實是用戶所需求的東西。

三、需求變更

  需求變更管理有兩個方面，一是與客戶就怎樣變更達成一致，一個是進行變更流程控制活動。在這兩個方面都容易出錯。

  1、與客戶達成一致方面，需要讓客戶意識到變更對項目影響的后果，要技巧性+友好性的將變更加入到協商條款中。在評估需求變更達到一定的影響時，要試圖協商控制變更，以保證在需求變更下，項目可以繼續成功。

  2、變更流程控制活動，包括怎么進行變更請求，怎么進行變更批準等過程控制，還要考慮為處理變更估計留出時間等等方面的問題。這方面不遵循過程控制流程來走，很容易導致花大功夫補救的后果。

  我們公司已經對變更沒有做很好的控制，就吃了很多虧。我們項目組是駐客戶所在地辦公，開發人員經常接到客戶電話來提出一些功能性的小變更，考慮到是小變更，又受“客戶是上帝、提高客戶滿意度”等思想的影響，也就痛快答應，甚至當場修改程序發布。客戶是高興了，短期來看，效率高，而且還與客戶打好關系。可長期來看，上此以往，這種行為就變成“沒有跟客戶計算成本”的花費，這還是小事，更嚴重的問題是，這種沒有經過整體評估、影響分析、風險識別與分析的行為，有可能改了東家，拆壞了西家，到最后要花費更大的財力去彌補，吃力不討好，更甚的后果是因為這些漏洞，遲遲拖延項目驗收時間，從而導致項目失敗。