淺析一下需求分析。作為一名合格的需求分析人員，對于一些基本的需求開發(fā)和需求管理，必須需要學會總結不足而導致。需求捕獲和分析是解決產品的前提，也是解決爭議的前提，也是產品立項的基準；如果需求分析做不到位，后續(xù)的開發(fā)、測試等產品研發(fā)和運營都需要花費很大的人力、財力來填補空白。然而，清晰的項目目標和范圍定義，能夠引導需求工作順利進行。從我們接觸到的項目中，有不少的項目是失敗的，其實，根據(jù)業(yè)內數(shù)據(jù)統(tǒng)計，80%的項目是失敗的，20%的項目才是我們成功的范例；并且這20%的項目還有延期交付、需求變更、上線阻力大等原因；從我個人的經歷看，項目失敗的本質分析主要有：因此針對這些因素我在幾篇文章中都進行了一些論述，也得到了一些有趣的視角。以下就簡要地對這些敗因做個初步的分析。1.不完整的需求我總是喜歡問這樣的一句話：“什么樣的需求是完整的呢？”實際上，在我以前的工作實踐中，該問題也始終是一個困惑！如果沒有一個有效的“完整性評價標準”，那么這個問題也必將是無解的。要破解這個問題，首先應先回答一個鋪墊性的問題：“誰更有可能可以對需求的完整性進行評價？”。我想大家一定會認同“用戶代表要比開發(fā)人員更適合對完整性進行評價”這一觀點吧！而當我們回頭去審視“軟件需求規(guī)格說明書”時，卻發(fā)現(xiàn)其中充斥著諸如數(shù)據(jù)字典管理、報表子系統(tǒng)、新增客戶之類的以技術動詞唱主角的字眼與結構，這樣做顯然會將技術功底并不深厚的用戶代表排除在有效讀者群之外。因此，要想讓用戶代表能夠更好地參與到完整性評價中來，就必須采用“業(yè)務導向”的組織結構，而不是讓用戶將一大堆技術動作翻譯到自己的業(yè)務場景中去。除此之外，在實際的操作過程中還有一個要點，那就是利用樹型層次結構將宏觀信息與微觀信息進行有效的剝在我從業(yè)的經歷中，很多項目組的人員覺得，需求分析就是技術分析，并且很多公司要求需求分析人員需要懂技術，可是；如果需求從技術的角度去看，就失去了業(yè)務的可塑性；根本創(chuàng)造不了機會，解決的只是一時問題，并不能真正的把控項目或者產品的發(fā)展。業(yè)務需求是需求之魂，對于需求分析而言，真正的專業(yè)主義是基于業(yè)務利益(解決問題、創(chuàng)造機會、提高管控能力等)的問題，不是技術問題，我們不是造原子彈，沒有那么大的工程和高技術，所以，一些軟件技術的發(fā)展是隨著需求深耕才產出，技術伴隨需求而來；有需求才有技術的發(fā)展，技術是解決需求。其實，這也是軟件迭代和敏捷的要求，快速響應和及時呈現(xiàn)。2.缺乏用戶參與在很多的軟件項目中，用戶都不能有效地參與到項目中來，也許諸如“你們先做，做出來我們試試后再改”之類的話，早已經聽得你的耳朵生繭了。實際上這個現(xiàn)象的背后存在幾個方面的因素：3.不切實際的用戶期望很多時候，軟件開發(fā)從業(yè)人員也很無奈！用戶總是很天真地提出了大量的需求，有些是技術上根本無法實現(xiàn)的，有些則是原本就脆弱的費用與時間預算內無法實現(xiàn)的。就像孩子們不知道能夠飛上月球的航天飛機要多少錢一樣，客戶也不知道自己提出的需求真的需要多大的成本。那么問題的根源是什么呢？其實原因就在于軟件的無形和成本的不透明。也許“客戶就像三歲小孩”這樣的潛臺詞，從而導致我們將“不切實際的需求”歸罪于客戶。實際上要解決這樣的問題，更需要的是從業(yè)人員主動地幫助用戶更好地理解軟件的成本。簡單地說，做不到是無效的，要說明為什么做不到才能解決問題。我們需求分析人員提出的就是產品的整個解決方案，不管是從業(yè)務角度還是技術角度，都是為了解決用戶的需求，解決他的痛點。4.需求變更頻繁這是一項特別有意思的因素，在CHAOS報告中將其列為第四位，這種排名上的問題背后有什么道理呢？當有人和我探討解決需求變更頻繁問題的方法時，我總會先問一句“你們經常遇到的變更主要是哪種類型？”，但就是這樣的一個問題卻往往難住了許多人。也就是說，在國內軟件行業(yè)中，對變更進行分類、統(tǒng)計的做法仍然不是很普遍。但如果只是簡單地將所有的需求變更都當作一個問題來看待，那么是無法有效地找出問題的根源的，也無法有針對性地改進需求過程，提高設計的彈性。這也許就是經驗和經歷之間的區(qū)別吧！另外一方面，用戶并沒有意識到變更對軟件項目的負面影響。而究其原因，其實與絕大多數(shù)軟件企業(yè)一樣缺乏統(tǒng)一的變更處理渠道，使得變更相對而言比較散落，沒有集中地體現(xiàn)出來。在我的實踐中，曾經就有用戶代表說：“我們的變更不多吧，我總共只提了兩個。”，不然變更得不到有效的遏制以及需求得不到更好的放大，需求變更管理需要設置條件及在時候進行論證。5.提供了不再需要的曾經嘗試過這樣一些小技巧，在每個功能模型的入口頁暗藏了一個計數(shù)器功能，一段時間后只要收集回log記錄，一看就知道哪些是“不再需要的”，也就不必再費心去做更多的升級了。當然，這種舉動只能起到“馬后炮”的效果，無法“防范于未然”，仍然浪費我們大量的開發(fā)資源與時間。是否能夠事先預防呢？這必須從另外一個角度來看，那就是能否在最開始有效地劃分優(yōu)先級。也許這樣的回答會令你失望，優(yōu)先級劃分經常是“拍腦袋”的產物，沒有理由也沒有原因，它就是最高優(yōu)先級。這樣的方法顯然是不正確的，真正基于業(yè)務領域知識來衡量需求的必要性和充分性是解決之道。需求分析就是向下分解+向上提煉，外加一些規(guī)范化。需求分析是什么？需求分析是業(yè)務分析，需求分析是一種分解活動，需求分析是一種提煉與整合行動，需求分析是一種規(guī)格化活動。需求分析我們輸出的產物就是需求規(guī)格說明書(PRD也叫需求文檔)，需求分析也是檢驗一個合格產品經理的標準，產品做什么？最主要的還是以把握客戶需求為準。需其實，需求獲取也有失敗，并不是完整的表現(xiàn)；需求獲取的問題主要表現(xiàn)在：那我們的需求標準是什么呢？怎樣的需求才能被記入到PRD里面呢？也就是我們的標準，需求的標準：這樣的PRD才不會有爭議，即使有變更也需要及時的知會項目組成員。需求分析的過程我在前篇文章中有提到，需求的驗證和評審是一個反復的過程，就是為了解決爭議。從我參與的軟件項目過程中來看，主要的原因如下，也希望給你得到些許提醒：真溝通失真，從客戶的描述到項目經理的理解、分析員的設計、程序員的編碼、商業(yè)顧問的詮釋，每個角色都根據(jù)自己的特點和需求對信息進行了不同的加工，從而導致信息的內容有了很大的改變。因此，對于軟件需求工程而言，克服溝通失真就成了一個要點。根據(jù)相關的研究顯示，在信息的傳遞過程中，如果沒有采取任何措施，那么在溝通過程中信息衰減可能的最大值高達60%。而在軟件開發(fā)過程中，需求信息通常要經歷用戶代表、需求人這是一個十分可怕的結果。怎樣才能夠更好地避免這種問題的出現(xiàn)呢？其實關鍵的手段有兩個：2.客戶的需求放大用戶在描述自己的需求時做了許多“添磚加瓦”的事?！坝脩粢床粫f，要么就會添油加醋”的現(xiàn)象，在我的實踐中是屢見不鮮的。而在這種現(xiàn)象的背后有什么潛在的原因呢？我認為至少有兩方面關鍵因素：經理的需求控制項目經理在溝通的過程中會導致需求產生偏差。由于國內許多軟件項目經理們通常是一身兼多職，項目管理、需求分析、架構設計一肩挑，因此在需求捕獲的過程中，總會“及時”地在腦海里勾勒出技術框架和路線，然后盡可能地控制需求的范圍。但實際上，有些需求“表面上”是控制下去了，但卻在后面以“需求變更”的形式全回來了。其實，在我的工作經理當中這也是司空慣見，老板為了減少開支總會這樣做，但是，后果卻沒有想到。實際上，我的體會是需求分析人員是有必要對需求進行有效的控制的，問題出在控制的策略和方向上。從前面的描述中不難看出，項目經理經常會從技術的角度來對需求進行控制，這樣就可能造成無法形成對需求的有效理解。我認為應該以業(yè)務為線索來組織需求，基于“Why”的層面對需求建立高層次的認識。4.分析人員的技術加工每次在跳槽時，就會想起現(xiàn)在許多名稱中包含“需求分析”、“系統(tǒng)分析”之類的職位，大多是由技術骨干擔任的，因此在工作中很少從業(yè)務角度進行分析，更多還是追求技術框架、新技術。對于這種現(xiàn)象，究其根源，關鍵還在于“技術能力”對他們的未來發(fā)展更為重要，而“業(yè)務能力”卻不是那么重要。但為了使需求工作有更好的提高，我會強烈呼吁那些Title上有“分析”之類名稱的人們，加強業(yè)務分析吧！畢竟，需求分析的本質在于業(yè)務分析，而非技術分析。5.開發(fā)人員的斷章取義對于客戶描述的需求，可以用一句生動的話來概括：“你要繩子，我給你了；你要木板，我也給你了；你為什么說這不是你想要的呢？”。我想程序員也有類似的問題想問自己的客戶，“你要文本框，我提供了；你要一個表單，我也有了；你為什么說這個程序不是你，又如何能夠真正理解需求呢