需求分析是產品經理的核心競爭力，如何做好需求分析是所有產品經理都需要重視的問題。本文作者從一個簡單的小案例出發，對做好需求分析進行了梳理，拆解分成了4個階段，供大家一同參考和學習。

前段時間一個產品交流群中關于“身份證號該隱藏幾位”的討論引發了我的思考。

猛的看來這只是很小的需求，產品經理們羅列了每個數字的含義、討論著到底隱藏幾位才能保護隱私，但遲遲沒有定論。

這就是犯了產品最常見的錯誤：拿到需求馬上想方案，沒有想透到底是要解決什么問題，導致方案無法落地。

所以挖掘需求根本為產品經理的核心技能，本文將以“抬杠青年”來定義產品經理，細說“需求分析”那些事。

P.S.抬杠的精髓在于不停say why，深挖問題的本質。這里可不是讓大家去做杠精，下文便是抬杠的正確姿勢～

需求分析的核心

需求分析的目標，是將未加工的需求功能進行梳理，產出用于技術實現的文檔。

俗話說“千里之行始于足下”，需求分析的核心就是對原始需求的梳理分析，若初期就找錯方向，后續的所有工作就會麻煩不斷：toC 產品可能用戶不買賬，甚者觸及合規風險被要求整改，toB 產品則會驗收不通過，打回重做。

需求梳理分下面這幾個階段進行：

1. 收集需求
2. 需求可替代性、可行性分析
3. 沙盤推演，產出業務流程圖
4. 需求反推驗證

1. 收集需求階段：杠需求方

初始需求可以分為兩大類：客戶需求、自研需求；客戶需求又可細分為：上級需求、甲方需求、用戶需求。

需求收集階段的目的，是挖掘需求本質，了解需要解決的問題。

客戶需求：

多數時候需求方在提出需求的同時，都提供了對應的解決方法，這一點在處理B端需求的時候尤為明顯。

若不對這種包裝好的需求進行拆解，直接在此基礎上出具方案，那么解決的僅僅是表層問題，根本問題還沒解決，后續還會遇到類似問題，導致浪費開發資源、團隊質疑產品能力、降低產品經理自身的成就感。

所以產品經理在拿到新需求后，都將其視為“包裝”好的需求，需要分析根本需要解決的問題是什么。

直接拿以上問題去問需求方，那就是將需求整理的工作甩給需求方，需求方只知道自己當前遇到了什么問題，但是并不清楚其根本需要解決的問題是什么。

那么就需要產品經理幫忙去引導、挖掘，去不斷“質問”需求方。根據已有的信息提出新的問題，來不斷深挖問題根本。

引導方式采用案例法，誰都會講故事，通過敘事、舉例子的方式，可以幫助我們還原需求場景，挖掘出根本問題。

案例法與學生時期寫作文類似，分為五要素：時間、地點、人物、干什么、遇到什么問題，所以產生了這個需求。

1. 時間：不僅局限于時間，操作的狀態、步驟也可作為時間；
2. 地點：不僅局限于地理位置，操作的終端也可作為地址；
3. 人物：進行操作的主體角色、本次操作涉及的人群；（不同的角色有不同的定位，所謂“屁股決定高度”，不同定位關注的方向就不同，比如老板關注結果，員工關注過程）
4. 干什么：發生了什么事、本次操作流程、期望達到的效果；
5. 遇到什么問題 ：遇到了什么阻礙、阻礙了什么操作的進展、造成了什么影響。

不同類型的客戶需求的溝通方式也有所差別：

1）上級需求：上級看重的是結果、收益，不關注過程。所以他們的需求大多是一個結果。

例如：在減少開發量的前提下讓更多人買會員、后臺生成數據月報等。

所以在溝通時，需要站在宏觀業務的角度，從結果反推背景，不要陷于細節的溝通。

例如第一個需求的業務背景是領導決定減少該業務線技術投入，且不希望增加機器，希望通過小功能的迭代，在不影響vip客戶體驗的前提下，提升會員轉化。

第二個需求的業務背景是每月商務需要與甲方結算，人工從各字表提取數據太耗精力，希望自動生成。

2）甲方需求：甲方需求方的級別不同，所以需求類型可能是結果型，也可能是操作型。

但他們大都有一個共同點，就是會對原始需求做一層包裝，用他們認為合理的解決方式來提需求。

產品經理需要將該需求涉及到的所有人拉到一起，一塊討論實際想解決的問題是什么，他們平時工作時是如何解決此類問題，所有人的意見達成一致后，產品經理再去思考針對需要解決的問題，是否有更優的解決方案。

3）用戶需求：用戶需求為操作類型，可直接采用五元素法來收集。

4）自研需求：自研需求就不必多說，不論是自己分析產品進行迭代，或是通過競品分析來優化，一定都要有一個明確的方向：具體是為了解決什么問題，實現什么目標。

若方向沒有明確，之后的工作就會像無頭蒼蠅一樣亂撞，效率極低。

2. 需求可替代性、可行性分析階段：杠需求

收集需求后，已明確用戶實際需要解決的問題是什么，接下來，就要針對需求本身去思考，這個需求是否有現成可替代功能、是否值得去做，是否能做。

因為產品經理作為需求的第一接收者，不應該當傳話筒，將外部傳來的需求全部都一股腦交給開發。

應當先對其做一層篩選，決定是否有必要進行之后的工作。

流程如下：

第一步 ：是否有可替代性

沒有誰比產品經理更熟悉產品，所以產品可能已經有現成功能可直接/間接解決用戶問題，那么就沒必要進行后續工作，將解決方案提供給需求方，確認其是否可以接受。

第二步 ：是否值得去做

每個產品都需要一套“產品原則”。

產品原則是對團隊信仰和價值觀對總結，用來指導產品經理作出正確的決策和取舍。

制定產品原則意味著決定什么重要、什么不重要，哪些原則是根本的、戰略性的，哪些是臨時的、戰術性的?！秵⑹句洝返?3章

根據產品原則，可判斷該需求是否值得去做，處理的優先級如何。若判定不解決，需要將原因結合產品原則反饋給需求方。

第三步：是否能做

經過前兩步，該需求已經確認需要實現，這一步需要根據當前系統架構、開發水平、運營成本等多方面考慮，該需求是否能實現。

這一階段需要技術參與，一般不可做的原因有三種：當前系統架構不支持，需要重構；開發水平有限，不能實現；運營成本過高。

拿到不可做的原因后，需要與上級溝通，讓上級決定是否要重構、新招開發、支付相應成本。

這一步溝通也有技巧，給上級提供最夠多的信息來輔助判斷：需求方、需要解決的問題、大致實現成本、影響范圍。

通過以上篩選，需求就是經過篩選的待處理狀態，可以進入下一步啦。

3. 沙盤推演階段：杠需求

從需求轉化為解決方案，需要先進行一次詳細的沙盤推演，將操作過程走通、異常情況都考慮進來，才會保證最終產出的解決方案的定位準確、覆蓋面全，不會產生遺漏。

閃盤推演，即根據需求的業務背景，將業務流程中所有涉及到的系統、用戶間的交互，用流程圖的形式進行流程梳理，幫助產品經理縷清業務邏輯。

在每個交互的過程中都可能產生異常，明確的流程圖有助于提前將可能發生的異常情況盡可能全面的提前梳理出來。

流程圖的制作過程不在本文詳述。

該階段的產出，為業務流程圖、異常情況梳理表。

注：一般在這一步，腦中會生成大概的解決方案。

沙盤流程配合當前問題的解決方案+實現成本，可能會發現第一步分析出來的問題還不是最根本的，還有更底層的問題需要先解決。

這樣就需要返回第一步重新進行一次需求梳理工作。

4. 需求反推驗證階段：杠自己

上面三個階段，就完成了需求的梳理過程，產出方案前的最后一步，便是去質疑自己，反推以上的產出，是否是真正用戶需要解決的問題，業務邏輯是否準確。

反推過程需要需求方的參與，產品提供需求梳理的產出資料，與需求方check。

需求再緊急，這一步都是一定要做的，需求梳理結果沒有與需求方進行確認，可能整個過程都是產品經理的自嗨，初始的方向錯了，沒解決用戶需求。

方向與需求方確認無誤后，再與需求方一起分析第三階段中“異常情況”的處理，這部分屬于方案制定階段，本文不做詳述。

該階段完成后，若是B端需求，需要進行郵件確認，作為留痕。在后期產品交付時以此需求為準。

綜上，做個總結

拿到需求后，先不要急于動手，先進行需求梳理：

1. 收集需求階段：剖析用戶實際需要解決的問題；
2. 需求可替代性、可行性分析：該需求是否有現成功能可解決，根據“產品原則”判斷這個需求是否值得去做，從成本考慮這個需求是否能做/要做；
3. 沙盤推演：從業務出發，產出業務流程圖，梳理異常情況；
4. 需求反推驗證：將以上產出與需求方進行確認，確保初始方向正確

不斷提問，以“抬杠青年”的姿態多問為什么，會在初期盡可能的挖掘很多潛在的“坑”。

前期多花點時間調研需求，總比開發后期改需求強，大家說是不是這個理？

作者：橘子；公眾號：橘子周思錄；我是3年產品橘子，每周分享自己對日常工作的總結思考，希望與您一同成長。

本文由 @橘子 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。