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

如何做需求分析？

從不同的方面入手：

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

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

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

如何做需求分析？

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

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

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

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

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

我的上一家企業(yè)做的是互聯網電商，其實在我看來電商和O2O有很大的區(qū)別點就是電商在當下盛行的情況下已經變的很有規(guī)則了，首頁、產品列表頁、詳情頁、下單頁等等，每個頁面展示的信息也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個標桿行業(yè)，另一方面是O2O與日常生活聯系的太緊密，落地下來就是很復雜的業(yè)務流，這些是to C產品的規(guī)則化和流程化，而流程化的東西在to B產品上體現的尤為明顯，to B產品最經典的例子就是公司后臺系統(tǒng)。

不論是一個to C的產品還是to B的產品，我們都要考慮到用戶使用場景，PM需要把自己當作用戶，充分考慮各種情況下的用戶思維才能設計一個滿足用戶需求的產品，這里并不是一味的去迎合用戶，做互聯網的都知道當一個業(yè)務不是規(guī)則化時很難用產品去滿足用戶，所以我們有必要制定規(guī)則，或者優(yōu)化不完善、流程復雜的

規(guī)則。

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

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

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

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

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

3:離散需求整合

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

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

4:技術人員參與需求分析階段

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

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