業務需求、用戶需求和功能需求這三個概念，對於產品新人來說，經常容易混淆，但瞭解這些是身為產品經理的一個基本功。
問：業務需求對於產品經理來說很重要麼？
答：業務真的是很重要。並不是說功能邏輯和交互不夠重要，事實上功能邏輯和交互是一個產品的基本功。選對商業模式、快速迭代，才能讓一個產品活下去。首先需要保證的是整體的方向和準則不會出問題，這才能保證產品是可用的，細節是在方向和準則的大前提下去根據產品本身去思考的，才能保證產品是易用的。
需求的分類
上面的問題是和朋友聊天提到的問題，但是實際在工作中可能有些小夥伴經常會弄混淆業務需求、用戶需求和功能需求這三個概念，那麼怎麼去區分這三個需求呢？
- 業務需求 ：通常是基於市場營銷部門、業務部門根據自己的業務需求和後續策劃的活動方法所整理成的需求文檔。
- 用戶需求：描述的是用戶的目標，是用戶能通過這個產品在什麼場景（什麼情況下）能完成什麼動作（做什麼）。
- 功能需求：是指產品通過需求池篩選內容後，整理成此版本需要迭代的內容，往往功能需求需要配合流程和原型邏輯，讓項目團隊夥伴有清晰瞭解。其實業務需求和用戶需求也不能完全轉換成功能需求。
需求的分類不僅僅包含這三個需求，比如我們在產品規劃中依託於公司未來業務發展的方向制定的規劃型需求和對於競品在同階段所實現的競品需求，由於此篇文章主要是針對於趨向於業務需求，所以這兒就著重的去看業務需求和附帶關聯的用戶需求、功能需求。
其實在深入的去思考業務需求的具象時，我們去梳理業務需求、用戶需求和功能需求三者之間存在的聯繫，都知道需求最終是為了產品目標服務的，所以我們需要清晰的明確為了解決產品目標，我們應該怎麼把控需求？
產品目標與需求之間的關係點
其實我們回過頭來看產品設計，目的不僅僅是一個用戶體驗好的產品，更是一款成功的產品，它包括業務側和用戶側兩方面。基於此，在具體設計的之前要分析一下四個方面，否則容易陷入僅僅是為了設計而設計，卻無法解決核心問題的情況。
分析業務需求：我們需要明確業務部門為什麼要做這個產品？所期待的產品成果是什麼？
分析用戶需求：誰來使用這個功能？方便新用戶還是老用戶？便於拉新還是促活？以及這部分用戶為什麼要使用這個功能？
明確產品策略：通過將業務需求和用戶需求進行匹配，通過一句話來解答就是：通過某種策略給某群用戶帶來某個價值，來實現某類業務目標需求。
設定數據指標：通過產品實現目標業務價值回溯對應的數據指標是否達成。
分析業務需求
業務部門反饋的業務訴求。產品需要與業務部門討論進行梳理討論整理，進而明確變成產品業務需求。可以通過三個點進行分析：
1. 分析業務目的和業務目標；
2. 整理對應的業務流程圖；
3. 整理產品的場景和規則。
接下來每個點一步步聊下：
第一步：分析業務目的和業務目標（就是去了解業務需求）
一般情況，業務人員會從自己做業務遇到的“阻礙”，這個“阻礙”可以幫助我們理解業務之間的干係，從中我們可以得到這些信息：
1. 這個需求涉及的業務干係人（用戶來源）；
2. 這個需求的關鍵操作（功能拆分來源）；
3. 這個需求的操作流程（流程來源）。
我們可以總結業務模塊的需求池：
有了上面的理解，就大致知道了需求是幹嘛的，那實際的業務中，是如何操作的呢？經過了什麼樣的流程節點呢？
第二步：整理業務流程圖
這個階段需要整理業務流程圖草圖和梳理規範的業務流程圖：
（1）流程圖草稿：把理解到的都用流程圖的方式表達出來，不分泳道、不糾結流程節點命名、也不用在意這個節點該不該畫出來，畫出最粗又是最細的流程圖。粗是因為不分泳道很多節點也不合理，細是因為把聽到的理解的都作為節點畫出來。
這時候不要畫泳道圖，因為對業務還模糊不清，抽象不出合理的泳道，如果一開始就設計泳道圖，反而會花費較多時間和精力，但效果並不理想。
舉個例子：A同學去超市購買商品的業務場景流程：
（2）細化流程圖：通過和業務方不斷調研和溝通，這時候可以逐漸的整理泳道圖來進行操作流程和用戶之間的協同點。
這時候輸出的流程必須是泳道劃分合理，流程節點粗細適宜，節點命名合乎業務的。但是這時候的流程有一點還是會有欠缺，異常流程和判斷節點往往會缺失。後面在實現功能流程會去整理異常情況和判斷的節點。
這一節點應該輸出：
一是流程圖草稿（只給自己最初理解業務用）；
二是業務流程圖（用於向其他團隊成員講解和幫助他們理解業務）。
第三步：整理產品場景和規則
有了流程圖和狀態圖，就可以抽象出不同的業務場景。再根據場景逐個細化調研，從而獲得業務規則，其中，業務規則細化到每個信息類型和細節處理等等信息，才算真正走到業務點場景中。
（1）抽象場景：抽象場景其實在個人理解中就是模塊化的需求，業務方針對場景的描述，產品經理將場景劃分各個模塊，針對模塊制定對應的功能需求點，並將功能需求進行串聯（通過流程圖）。這階段需要輸出的是業務需求池、業務功能導圖和業務規則流程圖。
這樣做的好處是：場景劃分便於理解查看和維護，但又不會落下細節和特殊情況，保證產品設計的完整性。
（2）細化規則：一旦有了場景，並且有了場景下的不同情境，就可以針對各個情境下的業務限制規則進行梳理和調研了。
這一節點應輸出：業務場景劃分列表、業務細節規則列表，應該注意規則列表是對業務場景的細化和深入。
分析用戶需求
用戶需求是針對於用戶在使用產品時候，結合業務方描述的場景形成梳理，希望用戶在場景完成某件事。分析用戶需求是從目標形成過程中的重要環節，它包含兩部分內容，即：
明確目標用戶，洞察用戶痛點——如果我們想要去明晰用戶訴求，必須結合用戶當前所處的場景。場景的藐視是業務訴求中去尋找目標用戶和目標用戶能為我們帶來的價值共同去界定的，更能夠幫助站在用戶視角，去了解當前場景並去分析目標用戶動作。
將用戶痛點轉化為需求——就像“用戶要的是更高效的移動，而不是一匹更快的馬”，用戶能想到的解決方案都是基於其認知本身，對此，產品需要挖掘需求背後的真正訴求，進而從根源找到解決方案。
舉個例子：現在英語類知識付費學習平臺案例，整體分析情況如下：
第一步：明確目標用戶
第二步：將用戶痛點轉化為用戶需求
第三步：明確產品策略
產品目標一定是以業務為導向，以用戶為中心出發的，通過業務訴求和站在用戶的角度上去思考的，只有這樣，才能提煉產品真正的價值。
在英語學習的場景中，為了更好的將業務需求和用戶需求更好的匹配，通過業務用戶關聯表可以一一進行解決：
通過業務用戶關聯表可以針對不同人群給予不同的解決方案，進而形成產品策略。確定了產品策略後，還需要根據公司資源投入和預估ROI以及上線時間確認產品需求的優先級，然後進而和項目組確認上線週期，這兒就先不去贅述。
設定衡量產品目標的數據指標
由產品目標可以演繹出的東西不少，其中最直接、最具有指導意義的就是數據指標。數據指標是對目標價值這種抽象概念的數據化表達，它能為所有參與角色形成一個具體的關注焦點，建立一個統一的座標體系和判斷標準，直觀的反應方案效果與目標價值之間的差距，成為後續迭代優化的思考源頭。所以，設定數據指標是非常重要，也是十分必要的。
比如英語學習平臺最後需要收集的數據指標包含：課程參與人數、拉新、留存率、UV、反饋數值（用戶完成課程）等。
當然對於產品經理來說，這僅僅是前期去梳理業務需求，針對於“梳理業務→產品模塊整理→需求池（功能整理）→梳理版本計劃→功能導圖→功能流程圖→原型設計→PRD文檔→產品評審→開發→測試上線→數據分析→產品迭代”，梳理業務是項目生命週期的第一環節，後面每個內容將通過一篇文章來聊聊。
後記：產品經理並不是大家口中的“做不好運營、敲不了代碼，就去做產品吧！”希望小夥伴們持之以恆，繼續努力。共勉之……
本文由 @john 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議