如何做需求分析？從不同方面著手:一是用戶需求，挖掘用戶的真實(shí)需求，看用戶是想造航母還是漁船；第二，產(chǎn)品本身的客觀需求。目前市場上同類型的產(chǎn)品要進(jìn)行比較和挖掘。比如市面上的產(chǎn)品都是漁船，那么客戶的需求就

如何做需求分析？

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

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

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

如何做需求分析？

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

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

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

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

我上一家公司是做互聯(lián)網(wǎng)電商的。其實(shí)在我看來，電子商務(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)。

無論是a to C產(chǎn)品還是a to B產(chǎn)品，都要考慮用戶使用場景，PM需要把自己當(dāng)成用戶。只有充分考慮用戶 我們能設(shè)計(jì)出滿足用戶需求的產(chǎn)品嗎？;的需求。在這里，我們并不是一味的迎合用戶?；ヂ?lián)網(wǎng)用戶都知道，一個業(yè)務(wù)不規(guī)范，很難用產(chǎn)品讓用戶滿意，所以我們有必要制定規(guī)則或者不完全、流程復(fù)雜的優(yōu)化。

規(guī)則。

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

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

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

在做數(shù)據(jù)統(tǒng)計(jì)的時候，發(fā)現(xiàn)業(yè)務(wù)部門的一個同事需要導(dǎo)出所有的新增用戶 、訂單號、餐廳金額、訂單金額等數(shù)據(jù)，每天考察配送員和用戶的滿意度。但是她每天導(dǎo)出的數(shù)據(jù)，其實(shí)也是另外兩個同事需要的，只是目的不同，但是都很死板。他們?nèi)齻€每天導(dǎo)出一個完整的數(shù)據(jù)，然后篩選條件組合成自己的數(shù)據(jù)。這種工作其實(shí)沒必要。我們可以每天為他們做這件事。

再比如財(cái)務(wù)在結(jié)算后勤人員工資的時候很多計(jì)算公式都是相互關(guān)聯(lián)的，比如A=B C，D=A*E B-C，但是都是按照D=(B C)*E B-C來計(jì)算的，暫且不管他們的部門管理。如何管理流程，但是PM遇到這樣的業(yè)務(wù)流程，就要考慮能否結(jié)合產(chǎn)品設(shè)計(jì)簡化流程，實(shí)現(xiàn)產(chǎn)品設(shè)計(jì)的初衷，同時也簡化流程。

3:離散需求整合

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

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

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

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

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