從需求收集到需求落地，需求分析如何才能更全面？

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

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

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

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

一、需求來自哪

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

被動來源就是來自於老闆，使用者以及運營等產品相關崗位的反饋。

主動來源的渠道就很多了，主要包括定期的使用者訪談、運營資料分析、競品動態追蹤、內部會議研討等。

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

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

二、需求分析方法論

1。 需求是什麼

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

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

2。 為什麼會產生這種需求

在接收了使用者需求具體內容之後，產品經理需要分析為什麼會產生這種需求。瞭解了原因之後，其實也就為下一步的產品研發或迭代指明瞭方向。

但就是這一步其實對產品經理的定效能力要求很高。“使用者需要的是汽車，而不是一匹更快的馬。”福特發明汽車的故事相信大家都已耳熟能詳。在與使用者的交流中，想要洞察使用者表面需求背後的底層動機並不容易。

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

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

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

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

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

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

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

3。 需求做不做

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

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

（1）使用者層面

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

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

最後是思考它是不是個“偽需求”。“偽需求”就是呼聲最為強烈，但上線發現其實並沒有什麼人用，效果並不理想的需求。之所以會產生這樣的現象是因為，網際網路時代聲音由“沉默”轉向了“沉沒”，很多使用者的聲音我們其實並沒聽到，表面上很大的聲浪遠不能代表大部分人的想法或者需要。要避免“偽需求”，需要做細緻的使用者調研。

（2）產品層面

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

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

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

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

（3）商業化層面

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

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

（4）內外部資源情況

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

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

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

4。 需求做什麼

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

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

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

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

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

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

5。 需求怎麼做

（1）優先順序排序

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

① KANO模型

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

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

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

必備屬性：當最佳化此需求，使用者滿意度不會提升，當不提供此需求，使用者滿意度會大幅降低；

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

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

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

② 四象限法則

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

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

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

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

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

③ 金字塔型需求

金字塔型劃分需求，將需求從下到上劃分為四個模組：可用性、更佳體驗、可擴充套件能力、生態。

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

（2）關鍵任務安排

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

三、結語

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

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

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

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

本文由 @我的鞋子大了 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議