起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如果你的項目失敗了，應該是做了失敗的需求分析
本文作者將根據自身的項目經驗，來淺析一下需求分析。
作為一名合格的需求分析人員，對于一些基本的需求開發和需求管理，必須需要學會總結及多問“為什么？”。其實，很多項目的失敗，經過總結和歸納，很大的原因在于需求分析不足而導致。需求捕獲和分析是解決產品的前提，也是解決爭議的前提，也是產品立項的基準；如果需求分析做不到位，后續的開發、測試等產品研發和運營都需要花費很大的人力、財力來填補空白。然而，清晰的項目目標和范圍定義，能夠引導需求工作順利進行。
從我們接觸到的項目中，有不少的項目是失敗的，其實，根據業內數據統計，80%的項目是失敗的，20%的項目才是我們成功的范例；并且這20%的項目還有延期交付、需求變更、上線阻力大等原因；從我個人的經歷看，項目失敗的本質分析主要有：
- 需求變更頻繁
- 上線阻力大（容易產生利益沖突 和增加工作量）
- 產品運行效果差
- 完全奔潰
然而，項目的失敗歸根結底就是需求分析的失敗，根據CHAOS報告總結的“軟件項目十大敗因”中，有五項是與軟件需求直接相關的。這些因素在我幾年的實踐經驗中也深有同感，因此針對這些因素我在幾篇文章中都進行了一些論述，也得到了一些有趣的視角。以下就簡要地對這些敗因做個初步的分析。
1. 不完整的需求
我總是喜歡問這樣的一句話：“什么樣的需求是完整的呢？”實際上，在我以前的工作實踐中，該問題也始終是一個困惑！如果沒有一個有效的“完整性評價標準”，那么這個問題也必將是無解的。要破解這個問題，首先應先回答一個鋪墊性的問題：“誰更有可能可以對需求的完整性進行評價？”。我想大家一定會認同“用戶代表要比開發人員更適合對完整性進行評價”這一觀點吧！而當我們回頭去審視“軟件需求規格說明書”時，卻發現其中充斥著諸如數據字典管理、報表子系統、新增客戶之類的以技術動詞唱主角的字眼與結構，這樣做顯然會將技術功底并不深厚的用戶代表排除在有效讀者群之外。
因此，要想讓用戶代表能夠更好地參與到完整性評價中來，就必須采用“業務導向”的組織結構，而不是讓用戶將一大堆技術動作翻譯到自己的業務場景中去。除此之外，在實際的操作過程中還有一個要點，那就是利用樹型層次結構將宏觀信息與微觀信息進行有效的剝離。
在我從業的經歷中，很多項目組的人員覺得，需求分析就是技術分析，并且很多公司要求需求分析人員需要懂技術，可是；如果需求從技術的角度去看，就失去了業務的可塑性；根本創造不了機會，解決的只是一時問題，并不能真正的把控項目或者產品的發展。
業務需求是需求之魂，對于需求分析而言，真正的專業主義是基于業務利益（解決問題、創造機會、提高管控能力等）的問題，不是技術問題，我們不是造原子彈，沒有那么大的工程和高技術，所以，一些軟件技術的發展是隨著需求深耕才產出，技術伴隨需求而來；有需求才有技術的發展，技術是解決需求。其實，這也是軟件迭代和敏捷的要求，快速響應和及時呈現。
2. 缺乏用戶參與
在很多的軟件項目中，用戶都不能有效地參與到項目中來，也許諸如“你們先做，做出來我們試試后再改”之類的話，早已經聽得你的耳朵生繭了。實際上這個現象的背后存在幾個方面的因素：
- 事不關己，高高掛起：主動參與意識是與獲得的利益成正比的。很多軟件項目在實施之時，并沒有清晰的目標，客戶中的許多代表也不知道能通過新系統獲得什么好處，因此沒有積極性。針對這種情況的主要應對措施是充分研究不同用戶代表的關注點、利益點，具體的方法就是對用戶進行研究，我會在下一篇文章中提到，如何進行用戶研究。
- 逃離無趣區：如果你不喜歡或不熟悉足球，當同事們討論起足球時你會怎么辦？我想選擇離開的人不在少數吧！人本性中有一種逃離無趣區的趨向，對于那些自己沒興趣、不夠專業的領域就不愿意多介入，一方面無趣，另一方面會丟面子！那么用戶對于軟件開發項目和你對于足球所遇到的情況不是一樣嗎？所謂，沒有調查就沒有發言權；用戶對于軟件的技術是沒有興趣的，對于業務流程來說卻是很好的突破口。
- 被你趕走：當用戶鼓起勇氣開始參與需求活動時，難免不被那些“需求分析人員”用深奧的技術語言（也許他們還認為這樣才是專業主義）嚇走。好吧，通過業務利益爭取用戶參與到需求活動中，始終讓技術解決方案在冰山之下以使用戶不中途離開，也許是緩解該問題的很重要的策略。對于需求分析員而言，真正的專業主義是基于業務利益分析和溝通。
3. 不切實際的用戶期望
很多時候，軟件開發從業人員也很無奈！用戶總是很天真地提出了大量的需求，有些是技術上根本無法實現的，有些則是原本就脆弱的費用與時間預算內無法實現的。就像孩子們不知道能夠飛上月球的航天飛機要多少錢一樣，客戶也不知道自己提出的需求真的需要多大的成本。那么問題的根源是什么呢？其實原因就在于軟件的無形和成本的不透明。也許“客戶就像三歲小孩”這樣的潛臺詞，從而導致我們將“不切實際的需求”歸罪于客戶。
實際上要解決這樣的問題，更需要的是從業人員主動地幫助用戶更好地理解軟件的成本。簡單地說，做不到是無效的，要說明為什么做不到才能解決問題。我們需求分析人員提出的就是產品的整個解決方案，不管是從業務角度還是技術角度，都是為了解決用戶的需求，解決他的痛點。
4. 需求變更頻繁
這是一項特別有意思的因素，在CHAOS報告中將其列為第四位，這種排名上的問題背后有什么道理呢？
當有人和我探討解決需求變更頻繁問題的方法時，我總會先問一句“你們經常遇到的變更主要是哪種類型？”，但就是這樣的一個問題卻往往難住了許多人。也就是說，在國內軟件行業中，對變更進行分類、統計的做法仍然不是很普遍。但如果只是簡單地將所有的需求變更都當作一個問題來看待，那么是無法有效地找出問題的根源的，也無法有針對性地改進需求過程，提高設計的彈性。這也許就是經驗和經歷之間的區別吧！
另外一方面，用戶并沒有意識到變更對軟件項目的負面影響。而究其原因，其實與絕大多數軟件企業一樣缺乏統一的變更處理渠道，使得變更相對而言比較散落，沒有集中地體現出來。在我的實踐中，曾經就有用戶代表說：“我們的變更不多吧，我總共只提了兩個?！?，豈不知他這樣提兩個變更的用戶就近百個……需求變更和管理也是需要需求人員重點把控，不然變更得不到有效的遏制以及需求得不到更好的放大，需求變更管理需要設置條件及在時候進行論證。
5. 提供了不再需要的
曾經嘗試過這樣一些小技巧，在每個功能模型的入口頁暗藏了一個計數器功能，一段時間后只要收集回log記錄，一看就知道哪些是“不再需要的”，也就不必再費心去做更多的升級了。當然，這種舉動只能起到“馬后炮”的效果，無法“防范于未然”，仍然浪費我們大量的開發資源與時間。
是否能夠事先預防呢？這必須從另外一個角度來看，那就是能否在最開始有效地劃分優先級。也許這樣的回答會令你失望，優先級劃分經常是“拍腦袋”的產物，沒有理由也沒有原因，它就是最高優先級。這樣的方法顯然是不正確的，真正基于業務領域知識來衡量需求的必要性和充分性是解決之道。
需求分析就是向下分解+向上提煉，外加一些規范化。需求分析是什么？需求分析是業務分析，需求分析是一種分解活動，需求分析是一種提煉與整合行動，需求分析是一種規格化活動。需求分析我們輸出的產物就是需求規格說明書（PRD也叫需求文檔），需求分析也是檢驗一個合格產品經理的標準，產品做什么？最主要的還是以把握客戶需求為準。需求又可分為：
- 業務需求
- 用戶需求
- 軟件需求
- 功能需求
- 非功能性需求
- 設計約束
其實，需求獲取也有失敗，并不是完整的表現；需求獲取的問題主要表現在：
- 捕獲范圍不足
- 缺乏計劃性
- 缺乏科學性
- 捕獲對象不明確
- 捕獲手段不足 有時候就會導致項目的終止或失敗。
那我們的需求標準是什么呢？怎樣的需求才能被記入到PRD里面呢？也就是我們的標準，需求的標準：
- 完整性
- 不失真
- 有優先級
- 有技術早期介入
這樣的PRD才不會有爭議，即使有變更也需要及時的知會項目組成員。需求分析的過程我在前篇文章中有提到，需求的驗證和評審是一個反復的過程，就是為了解決爭議。
從我參與的軟件項目過程中來看，主要的原因如下，也希望給你得到些許提醒：
1、溝通失真
溝通失真，從客戶的描述到項目經理的理解、分析員的設計、程序員的編碼、商業顧問的詮釋，每個角色都根據自己的特點和需求對信息進行了不同的加工，從而導致信息的內容有了很大的改變。因此，對于軟件需求工程而言，克服溝通失真就成了一個要點。根據相關的研究顯示，在信息的傳遞過程中，如果沒有采取任何措施，那么在溝通過程中信息衰減可能的最大值高達60%。而在軟件開發過程中，需求信息通常要經歷用戶代表、需求人員、設計人員再到開發人員，因此最壞的情況下，開發人員獲得的信息僅是原來的8.4%，這是一個十分可怕的結果。怎樣才能夠更好地避免這種問題的出現呢？其實關鍵的手段有兩個：
- 文檔：如果信息在傳遞的過程中僅靠口口相授的話，就難免發生遺忘、加工等情況，因此必須在這個過程中有效地利用文檔，將達成共識的信息文檔化。但這種方法只是用來輔助溝通的，而不是代替溝通，文檔的好處就是有依據，避免了后期的扯皮，也有利于需求的管理及變更。
- Review：國內常將其翻譯為“評審”，但這一翻譯卻容易給人誤導。評審在很多人的腦海中就是得出一個通過與否的結論，這也是導致需求評審工作流于形式的罪魁禍首之一。顧名思義，Review就是再（Re）看（View）一遍的意思，其本質含義是通過再次的審讀，盡早地暴露出錯誤。而最簡單、最有效的Review就是在用戶代表闡述了需求之后，需求分析員用自己的語言再復述一遍，以確保溝通沒有失真。解決失真的最有效的辦法就是及時的復述。
2. 客戶的需求放大
用戶在描述自己的需求時做了許多“添磚加瓦”的事。“用戶要么不會說，要么就會添油加醋”的現象，在我的實踐中是屢見不鮮的。而在這種現象的背后有什么潛在的原因呢？我認為至少有兩方面關鍵因素：
- 客戶希望支付的成本盡可能少，獲得的效益盡可能多（想馬好，又不想馬吃草）。這種思維對于任何一個客戶、任何一個人而言都是本能反應。而當用戶對開發成本越不了解時，這種心態就會越強烈，更加擔心自己“虧損”了；因此，在需求協商時就會采取盡可能增加功能的方法來降低“虧損”的風險。要解決該問題并不是件容易的事，一方面需要提升軟件估算實踐的有效性，另一方面則需要產業成熟度的提高。
- 解決方案的選擇權交給了不熟悉技術的客戶。許多需求團隊在進行需求捕獲活動時，經常預期用戶能夠直接告訴他們要做什么（What），而不太關心用戶提出需求的真正動機（Why）。但是，這樣就將解決方案的選擇權交給了并不熟悉技術的客戶代表，而一旦客戶代表選擇的解決方案不是最合適的，就必將引發后續的需求變更。因為，對于一個特定的問題，可能的解決方案會有很多，因此用戶可能在使用軟件的過程中不斷發現其他可選的、更合適的替代方案，從而導致了不必要的需求變更。而要緩解這一現象的關鍵就在于，在需求捕獲的過程中多問“為什么”。
3. 項目經理的需求控制
項目經理在溝通的過程中會導致需求產生偏差。由于國內許多軟件項目經理們通常是一身兼多職，項目管理、需求分析、架構設計一肩挑，因此在需求捕獲的過程中，總會“及時”地在腦海里勾勒出技術框架和路線，然后盡可能地控制需求的范圍。但實際上，有些需求“表面上”是控制下去了，但卻在后面以“需求變更”的形式全回來了。其實，在我的工作經理當中這也是司空慣見，老板為了減少開支總會這樣做，但是，后果卻沒有想到。
實際上，我的體會是需求分析人員是有必要對需求進行有效的控制的，問題出在控制的策略和方向上。從前面的描述中不難看出，項目經理經常會從技術的角度來對需求進行控制，這樣就可能造成無法形成對需求的有效理解。我認為應該以業務為線索來組織需求，基于“Why”的層面對需求建立高層次的認識。
4.?分析人員的技術加工
每次在跳槽時，就會想起現在許多名稱中包含“需求分析”、“系統分析”之類的職位，大多是由技術骨干擔任的，因此在工作中很少從業務角度進行分析，更多還是追求技術框架、新技術。對于這種現象，究其根源，關鍵還在于“技術能力”對他們的未來發展更為重要，而“業務能力”卻不是那么重要。但為了使需求工作有更好的提高，我會強烈呼吁那些Title上有“分析”之類名稱的人們，加強業務分析吧！畢竟，需求分析的本質在于業務分析，而非技術分析。
5. 開發人員的斷章取義
對于客戶描述的需求，可以用一句生動的話來概括：“你要繩子，我給你了；你要木板，我也給你了；你為什么說這不是你想要的呢？”。我想程序員也有類似的問題想問自己的客戶，“你要文本框，我提供了；你要一個表單，我也有了；你為什么說這個程序不是你想要的呢？”。這是需求嗎？也許很多人會有不同的看法！但如果缺乏對業務場景的了解，又如何能夠真正理解需求呢？業務場景是需求之魂，需求分析人員最重要的就是將客戶的業務場景分析透徹，將后續的產出輸入給開發人員。
不同的讀者能夠得到更多不同的啟發。不過最為重要的一點在于反思這一現象后面的本質因素，構思真正有效的緩解手段，這樣才能夠有效的避免出現項目失敗、走進“迷途”，這里的需求分析都是比較淺析，希望可以幫助你。以下是根據我這幾年做產品及需求分析的總結：
1、需求規格書應采用業務導向的樹型層次結構來組織
2、緩解溝通失真最有效的方法是及時復述
3、在需求捕獲的過程中多問為什么？
4、在功能上加一個計數器，用來區分或者說切掉產品功能的重要性的依據
5、需求分析人員對于計劃方法論的評價重在適用性
6、對預設計的需求是評判敏捷方法論是否適用的關鍵
7、高層管理人員的關注點往往在問題和機會
8、對于向用戶的鑲入式系統行為分析是要點，以場景為主
9、并行工作流是OA系統的關鍵線索和主要視圖
10、業務需求是需求定的產物，用戶需求是捕獲的產物，軟件需求是需求分析與建模的產物
功能需求的重點在于組織
11、非功能需求的要點在于保證信息有效傳遞和注意其局部性
12、設計約束包括非技術因素的技術選型、預期的軟硬件環境和預期的使用環境三大類
13、業務導向的層次結構是保障完整性的關鍵
14、滿意/不滿意度模型是需求必要性評價的有效手段
15、在需求捕獲活動中化被動為主動是關鍵，主動出擊才是抓住商機和賣點
希望能幫助在產品和需求分析道路上的你。
本文由 @唐先生 原創發布于人人都是產品經理。未經許可，禁止轉載
這怎么感覺是照著「軟件需求最佳實踐」抄的呢
很棒，很實用
在功能上加一個計數器，用來區分或者說切掉產品功能的重要性的依據—-這個直接叫埋點就ok了
雖然小白未能完全參透，但是萬分感謝