經過chaos report的統計，發現軟體專案成功的十大保證中，有三個到四個（其中乙個是需求定義，我們也認為和需求相關），差不多佔到40%左右，這是乙個很大的比例了。而十大敗因中，直接和需求相關的更是超過了50%，也就是說，需求一旦出現問題，專案基本上就是失敗了，包括完全失敗、在專案成本的大幅度超支、在專案進度上的較多的delay……
成功因素
權重
失敗因素
權重
使用者的參與（需求）
15.9%
不完整的需求（需求）
13.1%
執行層的支援（專案管理）
13.9%
缺乏使用者參與（需求）
12.4%
清晰的需求描述（需求）
13.0%
資源不足（資源）
10.6%
合適的規劃
（需求定義和專案管理）
9.6%
不切實際的使用者期望（需求）
9.9%
現實的客戶期望（需求）
8.2%
缺乏執行層的支援（專案管理）
9.3%
較小的里程碑（專案管理）
7.7%
需求變更頻繁（需求）
8.7%
有才能的員工（資源）
7.2%
規劃不足（需求定義、專案管理）
8.1%
主權
5.3%
提供了不再需要的（需求、專案管理）
7.5%
清晰的願景和目標（需求定義）
2.9%
缺乏
it管理（專案管理）
6.2%
努力的工作和穩定的員工（環境、資源）
2.4%
技術能力缺乏（資源）
4.3%
其他
13.9%
其他
9.9%
下面，簡單的對需求的幾個敗因做簡單的分析：
一、不完整的需求：
出現的環節及應對策略：
1、需求的捕獲階段，該捕獲的專案干係人沒有訪談到，導致部分需求缺失，不完整，另外，也有可能是忽視了非功能性需求。//按需求層次，列出需要訪談的物件，並請客戶和重要專案干係人確認；加強需求評審環節；重視非功能性需求。
2、需求分析，在需求的漏斗出現了問題，過濾掉了本不該過濾掉的需求。//加強需求評審環節。
3、在需求表述環節出現了問題。//加強需求評審環節。
4、在需求評審環節出現了問題，需求評審的效率不高、沒有找全必須的評審者、或者過於形式化//正確的認識評審的作用，並做好評審。
二、缺乏使用者參與：
這也是乙個很常見的例子，一方面可能是開發方或者實施方對客戶的參與度重視不夠，因為各種原因低估了使用者參與的作用，另外，也有可能是客戶方的不重視，由不合適的人拍板，使用者沒有或者很難參與進來，這往往是客戶方專案經理或者客戶高層的問題。
可能的原因及應對策略：
1、實施、開發方沒有重視到客戶參與的作用、意義，也可能是出於專案進度的壓力故意壓制客戶的需求而導致。比如形式化的需求工程，過於走過場，希望專案早點結束，比如不只關注核心專案干係人的需求、意見。//重視使用者的參與，給足需求階段的時間安排。
2、客戶的問題。客戶方不重視使用者的參與，往往是因為客戶資源的進展，比如大家都很忙，或者客戶的專案領導比較武斷，喜歡拍板而導致使用者沒有辦法參與進來，或者使用者即使能參與過來，他們的意見也不太被重視而逃離。//重視使用者的參與，他們才是真正的受益者或者受害者，把領導的期望和基層使用者的需求聯絡起來，或者領導更多的考慮流程的規範性和報表的需求，而把操作和業務需求交給真正的人來負責。
三、不切實際的使用者期望
這是長常見的，主要是使用者的期望過高，專案經理沒有給客戶乙個合適的期望，客戶也沒有引導終端使用者到合適的期望值。
這是我們常說的，專案管理，要注重管理客戶的期望，如果客戶的期望是「5層樓」那麼高的話，我們要想辦法把他降到「3層樓」，然後把實際的交付交付到「4層樓」。假設「5層樓」是我們在專案實施前「忽悠」的高度（首先給使用者乙個好的期望，才會選擇我們嘛），「4層樓」是乙個合理的期望高度的話。//管理使用者的期望，很重要！低期望，高交付，這樣實際上就超出使用者的期望了，從而提高了專案的滿意度。當然，也不能管理的太低，否則客戶就會沒有資訊，懷疑實施這麼專案的意義和必要性。
四、需求變更頻繁
需求變更，其實很大程度上和客戶沒有關係，更多的是我們自己出了問題，在需求開發環節沒有做好，當然，也有可能是需求控制方面出了問題。
1、沒有深入到使用者需求的本質，需求分析的深度不夠，過於形式化。很可能是我們只找到了部分what，沒有找到why//要引導、去分析使用者為什麼要這樣，不這樣會怎麼樣。另外，重視需求評審，提高評審的質量！
2、沒有需求的凍結期。導致使用者提需求和需求變更的成本太低，認為這是理所當然。//一定要有需求凍結期，使使用者重視需求凍結期前的時間來提需求，在需求凍結期引入規範的需求控制流程，並對使用者每次的變更做記錄和反饋，讓使用者自己慚愧，並意識到我們的難度和工作量。
五、提供了使用者不再需求的
可能的原因及應對策略：
1、有些需求可能只是拍腦袋，一時興起。//要區分哪些是穩定的需求，哪些是使用者的一時興起，不穩定的需求可以先不做，拖拖再說。
2、市場的變化太快或者我們開發、研發的進度太慢，沒有跟上市場的節奏。//正確分析產品的生命週期，不在飽和期和衰退期切入。要充分分析自己的研發能力。
軟體專案管理的十大定律
一 馬特萊法則 馬特萊法則又稱80 20法則，它的涵義是把80 20作為確定比值，主張企業經營者經營管理企業不必面面俱到，而應側重抓關鍵的20 從人力資源管理的角度來看，企業經營者應把主要精力放在對佔職工總數20 的業務骨幹的管理上，抓企業發展的骨幹力量，再以這20 的少數帶動佔80 的多數，以提高...
軟體專案管理的十大定律
一 馬特萊法則 馬特萊法則又稱80 20法則，它的涵義是把80 20作為確定比值，主張企業經營者經營管理企業不必面面俱到，而應側重抓關鍵的20 從人力資源管理的角度來看，企業經營者應把主要精力放在對佔職工總數20 的業務骨幹的管理上，抓企業發展的骨幹力量，再以這20 的少數帶動佔80 的多數，以提高...
專案管理十大誤區
隨著計算機硬體水平的不斷提高，計算機軟體的規模和複雜度也隨之增加。計算機軟體開發從 個人英雄 時代向團隊時代邁進，計算機軟體專案的管理也從 作坊式 管理向 軟體工廠式 管理邁進。這就要求軟體開發人員特別是軟體專案管理人員更深一步地理解和掌握現代軟體工程的理論方法，完成思想觀念上的轉變。筆者在此分析了...