需求分析可以說是產品經理最常見的工作之一了，無論是新產品的上線還是產品迭代都離不開需求分析。需求分析決定著產品的研發(fā)和迭代方向，一旦出現偏差就會和用戶的真實需要背道而馳，因此掌握正確的需求分析方法論也就特別重要。作者就需求收集到需求落地過程中，應當如何完成需求分析才能夠更全面展開分析，一起來看看。

什么是需求呢，用最簡潔描述其實就是用戶在一定場景下尚未解決的需要。用戶，場景和需求內容三者缺一不可。從開始的用戶需求到最后的產品需求，背后有一個需求分析的過程。

不同的產品經理所采用的需求分析方法和流程并不完全一致，段位越高的產品經理分析流程可能越簡約。但基本的宗旨都是一致的，那就是發(fā)現用戶最本質的需要，進而提供相應的產品功能去滿足它，為用戶創(chuàng)造價值。

本文嘗試歸納一種普遍性的需求分析流程，可以快速地運用到工作中去。

一、需求來自哪

在需求分析前，需要先了解我們接收得到的需求一般來自哪。按照主動性劃分，需求可以分為被動來源和主動來源。

被動來源就是來自于老板，用戶以及運營等產品相關崗位的反饋。

主動來源的渠道就很多了，主要包括定期的用戶訪談、運營數據分析、競品動態(tài)追蹤、內部會議研討等。

不管是來自于哪種渠道的需求，都要將其沉淀到需求池中，并進行需求分析。

因為工作情景中的需求大部分來自于用戶，因此本文也主要以用戶需求分析為主，其中部分內容同樣適用于其他需求來源主體。

二、需求分析方法論

1. 需求是什么

需求是什么，也就是用戶對需求的描述。這里有兩點需要注意，一是要收集來自于用戶的客觀需求，所謂客觀，就是產品經理不能引導用戶說出自己的需求。

第二就是確保需求描述的完整性，這種需求發(fā)生在什么場景，用戶的具體需要是什么。需求一定是和場景結合的，脫離了具體場景的需求也就喪失了其價值。

2. 為什么會產生這種需求

在接收了用戶需求具體內容之后，產品經理需要分析為什么會產生這種需求。了解了原因之后，其實也就為下一步的產品研發(fā)或迭代指明了方向。

但就是這一步其實對產品經理的定性能力要求很高。“用戶需要的是汽車，而不是一匹更快的馬?！备Ｌ匕l(fā)明汽車的故事相信大家都已耳熟能詳。在與用戶的交流中，想要洞察用戶表面需求背后的底層動機并不容易。

最容易想到的角度就是馬斯洛需求層次理論，可以從這個角度來思考用戶提出的需求是否契合其中一點。馬斯洛把需求從低層次到高層次分別為七個層次：生理需求、安全需求、歸屬與愛的需求、尊重需求、認知需求、美學需求、自我實現的需求。例如用戶希望自己的抖音賬戶可以設定為私密賬戶，其實就是為了滿足安全需要。

除了最底層的需求層次理論以外，也可以思考該需求能滿足用戶什么欲望，例如被激勵，收集控，強迫癥，利益相關，新鮮感等等。例如用戶希望app可以有成長體系，就是滿足自己的被激勵需要。

一款好的產品是一定能夠滿足人性或者是欲望的。

第二可以從角色—場景—路徑的角度來分析，用戶的同樣的需求，換個用戶是否存在，換個場景是否成立，改變使用路徑是否存在？如果是，那么這個需求就是用戶、場景或者是路徑決定的需求。例如各大app出現的老年人模式，各種音樂app出現的車載模式，根據查詢單號自動帶出對應的快遞公司等。

第三可以從更為宏觀的系統運行的角度來思考，用戶的需求是否是為了提升效率，節(jié)約時間，促進系統生態(tài)的完善，或者是解決當前用戶使用階段/業(yè)務階段出現的問題等（這里需要思考僅靠產品能否解決問題）。

例如用戶說它需要更快的馬車，背后實際上是對效率的渴求，網易云音樂推出評論的功能，除了滿足用戶的自我呈現需要，從系統生態(tài)的角度來看，信息接受和信息傳播一同才能構成完整閉環(huán)，否則用戶只聽到經典的音樂而感慨萬千，卻無處釋懷。

總而言之，在傾聽了用戶的需求之后，需要從多個角度洞悉用戶需求背后的深層次原因，這樣才能讓產品準確解決用戶痛點。

3. 需求做不做

收集了需求，也弄清了需求的背景和原因，那么這個需求到底要不要做呢？

這需要從多個層面來考量：

（1）用戶層面

首先要思考的是這個需求解決了用戶哪些痛點？這個需求是否具有高頻性，是否是強需求？例如每天都要吃飯，這是強需求，每天都要刷2次牙，這是高頻需求。如果用戶提了一個需求，既不高頻，又不屬于強需求，就要考慮到底要不要上線該需求。

再則是從用戶體驗的角度，這個功能實現前后用戶的使用路徑會發(fā)生改變嗎，這個需求會犧牲用戶體驗嗎，如果是以犧牲用戶體驗為代價的需求，也需要權衡。

最后是思考它是不是個“偽需求”?！皞涡枨蟆本褪呛袈曌顬閺娏?，但上線發(fā)現其實并沒有什么人用，效果并不理想的需求。之所以會產生這樣的現象是因為，互聯網時代聲音由“沉默”轉向了“沉沒”，很多用戶的聲音我們其實并沒聽到，表面上很大的聲浪遠不能代表大部分人的想法或者需要。要避免“偽需求”，需要做細致的用戶調研。

（2）產品層面

先定位開始說起。產品經理應該始終明晰自己產品的定位所在，一切需求都要的服務于產品的當前定位。例如你不能因為司機在等紅燈時無聊，就要求滴滴打車上線游戲功能。

這里需要注意的是，有的需求可能符合產品定位，但不是產品當前階段要做的事情，也需要排除。例如在產品冷啟動階段，應該聚焦于核心使用路徑與核心需求，其他需求即使合理，但也不是當前階段應該做的。

其次要考慮的是，現有產品功能是不是從側面也可以滿足用戶所提出的需求。例如很多人呼喚微信語音進度條，但是微信的語音轉文字方案，在大多數場景下其實從側面就能替代語音進度條。

最后還要從整體的角度思考新需求是否會影響產品設計語言。例如淘寶上線直播的功能，這就需要從設計語言的角度對產品進行重構。因為直播是個大風口，所以這樣的需求不得不做。但是其他的需求如果影響整體設計語言，勢必也要仔細思考一番。

（3）商業(yè)化層面

商業(yè)化層面主要需要考慮市場規(guī)模，商業(yè)模式和成本預算方面的問題。小的功能性需求其實并不需要考慮市場規(guī)模和商業(yè)模式這樣長遠的問題。但是一個大的功能上線，就要考慮到它的引流效果，可能帶來的盈利增長點。例如抖音在其app中上線“抖音商城”，這是一個非常大的動作，必然要考慮到市場規(guī)模，商業(yè)模式這些問題，正是電商市場空間遠未飽和，所以字節(jié)才開始布局。

無論是什么需求都需要考慮成本預算。這里的成本分為研發(fā)成本與非研發(fā)成本。研發(fā)成本很好理解，非研發(fā)成本主要包括用戶教育成本，內容是否需要人工審核，以及各種運營推廣成本等，非研發(fā)成本其實就是如何讓用戶喜歡上這個功能的成本。王堅老師在《結網》一書中有提到，一般而言可以按照研發(fā)成本占20%，非研發(fā)成本占80%進行測算。

（4）內外部資源情況

巧婦難為無米之炊。需求做不做有時候也不是自己能決定的。

產品經理針對當前需求需要思考，哪些核心資源是已經具備的，哪些是欠缺的。如果當前相關資源欠缺，需要外部的合作伙伴嗎，如何進行協調溝通，這些都要思考全面。

拿到一個需求，放到上面這些維度進行考量，可以解決大部分的需求做不做的判斷性問題。但是有的時候，可能并不需要這么復雜，就一句話，老板要你做，你能不做嗎？

4. 需求做什么

如果把需求進行劃分的話，無非就兩種，別人已經做過的需求和別人沒有做過的需求。如果是做別人沒有做過的需求，我們直接進行大刀闊斧的創(chuàng)新就可以了。但創(chuàng)新畢竟是少數，很多時候我們做過的東西別人早就有類似的概念出來了。像微信這樣現象級的產品最初也是來自于Kik Messenger的產品概念。

有一句話講的特別好，不要重新發(fā)明輪子，因為沒有產生價值增值。那剩下的就是別人已經做過的需求了。雖然別人已經有了，那么我們也可以思考的是，能不能二次創(chuàng)造價值和放大價值？這才是關鍵。

可以的創(chuàng)新點有其實有很多，比如說更新的體驗，更新的技術，更好的商業(yè)模式，更適合的時機，更強大的平臺，更完善的管理。例如同是短視頻平臺的美拍和抖音，抖音賦予了用戶全新的體驗，同時電商，有人To B，有人To C，有人To B2C，這就是商業(yè)模式的不同。

之前我就特別不理解，為什么新浪要打造一個酷似Instagram的綠洲？后來對比使用發(fā)現，綠洲確實更符合國人的社交媒體使用習慣，而且國內缺乏圖片社交app，依托于微博平臺的強大引流，是很有前景的。也就是說，綠洲的產品需求源自Instagram的概念，但是卻賦予了它很多的創(chuàng)新，這也未嘗不可。

此外，對于一些細小的功能性需求，比如說腦洞大開的微信消息置底功能，因為它比較具象，就不太適合從更新的體驗，更新的技術，更好的商業(yè)模式等角度來分析。這種情況可以借鑒HWM思考方法，它主要適用于頭腦風暴前去尋找解決問題的方向，擴展我們的思路。 HWM思考方法主要包括否定，轉移，積極，腦洞，分解幾個部分。

就拿微信消息置底功能來說，這個需求本質是用戶需要保護隱私，從“轉移”角度來看，那可以出一個聊天框不顯示的功能，或者是聊天框自主排序的功能，就不需要了置底這么奇葩的功能了。從“腦洞”的角度來看，當用戶頻繁刪除與一個人的聊天記錄時，下次退出聊天會主動提示是否隱藏與該用戶聊天記錄，或者推出閱后即焚的功能等等。

5. 需求怎么做

（1）優(yōu)先級排序

在工作場景中，同時會有許多需求需要做，這時候就需要對需求進行優(yōu)先級排序。常見的方法有KANO模型，四象限法則和金字塔型劃分。

① KANO模型

在卡諾模型中，將產品功能/需求和服務的特性分為五種屬性：必備屬性、期望屬性、魅力屬性、無差異屬性、反向屬性。

魅力屬性：用戶意想不到的，如果不提供此需求，用戶滿意度不會降低，但當提供此需求，用戶滿意度會有很大提升；

期望屬性：當提供此需求，用戶滿意度會提升，當不提供此需求，用戶滿意度會降低；

必備屬性：當優(yōu)化此需求，用戶滿意度不會提升，當不提供此需求，用戶滿意度會大幅降低；

無差異屬性：無論提供或不提供此需求，用戶滿意度都不會有改變，用戶根本不在意；

反向屬性：用戶根本都沒有此需求，提供后用戶滿意度反而會下降。

KANO模型需要進行相應的用戶調研，計算出相應的better-worse系數值，以確立需求的優(yōu)先級。一般情況而言，在產品設計時，要盡量避免無差異屬性、反向屬性，著力抓住用戶的核心需求，解決用戶痛點，即基本型需求，在確保基本需求解決的前提下，為用戶提供興奮點，即期望屬性與，魅力屬性。

② 四象限法則

四象限法則將需求等級劃分為：重要緊急，重要不緊急，不重要不緊急，不重要但緊急。

這里主要是涉及到兩個判斷標準，重要性和緊急性如何判斷。緊急性很容易，主要看時間寬度，離deadline很近，那就很緊急。重要性則有根據產品的不同規(guī)劃，依據實際工作場景確定，例如是否關乎核心功能使用，是否破壞了用戶體驗，是否影響產品商業(yè)化等等。

對于第一象限的事情，需要盡快分配資源，抓緊完成。

第二象限的事情，需要花80%的時間在上面的，精細化處理好。如果不及時處理完，就堆積到第一象限。

第三象限和第四象限相對來說是不重要的事情，但是它們也是需求，可以每天花費一定的時間，統一去處理。要注意這類需求要和第一第二象限的嚴格區(qū)分開來，不能因為邊緣任務影響主線任務進展。

③ 金字塔型需求

金字塔型劃分需求，將需求從下到上劃分為四個模塊：可用性、更佳體驗、可擴展能力、生態(tài)。

其中可用性和更佳體驗，是整個產品的最為基礎的部分，更高層的可擴展能力，生態(tài)。都是在這基礎上建構的。這種劃分非常清晰，產品經理可以直接定位手頭需求屬于哪個層級，進而進行需求優(yōu)先級安排。

（2）關鍵任務安排

根據劃分出來的優(yōu)先級，產品經理就要協調各方技術資源進行關鍵任務分配了，產品，UI，研發(fā)，測試團隊共同合作，完成需求上線，最終向用戶傳遞價值。當然最主要的還是前面的需求分析的過程，到這里關鍵任務安排，很多產品經理應該都是輕車熟路，就不再贅述。

三、結語

我們梳理出了需求分析的一般流程，從用戶需求表達，需求背后原因追溯，需求要不要做，到需求做什么，以及怎么做。

但是在實際工作中可能并不需要思考這么多，或者這么多的流程可以放在一起進行綜合考量，尤其是對于資深產品經理來說，有的時候需求分析不僅是理性的思辨，更閃耀著感性的靈光。

總而言之，要了解條條框框，但也不能被條條框框所限制。

作者：我的鞋子大了，微信公眾號：青芒產品筆記，定位于個人產品學習成長平臺

本文由 @我的鞋子大了 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議