如果你的項(xiàng)目失敗了應(yīng)該是做了失敗的需求分析

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