需求分析人員應(yīng)具備哪些技能？

1、公文寫作能力，包括word、ppt等。

2.我將使用建模工具來繪制相應(yīng)的UML圖。

3.邏輯分析能力

4、必須非常熟悉相關(guān)業(yè)務(wù)。

如何做需求分析？

一是用戶需求，挖掘用戶的真實(shí)需求，看用戶是想造航母還是漁船；

第二，產(chǎn)品本身的客觀需求。目前市場(chǎng)上同類型的產(chǎn)品要進(jìn)行比較和挖掘。比如市面上的產(chǎn)品都是漁船，那么客戶的需求就會(huì)減少；

第三，比較用戶和消費(fèi)者是不現(xiàn)實(shí)的的時(shí)間、進(jìn)度和預(yù)期結(jié)果跟自己的需求，比如客戶只給了造船的錢，缺乏造航母的。

如何做需求分析？

1:抓住了核心點(diǎn)，不是所有的用戶需求都是需求。

我們每做一個(gè)項(xiàng)目迭代或者一個(gè)新項(xiàng)目，都要有一個(gè)目的。在需求分析階段，需求收集渠道中的需求往往是分散的、無重點(diǎn)的、不符合邏輯的，我們需要從這些離散的需求點(diǎn)中抓住核心，梳理出實(shí)際使用場(chǎng)景來分析問題。所有的核心點(diǎn)都要面向最終目標(biāo)，并不是所有的用戶需求都是需求。

以我的項(xiàng)目為例。由于歷史原因，自營(yíng)配送員與員工的關(guān)系沒有錄入OA系統(tǒng)，所以配送員的工資結(jié)算數(shù)據(jù)只能做成配送系統(tǒng)，相當(dāng)于簡(jiǎn)單的考勤記錄。其實(shí)之前系統(tǒng)也有這個(gè)功能，但是因?yàn)橹皼]有仔細(xì)整理需求，這個(gè)功能做了也是白做，所以這次我接手了，差點(diǎn)就做了。我以為讓一個(gè)產(chǎn)品助理先整理需求是比較簡(jiǎn)單的，但是當(dāng)我畫出原型的時(shí)候，發(fā)現(xiàn)并不能解決薪資結(jié)算的功能。

所以，當(dāng)時(shí)我就跟小哥說，你剛交班，但是交班的目的是結(jié)算工資，可以Idon’我不能滿足需求。所以我跟他強(qiáng)調(diào)，這個(gè)要求的目的是考勤，要提供請(qǐng)假、值班、加班小時(shí)、休息日加班等數(shù)據(jù)。其實(shí)他的第一個(gè)原型并沒有完全理解我們?yōu)槭裁匆鲞@個(gè)調(diào)度功能，所以在理解需求的過程中沒有抓住核心點(diǎn)，導(dǎo)致需求不清晰。

2:制定規(guī)則，改進(jìn)復(fù)雜的流程。

我上一家公司是做互聯(lián)網(wǎng)電商的。其實(shí)在我看來，電子商務(wù)和O2O有一個(gè)很大的區(qū)別，就是電子商務(wù)在盛行的情況下已經(jīng)變得非常有規(guī)律，比如首頁(yè)、商品列表頁(yè)、詳情頁(yè)、訂單頁(yè)等等。，而且每個(gè)頁(yè)面顯示的信息也大相徑庭，和O2O不一樣。一方面O2O差不多13年才興起，至今(15年)沒有標(biāo)桿行業(yè)，另一方面O2O。生活聯(lián)系太緊密了，而且是很復(fù)雜的業(yè)務(wù)流程。以上是toC產(chǎn)品的規(guī)則和流程，流程在toB產(chǎn)品中尤為明顯。toB產(chǎn)品最經(jīng)典的例子就是公司后臺(tái)系統(tǒng)。

不管是toC的產(chǎn)品還是toB的產(chǎn)品，都要考慮用戶的使用場(chǎng)景。PM需要把自己當(dāng)成用戶，充分考慮用戶在各種情況下思考，設(shè)計(jì)出滿足用戶需求的產(chǎn)品。;的需求。在這里，我們并不是一味的迎合用戶。互聯(lián)網(wǎng)用戶都知道，一個(gè)業(yè)務(wù)不規(guī)范，很難用產(chǎn)品滿足用戶，所以我們有必要制定規(guī)則，或者說優(yōu)化不完善，很復(fù)雜。

規(guī)則。

讓讓我們談?wù)勚贫ㄒ?guī)則。其實(shí)統(tǒng)一規(guī)則有利有弊。比如滴滴打車訂單被搶，優(yōu)步打車訂單被系統(tǒng)自動(dòng)分配。滴滴可以改善司機(jī)積極性和自主性，司機(jī)可以選擇高價(jià)值訂單，但這種做法也會(huì)影響用戶體驗(yàn)。比如以后沒有補(bǔ)貼，我只是一個(gè)起步價(jià)，有些司機(jī)不愿意接單，要等很久；優(yōu)步打車制定了自動(dòng)分配的規(guī)則，首先分配離乘客最近的閑置司機(jī)。如果他不不接，他會(huì)被分配到下一個(gè)。我贏了。;不能說這是否能讓用戶滿意。我只說這個(gè)規(guī)則簡(jiǎn)化了下單流程。司機(jī)和乘客只有兩個(gè)選擇，接還是不接，坐還是不坐。如果司機(jī)不他不接。;我不知道下一個(gè)訂單什么時(shí)候能等到，也不知道訂單量有多大。雖然降低了司機(jī)之間的積極性和自主性，但是對(duì)用戶來說體驗(yàn)還是不錯(cuò)的。

制定規(guī)則后，讓讓我們談?wù)劯倪M(jìn)流程。如我上面所說，這種流程簡(jiǎn)化在toB產(chǎn)品中尤為明顯。很多人有一個(gè)觀點(diǎn)，后臺(tái)系統(tǒng)反正是自己人或者其他企業(yè)人員用的，沒必要做得那么方便細(xì)致。其實(shí)優(yōu)秀的PM在這方面總是能從頭到尾的做完，因?yàn)樵谒麄冄劾铮稽c(diǎn)點(diǎn)的產(chǎn)品優(yōu)化或者流程優(yōu)化就能給企業(yè)帶來很多收益，這點(diǎn)我是有切身體會(huì)的。

在我之前做過的很多項(xiàng)目中，有兩個(gè)是我在做需求的時(shí)候，發(fā)現(xiàn)業(yè)務(wù)部門每天都在固定的思考或者重復(fù)做他的工作，但是他們沒有我發(fā)現(xiàn)它實(shí)際上效率很低。在沒有人觀察到流程有問題的時(shí)候，業(yè)務(wù)部門已經(jīng)形成了一個(gè)規(guī)范，但是這個(gè)規(guī)范不是最優(yōu)的。PM做需求分析的時(shí)候，需要仔細(xì)觀察他們部門或者個(gè)人的工作內(nèi)容，思考為什么要這樣做，有沒有其他的解決方案來提高其工作效率。

做數(shù)據(jù)統(tǒng)計(jì)的時(shí)候，發(fā)現(xiàn)業(yè)務(wù)部門的一個(gè)同事要導(dǎo)出所有的新增用戶號(hào)碼，訂單號(hào)，餐廳金額，訂單金額等數(shù)據(jù)每天調(diào)查配送員和用戶的滿意度。但是她每天導(dǎo)出的數(shù)據(jù)，其實(shí)也是另外兩個(gè)同事在用，只是目的不同，但都很死板。他們?nèi)齻€(gè)每天導(dǎo)出一個(gè)完整的數(shù)據(jù)，然后篩選條件和分組。其實(shí)沒必要去合成我們想要的數(shù)據(jù)。我們可以向他們的部門發(fā)送每日訂單報(bào)告，并標(biāo)記新用戶。

又如，財(cái)務(wù)部門在結(jié)算后勤人員工資時(shí)，很多計(jì)算公式是相互關(guān)聯(lián)的。比如A=BC，D=A*EB-C，但是計(jì)算出來是D=(BC)*EB-C.L:離散需求整合

在和業(yè)務(wù)部門打交道的時(shí)候，我發(fā)現(xiàn)他們的思維邏輯可能有點(diǎn)差。當(dāng)PM理解了需求，業(yè)務(wù)人員或者用戶就沒有了因果，也就是沒有了邏輯。此時(shí)，如果PM不不要問問題，很容易被坑。合格的PM在這種情況下應(yīng)該轉(zhuǎn)過身來，再次說明問題。如果遇到稍微強(qiáng)勢(shì)一點(diǎn)的PM，要指出剛才的說法是錯(cuò)誤的。

也有業(yè)務(wù)部門的人，在你溝通的時(shí)候談了很多產(chǎn)品改進(jìn)意見或者新的需求想法。這時(shí)候PM要認(rèn)真聽，記錄需求點(diǎn)，千萬不要給他們這個(gè)功能什么時(shí)候做，什么時(shí)候上線的答案，因?yàn)橄到y(tǒng)永遠(yuǎn)是不完善的，需求永遠(yuǎn)是無止境的，資源是有限的，所以你給的答案可以不要意識(shí)到別人糟糕的觀點(diǎn)。一個(gè)優(yōu)秀的PM需要大局觀，能夠和團(tuán)隊(duì)一起評(píng)估需求。

4:技術(shù)人員參與需求分析階段。

現(xiàn)在很多互聯(lián)網(wǎng)公司基本都是產(chǎn)品驅(qū)動(dòng)，所以it很難說它們是技術(shù)驅(qū)動(dòng)的，因?yàn)楫a(chǎn)品團(tuán)隊(duì)知道用戶想要什么。在我參與需求分析的時(shí)候，事業(yè)部的技術(shù)總監(jiān)喜歡跟著我去了解需求，這是我之前的工作組從來沒有遇到過的。現(xiàn)在他參與需求的時(shí)候，我發(fā)現(xiàn)整個(gè)產(chǎn)品需求是混亂的，阻礙了我需求分析的進(jìn)度，因?yàn)樗偸菑募夹g(shù)角度考慮實(shí)現(xiàn)這個(gè)的難度。因?yàn)樗羌夹g(shù)總監(jiān)，有很強(qiáng)的邏輯思維能力，所以每當(dāng)聽到不需要添加一個(gè)條目來維護(hù)這個(gè)數(shù)據(jù)的時(shí)候，他就會(huì)站出來說為什么要這么做，然后說服業(yè)務(wù)部門這個(gè)數(shù)據(jù)不能提供，那他能不能先不做？

但是從產(chǎn)品的角度來說，既然選擇做這個(gè)項(xiàng)目，就要從產(chǎn)品的角度來設(shè)計(jì)。在一整套產(chǎn)品解決方案出來后，精簡(jiǎn)功能是一個(gè)很好的方法。在某些情況下，當(dāng)一個(gè)更好的想法產(chǎn)生時(shí)，技術(shù)人員會(huì)首先考慮它是否能實(shí)現(xiàn)以及實(shí)現(xiàn)的復(fù)雜程度。如果有一點(diǎn)困難或者現(xiàn)場(chǎng)無法給出技術(shù)上可行的方案，這個(gè)功能就暫時(shí)擱置，也許會(huì)提出另一個(gè)沒有錯(cuò)但不是最好的方案，于是技術(shù)人員參與需求。總而言之，我的理解是技術(shù)人員暫時(shí)不要參與需求分析階段，產(chǎn)品團(tuán)隊(duì)內(nèi)部討論后技術(shù)團(tuán)隊(duì)再參與評(píng)審，可能會(huì)達(dá)到事半功倍的效果。