中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

需求分析是層層遞進的關系：過濾原始需求、舍棄無用需求、最后整合分類，確定需求優(yōu)先級。

各位產品經理，時間已經來到2020年，今年突如其來的黑天鵝的打得人類措手不及，任何事情都不確定，未來的環(huán)境唯一不變的就是變化。我想唯一可以做的就是不斷總結和積累，增加自己唯一握在手上可以確定的部分，在做產品經理的這兩年，經常面對需求分析，也經常翻看各大博主的需求分析策略。本文將結合實際工作的經驗，試圖總結出一套完整的2B需求分析思路和方法，希望給看到這篇文章的產品經理帶來一些啟發(fā)，在需求的不確定中獲得確定。

一、需求獲取

要分析需求，首要要弄清楚需求的來源，也就是你的需求從哪里來？

1. 獲取方式

總的來說獲取需求的方式有兩種：

1. 主動獲?。?、市場環(huán)境整體調研；2、競品分析3、問卷調研）
2. 被動接受，對于被動接受的需求，往往是???? 用戶直接提出的需求，通過意見反饋渠道或主動聯系產品溝通。

原則：明確目的采取不同的獲取需求方式

在實際過程中采用哪種方式來獲取需求？往往跟我們本身想要達到什么目的有關，時刻牢記一切從目的出發(fā)，當然獲取需求的方式不是3選1，也不是2選1，可以結合。

一般來說本身產品的迭代規(guī)劃往往采用競品調研分析、問卷調研的方式。產品的原始規(guī)劃往往采用市場環(huán)境調研、同類產品調研的方式在在每一項的具體方式中，根據自身的目的，調研的具體方式也不盡相同：拿問卷訪談來說，明確此次調研主要是為了產品優(yōu)化的體驗項，那么你設計的調研問卷更偏向于體驗的問題，對象也更多是實際操作者，如果此次調研的目的是為了整個產品的二次功能迭代，那么調研問卷更傾向于產品功能的延展或改善上的問題（一個原則“問卷調研更多的是調研”，所以在設計問卷的問題更多的是開放和引發(fā)思考的問題）

2. 明確調研對象

原則：窮盡你的調研對象—針對主動調研的方式

B端產品的訪談對象不同于C端，B端涉及到的用戶角色代表不一樣，同一套產品一般不止一個角色使用，他們有可能往往包含著矛盾的需求，為了使需求更全面更合理，那么根據調研的目的要盡可能的選擇包含相關所有的對象。

3. 明確需求

原則：多問為什么

無論是被動獲取還是主動獲取，在面對所有的需求時，都需要問自己或者問你的對象“為什么“，據說有一個產品經理思考問題的法則，就是無論任何事情，都連問6個為什么，要多問為什么？直到說清楚原因、講清楚邏輯，搞清楚環(huán)境、搞清楚原因的過程。

二、需求分析

當我們獲得了這些需求后，是不是馬上就開干了？答案當然是否定的，從產品經理視角看用戶：用戶不是自然人，而是用戶背后的需求合集，這有兩層意思：1是產品經理的最終對象是需求，2是需求的承載是人，它們具有異質性（特點千差萬別）、情境性（用戶的行為和反應會受情境影響）、可塑性（用戶的偏好和認知會隨著外界不同信息刺激發(fā)生變化和演化）、自利性（用戶追求個人總效用最大化）、有限理性（用戶雖追求理性，但能力是有限的），這就意味著，我們還要從已經獲得的原始需求里抽象分析、梳理整合出真正需要滿足的需求，然后找到產品可以做的地方，這才構成了我們作為產品經理和產品設計者的核心價值。

那么如何去做需求分析？需求的分析也是層層遞進的關系。

1. 需求過濾

面對原始需求，哪些才是我們需要去解決的，哪些不需要？ 而最終留下來的需求才是我們要去解決的需求。

需要解決的問題：需求要最終解決的是什么樣的問題？需求是正確的嗎？需求是真實的嗎？需求可以解決嗎？需求值得解決嗎？這幾個問題層層遞進，弄清楚這幾個問題，基本上我們的需求就能決定其去留了。

需求最終解決什么樣的問題？–需求定義

未經過訓練的人都不是抽象問題的專家，所以在提出他們的需求的時候，往往直接說出感受，或者給出解決方案。

如：小A對于聽歌軟件使用體驗感不好，提出了顏色不好看，這個地方字太小了，聽不到我想聽的歌，能不能把這個地方的顏色換成藍色呢？這往往是用戶直接表達的需求和使用體驗，這時候如果刻意做抽象，才能意識到用戶會在說布局不符合使用習慣；在用戶搜索要聽的歌時，連續(xù)翻了好幾頁都找不到，因此前幾頁的關鍵字匹配代表能否更快速的找到結果，所以產品要解決的是用戶關鍵字快速匹配的問題。

再舉個例子：小B提出每次做采購單都必須要有商品的編碼，太麻煩了，沒有編碼就要去找數據中心的人維護，能不能不要這個編碼？直接填說明？從表面上來看小B是想要解決商品編碼的問題，而實際上呢？經過詢問你會發(fā)現要解決小B的問題其實是維護流程繁瑣或編碼缺失的問題。而不是商品有沒有編碼的問題。

大多數人的需求和“要解決的問題”都是需要抽象和梳理的，所以我們要將用戶提出的需求，進行抽象。

另一個經典的例子就是：用戶說我需要一匹馬，經過分析抽象才知道用戶需求的不是一匹馬，而是一個能快速到達目的地的工具。

2. 需求舍棄

在明確定義需求需要解決的問題了，接下來我們要思考的是需求是真實的嗎？需求是正確的嗎？也就是說有沒有“價值風險”需不需要去解決。我們可以試著從以下幾個方向去思考：

（1）需求是否存在矛盾？

A要解決的問題和其相關的角色需求或現狀是否有沖突：這很重要，尤其是對于B端的需求來說，我們前面提到產品經理面對的需求往往是個人賦予在當前角色和環(huán)境下提出來的，人提出的需求都是利己的。比如：以剛剛小A提出這個按鈕放在這里太不方便了。那么我們抽象出來是要解決的小A的問題是布局問題，在經過分析小A是個左撇子，所以他這樣提，那么他的需求就和普通的一般人的需求是矛盾的，此時就應該平衡價值，是否應該舍棄掉這樣的需求。往往B端的產品需求會存在，角色于相關覺得之間的矛盾，與上級需求的矛盾，與整體公司管理需求的矛盾，與商業(yè)訴求的矛盾針對矛盾的需求，要理清矛盾關系，分清價值，大膽舍棄。

（2）需求是否只是解決了當時問題？

就是「產品做出來了，某些顧客也會用了，但后來都不繼續(xù)用，因為沒有滿足需求」的狀況，此類需求是否需要我們花力氣花成本去滿足？還是是否可以需要用戶麻煩一點。分清需求的長期價值，大膽舍棄。

（3）是否帶來了真實的價值？

有些需求可能是我們創(chuàng)造出來的需求，來源于我們自身認識的不足，比如我們認為用戶一條條刪除會很麻煩，想做一個批量刪除的功能改善一下，但實際上用戶批量刪除更容易導致錯誤刪除，而刪除的情況并不多，所以此類需求就是我們人為創(chuàng)造的需求。充分認識需求是否真實帶來了價值，大膽舍棄創(chuàng)造出來的不能帶來真實價值的需求。

（4）從需求的成本和價值檢視需求

此時需要考慮兩個問題：

1. 當前是真實的需求也能帶來價值且長期帶來價值，但手邊并沒有解決問題的技術，或技術尚未成熟，就是「我們知道要做什么產品，但是做不出來」的狀況，此類需求也只能暫時舍棄
2. 投入的成本是否大大超過帶來的價值：需求不是無邊界的，滿足超過一定邊界，邊際收益會驟降。絕大多數情況下，超過這個滿意的邊界，用戶的滿意度不會一點兒都不變，但變化程度會非常小。因此我們要關注這個邊界并且定義這個邊界。

3. 需求整理

（1）需求聚合

對于2B的需求往往都是以業(yè)務為導向的，著手去解決分散的需求，往往容易陷入點狀里面，此時需要以業(yè)務為導向指引將零散的需求串聯起來，形成一個完整，內容清晰的框架，以免落入拼命應付解決問題的境地。

找出哪些需求是哪些業(yè)務，并將其劃分不同的板塊，例如有些是采購申請的需求，有些事采購單的需求，他們又都屬于采購需求。其中需求1，2都歸屬哪條業(yè)務線上。

（2）需求分類

問題不分大小，不分場景，只要是需要解決的問題，都是需求，而需求扽分類有助于我們分清需求的優(yōu)先級，一般我會將需求分為：功能性需求、體驗性需求、二級分類是新增還是優(yōu)化；他們的重要關系一般是：功能新增>功能優(yōu)化>體驗優(yōu)化

（3）需求優(yōu)先級

在需求分類分級的基礎上，我們可以在定義其優(yōu)先級，這里就可以運用“痛點”、“癢點”或者馬斯洛模型等作為參考了，它們可以協助我們定義問題的大小即嚴重程度。對于2B需求來說，往往急需解決的痛點需求是少了這個功能業(yè)務無法開展，或者開展的十分困難。

結語

需求分析作為產品經理工作中核心的也是最重要的一環(huán)，其需要警示和思考的內容遠不止于此，如何運用并不斷改進是重中之重。

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

題圖來自Unsplash，基于CC0協議