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

編輯導語：做產品離不開對需求的分析整理，當我們面對海量的需求該如何面對，如何處理，如何提煉出真需求來作為做產品的核心鏈。這篇文章從需求分析的定義出發(fā)，用四步法來教大家搞定需求分析關鍵節(jié)點。一起來看看吧。

這個需求做還是不做？這是產品經理日常需要做的選擇。

每天都有需求從不同的地方來，甚至都無法知道什么時候會來，但是你知道需求一定會來。

那怎么判斷需求是不是值得做？這就要做需求分析了，可見需求分析也是一門基本功。

我們今天就聊一聊需求分析，希望對大家有所啟發(fā)。

一、什么是需求分析

需求分析也稱為軟件需求分析、系統(tǒng)需求分析或需求分析工程等，是開發(fā)人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統(tǒng)必須做什么的過程(百度百科）。

關于需求分析的說明最重要的就是前文的最后一段“將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統(tǒng)必須做什么的過程?！?/p>

這段話說明了幾個情況：

• 一是需求通常來源于用戶；
• 二是用戶在表達需求的時候是根據自己的習慣表述的，是不完整甚至是隱含的，需要產品經理進行深入分析和定義；
• 三是在用戶表達了需求以后，從系統(tǒng)層面需要給出具體的方案，幫助用戶解決需求問題。

當然需求雖然是來源于用戶，但有可能不是直接來源于用戶，可能是經過業(yè)務部門轉述過來的，也可能是數據分析得來的。

實際上日常產品經理在正式開始做需求方案之前都會做需求分析，所以算是一個常規(guī)技能。

接下來我們具體講一下需求分析的三個步驟，只有完成全部三個步驟才算一次需求分析完整的結束了。

二、需求真實性的判斷

第一步先做需求真實性的判斷，如果是一個不真實的需求其實就沒有必要做后續(xù)的分析。

一個需求是否真實通?？梢酝ㄟ^回答以下四個問題來判斷：

1. 用戶是誰？
2. 需求場景是怎么樣的？
3. 用戶遇到的問題是什么？
4. 用戶想要解決的實際需求是什么？

以上四個問題對應了用戶、場景、挑戰(zhàn)和目的，能夠回答以上四個問題是判斷需求真實性的前提，即如果無法表述前面的問題就可以判定這不是一個真實需求。

我們舉個例子做一些說明：

知乎上有個問題是這樣的，淘寶下訂單后為什么不可以更改送貨地址？

我們按照前面的問題框架回答一下：

• 用戶是誰？淘寶上購買商品的用戶。
• 需求場景是怎么樣的？送貨地址填錯了或者選錯了。
• 用戶遇到的問題是什么？淘寶無法修改送貨地址。
• 用戶想要解決的實際需求是什么？讓購買的商品送到正確的地址。

非常清晰，所以對于地址填錯了的淘寶用戶來說需要修改送貨地址是一個真實的需求。

我們再舉一個例子：

手工耿曾經做過一個物品，用處是在地震發(fā)生時能夠保證這個碗不被打翻，能夠繼續(xù)吃泡面。

我們還是按照前面的問題框架回答一下：

• 用戶是誰？肚子餓了，想吃泡面的人。
• 需求場景是怎么樣的？在地震發(fā)生時正在吃泡面。
• 用戶遇到的問題是什么？地震發(fā)生了需要躲避危險。
• 用戶想要解決的實際需求是什么？保證自己的生命安全。

大家注意到沒有，在地震中用戶的最優(yōu)先的需求是保證自己的安全，如果是地震發(fā)生，大地還在晃動，誰還有心思吃泡面。

所以用戶和場景都對，吃泡面這個需求雖然存在但是不是第一需求，第一需求是安全，那么所謂的解決方案當然不對。

注意：我在這里說的是需求的真實性，而不是判斷需求的真?zhèn)?，我看了一下市面上很多寫用戶需求分析的文章，都在說偽需求的問題，他們中的絕大部分都把需求的理解不對或者需求的價值也歸在偽需求里面，我認為這是非常不對的。

有名的一個例子是大家想要一匹更快的馬的需求，福特把他解讀為需要更快的速度就做出了福特汽車。

注意這個例子，福特變更了解讀的角度，更接近需求的本質，所以福特勝利了，但是這并不能說想要一匹更快的馬是一個偽需求，想要一匹更快的馬也是一個真實的需求，如果把這個時間拉到工業(yè)革命以前，當時的技術水平根本無法造出汽車，那你說這是不是一個真需求？

所以不要把不同的問題混為一談，都把它們歸類成偽需求，這是非?；闹嚨淖龇?。

三、需求價值的評定

需求真實性判斷完成之后就需要去判斷需求的價值。需求價值的大小由以下幾個維度來確定：

• 用戶廣度：該需求的受眾面有多大？
• 使用頻率：該需求的使用頻率是以日/周/月為周期？
• 剛需程度：該需求對用戶有多強烈需要？
• 生態(tài)影響：對平臺其他參與方的影響。
• 產品時機：該需求是否符合產品的規(guī)劃，當下的環(huán)境？

我們還是以前面那個淘寶的例子來說明——淘寶下訂單后為什么不可以更改送貨地址？

1. 用戶廣度

該需求的受眾面有多大？

具體數據我肯定不知道，但是應該還是蠻多人遇到過這個問題，假設為10%吧。

2. 使用頻率

該需求的使用頻率是以日/周/月為周期？

頻率肯定很低，大概上百次里面才會有那么一兩次，從頻率上來說大概一年也就一兩次，這是從一般用戶的角度來說，購買頻次越高這個功能的使用頻率也可能更大。

3. 剛需程度

該需求對用戶有多強烈需要？

用戶遇到這個問題的話當然是希望能夠修改地址，但是沒有這個功能好像負面也不是很大，可以客服聯(lián)系商家修改，或者去送達的地方取一下貨，對于大部分用戶來說地址不是住的地方就是公司，有的時候換住址或者公司可能出錯，但是去取一下也還行。

4. 生態(tài)影響

該需求對平臺各方產生的影響是怎么樣的？

對于購買用戶來說其實不會因為這個問題就離開，畢竟和平臺帶來的便利性比較，這么一兩次挫折不算什么。

對于商家來說，如果允許修改就會是個非常大的麻煩。

我們來具體分析一下：

如果允許用戶修改會發(fā)生什么情況呢？

可能有兩種情況，一種是商家發(fā)貨了，一種是商家沒發(fā)貨。

發(fā)貨了就不說了，修改也沒用，因為貨都在路上了，不可能更改地址，快遞公司也沒有這樣的流程。

如果沒發(fā)貨那么可能會出現(xiàn)兩種情況，一種是商家還沒有備貨，一種是已經備貨提交快遞單給快遞公司了。

如果沒有備貨還好說，如果已經提交了快遞單那就很麻煩了，修改數據是簡單的，問題就是你需要把這個訂單對應的貨品找出來然后把快遞單換一下，這個找的過程是很耗費商家時間的，因為有可能商家一天發(fā)幾千件貨，花時間更換地址就會導致發(fā)貨效率降低，如果要保持效率就需要話更多的人工成本，這對商家來說肯定是不希望的，因為錢賺少了。

如果允許修改則商家每天都要處理這個事情，不友好程度就很高了，商家不會馬上走但是可能會把重心遷移到其他平臺，這樣整個淘寶生態(tài)就慢慢變差了，這個肯定是淘寶難以承受的。

所以從生態(tài)的角度來說這個就是負向價值非常大的一個用戶需求。

商業(yè)價值：該需求對于業(yè)績的價值是怎么樣的？

基本沒有商業(yè)價值，因為改了之后并不會增加業(yè)績。

產品時機：該需求是否符合產品的規(guī)劃，當下的環(huán)境？這個倒是沒所謂。

所以綜合起來看這個需求的價值對于淘寶就是負面的，淘寶肯定不會做這個功能。

我在舉例說明的時候用的都是定性的說明，如果想要做成定量的分析，那么可以給每一項做一個打分表，譬如1-10分，然后給每一項賦予不同的權重值，譬如都是20%，這個根據需要調整就是了，最后統(tǒng)計綜合得分，根據綜合得分判斷需求價值。

判斷需求價值是為了決定做不做的問題，如果需求價值不大甚至需求價值為負那就不用列入計劃了。

四、需求優(yōu)先級的評定

按照我們的經驗來說，需求不可能只有一個，它們廣泛的來自于領導、用戶、業(yè)務部門和產品部門自身，所以有十幾個或者幾十個需求是很正常的，這個時候就涉及到對需求優(yōu)先級的判定問題，公司的資源總是有限的，所以不可能所有需求都在第一時間投入資源，優(yōu)先級的判定就是解決資源如何投入的問題。

1. 需求的優(yōu)先級如何判定呢

對于優(yōu)先級的判定主要是基于前面的需求價值和需求成本-指的是實現(xiàn)這個需求需要投入的資源，這就是一個衡量性價比的過程。

一般類似會把需求價值和需求成本分成低、中、高三等，交叉之后分為優(yōu)先級最高、優(yōu)先級次高、優(yōu)先級一般和不做四個部分。如下圖：

優(yōu)先級最高一般劃為P0和P1，優(yōu)先級次高劃為P2和P3，優(yōu)先級一般就劃為P4。

特別說一下，有些公司把優(yōu)先級劃的特別細，分成好多等級，其實沒必要。太細了浪費時間分。

五、需求池管理

需求池的管理是最后一步，也是最重要的一步，把從各方收集來的需求、經過前面的分析之后篩選出來的需求匯集到一起，記錄在冊方便管理需求和后續(xù)的版本規(guī)劃，也方便追溯產品方向的迭代。

需求池的基礎信息主要包含：編號、模塊、功能點、需求描述、場景描述、需求類型、優(yōu)先級、提出人、提出時間、當前狀態(tài)、備注。

編號：需求的唯一標識，編號的規(guī)則可以自行定義，最簡單的就是日期+自增數，作用是作為每條需求的唯一編號和快速查詢需求。

模塊：根據產品模塊去劃分，作用是將需求統(tǒng)一歸類到某個模塊下，在進行版本規(guī)劃時，可以優(yōu)先從某個模塊中篩選，同時便于根據模塊查詢。

功能點：簡單描述需求的功能，也就是要做什么，這樣我們快速查看某個需求時，能一眼看明白這個需求是要新增或修改哪個功能。

需求描述：需要描述清楚需求的完整性、一致性，需要精準的描述。如果產品經理在后續(xù)想不清楚這個需求到底要做什么，可以通過需求詳細描述來回想或了解。

場景描述：了解用戶在什么場景下產生的需求，在給開發(fā)轉述為什么要增加這個需求時，可以清晰的說明是因為哪些原因，更能說服開發(fā)愿意做這個需求。

優(yōu)先級：從P0-P4，優(yōu)先級依次下降，優(yōu)先級可以幫助產品經理在做版本規(guī)劃時判斷應該先做哪些需求。

開發(fā)量：需求的開發(fā)工作量，可以通過這個信息規(guī)劃開發(fā)每個版本的工作內容，也方便我們了解每個需求的開發(fā)難度。

提出人：原需求的提出人，便于日后有疑問可追溯。

提出時間：需求的提出時間，方便我們了解是什么時間提出的需求，同時可以利用提出時間來規(guī)劃需求的緊急程度。

產品對接人：具體是誰來負責對接和后續(xù)的產品設計，這個的話一開始沒有可以空著。

狀態(tài)：這個指的是需求的生命周期，待處理、設計中、開發(fā)中、已發(fā)布、暫緩（標注原因）；主要作用是可以對需求的流轉狀態(tài)進行跟蹤，可以了解需求在不同階段的狀態(tài)，發(fā)現(xiàn)問題及時調整。

備注：一些額外信息的記錄。

需求類型主要包含：

• 新增功能：目前平臺沒有實現(xiàn)的功能；
• 功能迭代：對目前平臺已實現(xiàn)的功能進行優(yōu)化；
• 用戶體驗：例如頁面按鈕擺放的問題，發(fā)送消息時發(fā)送按鈕放在右側，可以按照用戶的使用習慣設計；
• UI優(yōu)化：如整體產品色調的調整等，這個需要根據平臺調性去處理。

六、最后

需求分析其實不復雜，但是想要把握的準其實還是需要一些功力的，大家在做具體的需求方案之前不妨想一想這個需求是不是值得做。

公司資源有限，你的時間也有限，總要投入到那些能夠產生更大價值的需求里面去。

而選擇無疑是這個時代最重要的能力，那么在選擇之前的分析就無疑是基石，多練練這個技能，或許不止對工作有幫助。

如果你選擇做產品經理，那么祝你好運。

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

題圖來自 pexels，基于 CC0 協(xié)議