需求分析人員應(yīng)具備哪些技能？需求分析師主要在項目前期收集項目需求，分析項目實施的可行性，為開發(fā)者整理客戶需求。通常，需要以下技能:1、公文寫作能力，包括word、ppt等。2.我將使用建模工具來繪制相

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

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

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

3.邏輯分析能力

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

如何做需求分析？

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

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

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

如何做需求分析？

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

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

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

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

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

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

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

規(guī)則。

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

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

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

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

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

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

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

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

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

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