本文將需求分為兩類——工具類需求、用戶端需求；并進一步給出了兩個案例方便理解。
本文將需求分為兩類——工具類需求、用戶端需求；并進一步給出了兩個案例方便理解。
前言
關于需求分析無疑是產品經理的一項必備基礎功，也是每個產品經理可能工作大部分時間都在做的事情，但是絕大部分產品經理可能不會刻意的去總結一套方法論。總的來說不總結方法論也不會有多少問題，因為畢竟基本工作很熟手，但是總結了方法論并寫出來有以下幾個好處：
- 指導自己工作，在自己不知該如何著手做一個需求的時候，可以為自己提供一個框架
- 鍛煉自己的結構化思維及總結能力
- 寫出來與自己對話能提高自己的認知，會獲得意想不到的收獲
個人平時也比較懶，偶爾會寫些東西，但是通常不能長久的堅持，也希望自己能慢慢堅持下去。
什么是需求分析
個人對需求分析就是： 確認終點尋找路徑的過程.
從這一定義來說需求分為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個場景全貌）
我：你能簡單說一下你以后要怎么用著兩張報表嗎？
財務：每個月月底小貸公司打款過來，然后我用“報表1”進行核對打款是否正確。每個月我根據“報表2”計算應付渠道多少款
我：那為什么要拆成兩個報表？之前研發不是拉一張報表給你就OK了嗎？
財務：因為結算給渠道不能讓他們看到成本，結算給小貸公司，也不會給他看渠道成本，他們也不關心（已經獲得第1個結算場景全貌）
我：那我做一個報表給你，你再拆不一樣嗎？（這么問不是為了偷懶，因為工作量差不了多少，主要目的還是旁敲側擊挖掘其使用場景）
財務：這樣也可以，但是有些麻煩，而且有的時候渠道方中途想核對一下月中數據是否一致，此時不用導出EXCEL報表發過去，比較麻煩，直接截個圖對下數據就可以了（獲得了第2個使用場景）
我：除了對賬，表格對你還有其他幫助嗎？
財務：還會去統計每個渠道帶來利潤，看看渠道大體情況
我：那分成兩個表格你怎么統計利潤？
財務：（財務有點支吾，估計之前沒考慮到）我可以自己再把表格合起來然后對賬（獲取了第3個場景全貌）
從以上的對話可以看出財務所提的方案，滿足不了她自己所有的使用場景需求，當然后續對話還有一部分是關于功能細節的，這里不贅述了。
有的人可能會問，財務說的也對，兩個表格到時候她自己合起來對賬就OK了？
那么首先這樣麻煩，容易造成錯誤不說，最關鍵的一個問題是，她如果要去做合表，必須保證后臺所查出來的兩個表格數據排序是一樣的，否則就會造成數據對不齊！如果直接開發上線，后續就不得不面臨著一個問題——需求變更#@￥！￥%@%￥！%￥
5. 功能設計：
有了具體的使用場景，對業務了解，基本功能設計就不太會出多少問題了，這個產品形態很簡單。下面直接附上最終的交互稿：
至于后續的幾個步驟，在這個例子中不需要做，因為功能很簡單工作量小
案例二：優化認證轉化率
某小額貸款公司，整體業務流程為：用戶登錄注冊→認證獲取額度→申請→審批→打款
需求背景：
在該項目上線半年左右，業務已經逐步趨于穩定了。于是就琢磨著看能不能提高業務效率，在當時整體的認證轉化率在35%左右，憑直覺有很大的優化空間，于是就自己倒騰備庫，拉了一周的和認證相關的業務數與埋點數據，做出了下圖：
在這張圖上很容易看出進入頁面=》提交身份認證，聯系人1點擊=》聯系人2點擊，這2步跳變流失比明顯比較大，于是就有了“優化認證轉化率”的需求，套用需求分析框架。
1. 目標分析：
此需求受眾是誰？所有進入我們APP無特定屬性用戶。是否影響其他部門/人？應該不影響。此需求的目標是什么？提高用戶進入認證頁到獲得額度的總體轉化率。
2. 價值分析：
此需求價值幾何？
12000*[1-35/(35+X)]*6=72000*X/(35+X)元
（公式得來是因為我們要維持放款量是一定的，轉化率高了對應的拉的用戶量就可以減少，大家可以自己推算）
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）觀察數據，如果有效果則全渠道更新，如果沒效果，則將定向渠道代碼回滾，再次更新，等待后續新版本將所有渠道全量升級統一版本
第一步到第二步的跳失根據上報數據和猜想大體一致，但是后續還做了交互上優化，也提高了一點，這里就不再闡述了。
最后的話
最好我想說，方法論與框架是用來幫助我們的，不是用來限制我們的。
在自己對于需求分析不熟悉的時候或者需求比較復雜的時候可以套用框架來幫助我們找到解題思路，當我們對需求分析已經成為本能的時候應該學會放下框架和方法論，在實際工作中會遇到千種千樣的需求，需求分析也要靈活多變，甚至有的需求就是改個文案，此時還陷入在框架或者方法論就無疑有點照貓畫虎了。
以上是個人對需求分析的理解與總結，說的不到位地方請大神指點，也歡迎大家一起交流。
本文由 @wens 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
