如何做需求分析？從不同的方面入手：第一、用戶需求，挖掘用戶真實的需求，看看用戶是想造一艘航空母艦還是想造一艘捕魚的船；第二、產(chǎn)品自身的客觀需求，客觀需求，目前市面該同類型的產(chǎn)品進(jìn)行對比和挖掘，比如市面

如何做需求分析？

從不同的方面入手：

第一、用戶需求，挖掘用戶真實的需求，看看用戶是想造一艘航空母艦還是想造一艘捕魚的船；

第二、產(chǎn)品自身的客觀需求，客觀需求，目前市面該同類型的產(chǎn)品進(jìn)行對比和挖掘，比如市面上的產(chǎn)品都是一條捕魚的船，那客戶的需求就要降低；

第三、自身需求，對比用戶的時間、進(jìn)度、預(yù)期效果、比如客戶只給了造一條小船的錢，缺想造航空母艦，不現(xiàn)實的。

如何做需求分析？

1:抓核心點，不是所有用戶訴求都是需求

我們每做一個項目迭代或者新項目一定有目的，而需求分析階段，需求采集渠道中的需求往往是零散的、無重點的、邏輯性不強(qiáng)的，所以我們需要從這些離散的需求點中要抓住核心，梳理實際使用場景去分析問題，所有的核心點一定是以最終目的為導(dǎo)向的，不是所有用戶訴求都是需求。

以我的項目為例，由于歷史原因，自配送人員關(guān)系沒有進(jìn)入OA系統(tǒng)，所以配送員工資結(jié)算數(shù)據(jù)只能做進(jìn)配送系統(tǒng)，相當(dāng)于是一個簡單考勤記錄，其實最早之前系統(tǒng)是有這個功能的，但是由于之前沒有仔細(xì)整理需求，導(dǎo)致這個功能白做了，所以這次我接手幾乎從做，我以為這個事情比較簡單就讓一個產(chǎn)品助理先去整理需求，當(dāng)把原型圖出出來時發(fā)現(xiàn)并不能解決結(jié)算工資的功能，只是一個簡單的排班。

所以，當(dāng)時我就跟那小兄弟說，你這東西只是完成了排班，然而排班的目的為了結(jié)算工資這還不能滿足需求。所以我跟他強(qiáng)調(diào)，我們做這個需求的目的是為了考勤，諸如請假、值班、加班工時、輪休日加班等數(shù)據(jù)要能提供出來，他的第一版原型其實沒有充分了解到我們?yōu)槭裁匆鲞@個排班功能，所以在了解需求過程中沒有抓住核心點，導(dǎo)致需求不明確。

2:制定規(guī)則、改善復(fù)雜流程

我的上一家企業(yè)做的是互聯(lián)網(wǎng)電商，其實在我看來電商和O2O有很大的區(qū)別點就是電商在當(dāng)下盛行的情況下已經(jīng)變的很有規(guī)則了，首頁、產(chǎn)品列表頁、詳情頁、下單頁等等，每個頁面展示的信息也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個標(biāo)桿行業(yè)，另一方面是O2O與日常生活聯(lián)系的太緊密，落地下來就是很復(fù)雜的業(yè)務(wù)流，這些是to C產(chǎn)品的規(guī)則化和流程化，而流程化的東西在to B產(chǎn)品上體現(xià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)的都知道當(dāng)一個業(yè)務(wù)不是規(guī)則化時很難用產(chǎn)品去滿足用戶，所以我們有必要制定規(guī)則，或者優(yōu)化不完善、流程復(fù)雜的

規(guī)則。

下面說說制定規(guī)則，其實統(tǒng)一規(guī)則有利有弊，舉個例子，滴滴打車的訂單是搶的，uber打車的訂單是系統(tǒng)自動分配的，滴滴那種做法能提高司機(jī)積極性、自主性，司機(jī)可以選擇高金額的訂單，但是這種做法也會影響用戶體驗，比如說萬一以后不補(bǔ)貼了，我只是一個起步價，有些司機(jī)就不愿意接單，要等待很久；而uber打車制定了自動分配的規(guī)則，先分配目前離乘客最近的空閑司機(jī)，如果他不接再分配給下一個，這種做法能不能滿足用戶我不說，我只說這種規(guī)則簡化了下單流程，司機(jī)和乘客只有兩個選項，接還是不接，坐還是不坐，司機(jī)如果不接，但他并不知道下一單能等到什么時候，訂單金額有多大？雖然司機(jī)間的積極性和自主性減少，但是對用戶來說體驗很好。

說完了制定規(guī)則，再說一下改善流程，我上面說了這種流程化精簡在to B產(chǎn)品上尤為明顯，很多人有個看法就是后臺系統(tǒng)反正是自己人或者其他企業(yè)人員用的，完成功能就行，沒必要做的這么便捷和細(xì)致，其實不然，優(yōu)秀的PM在這方面總能善始善終，因為在他們眼里一點點的產(chǎn)品優(yōu)化或者流程優(yōu)化能為企業(yè)帶來很多的效益，這個我有切身的體會。

之前做的多個項目，其中有兩個就是我在做需求的時候發(fā)現(xiàn)業(yè)務(wù)部門在實際運(yùn)營中思維定勢或者每日重復(fù)做屬于他的工作，但是他們并沒有發(fā)現(xiàn)這樣做其實效率很低，在沒人觀察流程有問題的時候，業(yè)務(wù)部門已經(jīng)形成規(guī)范，但是這種規(guī)范并不是最優(yōu)的，當(dāng)PM做需求分析的時候需要細(xì)致觀察他們部門或者個人的工作內(nèi)容，想一想為什么這么樣做，有沒有其他方案能提高其工作效率。

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

還有個例子是，財務(wù)在結(jié)算物流人員工資的時候很多計算公式是相互關(guān)聯(lián)的，比如說A=B C，D=A*E B-C，然而他們就計算成D=(B C)*E B-C，暫且不說他們部門管理流程怎么樣，但是PM在遇到這樣業(yè)務(wù)流程的時候結(jié)合產(chǎn)品設(shè)計考慮是否可以精簡流程，實現(xiàn)產(chǎn)品設(shè)計的初衷的同時也能簡化流程。

3:離散需求整合

在和業(yè)務(wù)部門打交道的時候發(fā)現(xiàn)他們的思維邏輯性可能稍微差點，在PM了解需求的時候業(yè)務(wù)人員或者用戶表述的沒有前因后果，也就是沒有邏輯性，這時如果PM不追問下去自己很容易被帶到坑里面，合格的PM應(yīng)該在這種情況下峰回路轉(zhuǎn)，把問題再闡述一遍，如遇到稍微強(qiáng)勢一點的PM，此時應(yīng)該會指出剛才的表述有錯誤。

還有的業(yè)務(wù)部門人員在你去溝通的時候嘩啦啦的說了一大推產(chǎn)品改進(jìn)意見或者新需求想法，此時PM應(yīng)該細(xì)心聆聽，記錄下需求點，千萬不要給他們答復(fù)這個功能什么時候做、什么時候上線，因為系統(tǒng)永遠(yuǎn)是不完善的、需求卻永遠(yuǎn)是數(shù)不盡的，而資源是有限的，你給的答復(fù)實現(xiàn)不了別人會有不好的看法，優(yōu)秀的PM需要大局觀，能夠和團(tuán)隊一起評估需求優(yōu)先級，規(guī)劃產(chǎn)品生命周期，這才能推進(jìn)產(chǎn)品迭代。

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

現(xiàn)在很多互聯(lián)網(wǎng)公司基本上都是產(chǎn)品驅(qū)動，很難說技術(shù)驅(qū)動，因為產(chǎn)品團(tuán)隊可以知道用戶想要什么，我在參與需求分析過程中事業(yè)部技術(shù)負(fù)責(zé)人喜歡跟著我一起去了解需求，這在我之前的工作組中沒遇到過，現(xiàn)在做需求的時候他參與進(jìn)來后我發(fā)現(xiàn)整個產(chǎn)品需求被亂了，阻礙了我需求分析進(jìn)度，因為他總是以技術(shù)的角度考慮這樣實現(xiàn)的難度，由于他是技術(shù)負(fù)責(zé)人，邏輯思維能力很強(qiáng)，每當(dāng)聽到這個數(shù)據(jù)沒有需要新增一個入口去維護(hù)時他就站出來說為什么要這樣做，然后勸說業(yè)務(wù)部門說這個數(shù)據(jù)提供不了，能不能先不做。

但是從產(chǎn)品角度上考慮，既然選擇做這個項目那么就該從產(chǎn)品角度去設(shè)計好，等一整套產(chǎn)品方案出來之后再去精簡功能是一個很好的方法，還有一些情況是當(dāng)有一個比較好的idea產(chǎn)生時技術(shù)人員會首先考慮能不能實現(xiàn)、實現(xiàn)的復(fù)雜度，如果有一點困難或者技術(shù)可行方案不能當(dāng)場給出時，這個功能就暫且擱置了，也許就會提出另一個不會錯但是并不是最好的方案，所以技術(shù)人員參與需求分析階段最容易把原本一個好的產(chǎn)品扼殺在搖籃之中。綜上考慮，我的理解是技術(shù)人員在需求分析階段暫且不要參與進(jìn)來，等產(chǎn)品團(tuán)隊內(nèi)部討論之后技術(shù)團(tuán)隊參與審評，這樣也許能達(dá)到事半功倍的作用。