本文将需求分為兩類——工具類需求、用戶端需求；并進一步給出了兩個案例方便理解。

前言

關于需求分析無疑是産品經理的一項必備基礎功，也是每個産品經理可能工作大部分時間都在做的事情，但是絕大部分産品經理可能不會刻意的去總結一套方法論。總的來說不總結方法論也不會有多少問題，因為畢竟基本工作很熟手，但是總結了方法論并寫出來有以下幾個好處：

1. 指導自己工作，在自己不知該如何着手做一個需求的時候，可以為自己提供一個框架
2. 鍛煉自己的結構化思維及總結能力
3. 寫出來與自己對話能提高自己的認知，會獲得意想不到的收獲

個人平時也比較懶，偶爾會寫些東西，但是通常不能長久的堅持，也希望自己能慢慢堅持下去。

什麼是需求分析

個人對需求分析就是：确認終點尋找路徑的過程.

從這一定義來說需求分為2類：

• 第一類是終點比較明确，無太多争議性，此時的需求分析主要集中在尋找路徑。
• 第二類是終點不是非常明确、甚至是極為不明确，此時需要先确認終點再去尋找路徑。

第一類需求主要包括一些公司職能部門管理後台一些效率性工具、營銷工具等

如：财務管理、訂單管理、路由配置等，這類需求考驗的是産品經理的基本功，包括業務流程梳理、功能邏輯梳理、功能列表及細節，提供最終解決方案、優先級協調、方案拆解及叠代計劃等。

需要注意的是，這裡所說的終點比較明确是相對的，有些新人産品經理比較容易犯的錯誤是，業務部門提啥後台需求我就接啥。

這樣很容易導緻後續改改改，因為業務人員提的往往不是一個需求，而是一個解決了他們所認為的需求點的一個方案，産品經理一定要能識别需求和方案之間的差别，透過方案看到需求本身是什麼。

舉個簡單例子：運營人員提了個需求說，我想在推送配置界面裡加一個EXCEL導入推送人員名單功能。

這個需求看上去很合理，這樣運營就可以快速的導入推送人員名單了，但是仔細想想這是一個需求嗎？或者說這個需求本質是加一個EXCEL導入功能是産品的最終形态嗎？這個問題在這裡不做回答，後面會舉一個相類似的我在工作中遇到的實例。

第二類需求主要是一些用戶端需求

比如推出一個新的功能、一個新的玩法、對以前功能做優化。但是對于這個玩法究竟效果如何，大家都不能很确定。此類需求相對于第一類需求除了考驗産品的基本功以外還需要産品經理有規劃MVP（最小可行化産品）能力、數據分析能力等。

可能會有人提出還有第三類需求，就是現在啥都沒有從0~1打造産品。在這篇文章的場景限定下，此類不屬于一個需求，這是要做一整條産品線，這即需要産品經理對宏觀了解把握、對業務熟悉、對微觀的有掌控等能力，個人暫時沒有實力寫這樣文章，如果有同學想學習此類能力，推薦學習梁甯的《産品思維30講》、《增長思維30講》，後續個人也會嘗試着從自己的工作理解中來簡單談談

需求分析框架

需求分析框架用比較直白的話來說就是：值不值得做？做成啥樣子？怎麼來做？

值不值得做需要去分析目标和價值，做成啥樣子需要去梳理業務流程、分析使用場景、設計功能細節，而怎麼來做主要就是确認優先級、調整配置資源、完成叠代計劃，以下是個人總結的需求分析的框架圖：

嚴格來說，怎麼來做已經不屬于需求分析範疇，但是當面臨的需求比較大但是研發資源不足時候就需要考慮怎麼來做了，比如說優惠券系統，涉及到模闆創建、運營發券、用戶領券、用券、核銷、數據統計等，在研發資源不足業務有比較急需情況下，就需要将一整個大需求進行拆解，分多期來做。從這個角度來說也夠得着需求分析的邊

2個案例

以下是自己工作中碰到的2個真實的需求分析案例：

案例1：财務結算報表需求

業務背景：

公司甲為某小貸公司一級代理中介，其職能是為小額貸款公司尋找二級渠道客戶，用戶經二級渠道辦理業務，錢款直接打到小貸公司（由于業務法規限制，系統無法直接在用戶付款時候進行分賬），每月月末，小貸公司分賬給甲公司，甲再分賬給二級代理公司。

如下圖所示：

當時财務是這麼跟我提需求的大概是這麼說的——

“我需要一個2個結算報表頁面，兩個報表都有balabala字段，都要有個EXCEL導出功能。”

下面我們套用需求框架對此需求進行分析：

1. 目标分析：

此需求受衆是誰？——财務（廢話……）

是否影響其他人？——否

此需求目标是什麼？——是要一個列表嗎和EXCEL導出嗎？

顯然不是，因為前期分賬也有EXCEL，隻不過是研發從數據庫拉取的，她要的是能夠更效率的分賬與核賬，最終目标是“更效率分賬和核賬”。

此處必須要廢話一下，因為有的新人産品經理會真的直接按照需求方提的要求做出這麼兩個表格出來。

2. 價值分析：

此需求有無價值，價值幾何？很顯然有，隻不過是一個優先級問題，隻要沒有更高優先級需求這個需求肯定要做的，因為可以節約開發和财務雙方的時間。

3. 業務流程梳理：

可參見上圖，财務核心點就在于向上遊和下遊的結算、核賬。

4. 場景分析：

在這裡，因為這個是一個新項目，我不是太了解此條業務線結算場景，所以需要和财務進行了大概如下對話（這一步非常關鍵，知道怎麼用，才能設計好對應功能）：

我：你能簡單說一下你以後要怎麼用着兩張報表嗎？

财務：每個月月底小貸公司打款過來，然後我用“報表1”進行核對打款是否正确。每個月我根據“報表2”計算應付渠道多少款

我：那為什麼要拆成兩個報表？之前研發不是拉一張報表給你就OK了嗎？

财務：因為結算給渠道不能讓他們看到成本，結算給小貸公司，也不會給他看渠道成本，他們也不關心（已經獲得第1個結算場景全貌）

我：那我做一個報表給你，你再拆不一樣嗎？（這麼問不是為了偷懶，因為工作量差不了多少，主要目的還是旁敲側擊挖掘其使用場景）

财務：這樣也可以，但是有些麻煩，而且有的時候渠道方中途想核對一下月中數據是否一緻，此時不用導出EXCEL報表發過去，比較麻煩，直接截個圖對下數據就可以了（獲得了第2個使用場景）

我：除了對賬，表格對你還有其他幫助嗎？

财務：還會去統計每個渠道帶來利潤，看看渠道大體情況

我：那分成兩個表格你怎麼統計利潤？

财務：（财務有點支吾，估計之前沒考慮到）我可以自己再把表格合起來然後對賬（獲取了第3個場景全貌）

從以上的對話可以看出财務所提的方案，滿足不了她自己所有的使用場景需求，當然後續對話還有一部分是關于功能細節的，這裡不贅述了。

有的人可能會問，财務說的也對，兩個表格到時候她自己合起來對賬就OK了？

那麼首先這樣麻煩，容易造成錯誤不說，最關鍵的一個問題是，她如果要去做合表，必須保證後台所查出來的兩個表格數據排序是一樣的，否則就會造成數據對不齊！如果直接開發上線，後續就不得不面臨着一個問題——需求變更#@￥！￥%@%￥！%￥

5. 功能設計：

有了具體的使用場景，對業務了解，基本功能設計就不太會出多少問題了，這個産品形态很簡單。下面直接附上最終的交互稿：

至于後續的幾個步驟，在這個例子中不需要做，因為功能很簡單工作量小

案例二：優化認證轉化率

某小額貸款公司，整體業務流程為：用戶登錄注冊→認證獲取額度→申請→審批→打款

需求背景：

在該項目上線半年左右，業務已經逐步趨于穩定了。于是就琢磨着看能不能提高業務效率，在當時整體的認證轉化率在35%左右，憑直覺有很大的優化空間，于是就自己倒騰備庫，拉了一周的和認證相關的業務數與埋點數據，做出了下圖：

在這張圖上很容易看出進入頁面=》提交身份認證，聯系人1點擊=》聯系人2點擊，這2步跳變流失比明顯比較大，于是就有了“優化認證轉化率”的需求，套用需求分析框架。

1. 目标分析：

此需求受衆是誰？所有進入我們APP無特定屬性用戶。是否影響其他部門/人？應該不影響。此需求的目标是什麼？提高用戶進入認證頁到獲得額度的總體轉化率。

2. 價值分析：

此需求價值幾何？

簡單來算一筆賬，市場運營推廣費，平均一個注冊用戶在4~10多塊，我們就按照6塊來算，我們每天新注冊然後到認證頁面用戶在1W2左右，如果能将認證轉化率提高X%，那麼每天可以等價為公司節省下：

12000*[1-35/(35 X)]*6=72000*X/(35 X)元

（公式得來是因為我們要維持放款量是一定的，轉化率高了對應的拉的用戶量就可以減少，大家可以自己推算）

簡單代入，如果提高了1%，那麼每天可以為公司節省2000元左右推廣費，如果提高了5%呢？那麼每天就可以節省9000元，一個月就可以省下27W！！！的推廣費用。

3. 業務流程梳理：

此處應該說是問題分析了。第一步到第二步之所以跳失這麼高，大膽猜測原因：

• 1）騙貸用戶，身份證提交不了（因為身份證需要拍照，我們接了三方防僞，假冒身份證提交不上來）
• 2）未成年用戶（身份證年齡前端計算低于18歲就不給提交）
• 3）頁面采集用全部展開方式，信息太多，對用戶不太友好

緊急聯系人1→緊急聯系人2 仔細去用了，分析一下大膽猜測跳失率如此高的原因：

填寫聯系人系統需要讀取用戶通訊從通訊錄中選取，當初在設計時候為了提高用戶體驗就将授權分散在各個步驟，需要用到時候才授權。

此處猜測之所以聯系人2比聯系人1點擊跳變這麼大，可能是在聯系人1點擊時候，獲取用戶通訊錄授權讓用戶産生擔憂而造成大量流失。

參考了其他競品和世面上軟件，所有授權在用戶第一次進入APP之後就全部一起彈出。

4. 場景分析：此處無

5. 功能設計：

針對以上的猜測，做以下優化：

• 1）增加身份證照片上傳報錯上報埋點，将報錯原因上傳至後台
• 2）将提交身份證按鈕報錯也上傳（以前前端攔截不上傳），并上傳報錯信息
• 3）在用戶打開APP即獲取所有授權，減少用戶獲取聯系人時候

6. 優先級協調：

系統和業務已比較穩定，精細化運營優先級可以提高。

7. 資源協調：

依照6，隻要價值闡述得當，團隊認可，資源肯定到位，而且工作量很小……

8. 叠代計劃（重點闡述一下）：

• 1）因為這個需求效果不能确定，不能做全量更新，但是我們當時沒有ABtest支持。所以就想了一個折中辦法，就是挑選一個量相對來說還可以，認證頁面漏鬥和整體沒有太大差異，（記得選的是華為渠道吧，每天注冊量1000多）
• 2）進行内部非強制升級提醒，此處提醒一下，一定不要在某一個渠道發包，因為渠道會有抓包機制，因為你在A渠道新版本的包，其他渠道如果版本低的話會将A渠道的包抓去更新，這樣不僅會導緻包的渠道号錯亂，而且萬一所做的改動起到的是負效果，損失将會很大。
• 3）觀察數據，如果有效果則全渠道更新，如果沒效果，則将定向渠道代碼回滾，再次更新，等待後續新版本将所有渠道全量升級統一版本

後續又根據數據進行了多次優化驗證，這裡就不說了，直接說結果吧，優化的确有效果，聯系人1點擊→聯系人2點擊跳失率從原來的25%左右下降到16%左右，整體轉化率提高了3個百分點樣子。每個月可為公司節省17W左右推廣成本（實際推廣成本節省随着每個月目标不同而不同）。

第一步到第二步的跳失根據上報數據和猜想大體一緻，但是後續還做了交互上優化，也提高了一點，這裡就不再闡述了。

最後的話

最好我想說，方法論與框架是用來幫助我們的，不是用來限制我們的。

在自己對于需求分析不熟悉的時候或者需求比較複雜的時候可以套用框架來幫助我們找到解題思路，當我們對需求分析已經成為本能的時候應該學會放下框架和方法論，在實際工作中會遇到千種千樣的需求，需求分析也要靈活多變，甚至有的需求就是改個文案，此時還陷入在框架或者方法論就無疑有點照貓畫虎了。

以上是個人對需求分析的理解與總結，說的不到位地方請大神指點，也歡迎大家一起交流。

本文由 @wens 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部