需求管理是一個產品中非常重要的環節， 它直接關係到產品最終交付的成果和品質。 產品經理在面對使用者的時候， 還面對著一群人：技術/開發。 如何在接觸用戶需求到技術實現過程中做好需求分析， 提高產品需求的交付品質？本文將從5個階段理解需求， 細化需求分析全過程。
對於產品經理來說， 需求來源可以分為兩種， 被動和主動。 被動需求來自於不同用戶角色， 可能來自於公司的業務部門、產品、測試、公司老闆、直屬上司， 和產品的使用者（Key_User）。 在被動接收的需求裡， 有時候用戶提出的需求很荒謬；有時候提出的需求很具體， 具體到做一個什麼樣的介面， 加一個什麼功能按鈕， 實現什麼邏輯；有時候卻很模糊， 用戶完全無法表達清楚自己面對的困難在哪裡， 自己想要什麼。 主動需求則來自于產品經理通過自身對產品的理解、競品分析、市場分析、產品運營報告等途徑整理的需求。
面對如此雜亂的需求， 如何有邏輯、有順序、完整性的梳理出需求？
1. 需求梳理1.1 搭建自己的需求框架將雜亂無章的需求， 作為一個個待解決的問題點， 解決需求的過程實際上就是解決用戶面臨的問題。
需求框架可以是產品最初的概念模型， 可以是調研提綱， 也可以是一段思路。 作用是為了有次序、有邏輯、有條理的將所有需求串聯起來。
（1）需求分類
搭建需求框架的第一步是要對收集的需求列表進行分類， 我把產品經理收集的使用者需求分為兩類：業務需求、功能需求。
業務需求：由業務提供方或者開展方（產品的使用者）提出的需求， 需求點與業務流程、實際操作過程相關。 功能需求：由使用者提出需要一個什麼樣的功能，（2）連接需求
按照場景以及作業流程將分類後的需求連接起來。 如下圖表達的類似結構：
當然， 也可以通過思維導圖來實現。 連接需求時不一定要非常細， 可能只是一個需求大類或者大方向， 但是最好按照業務的發生順序進行依次排列。
2. 需求調研需求框架梳理結束後， 產品經理需要深入到需求調研活動中去， 重點是瞭解現狀情況。 瞭解有哪些人即哪些角色參與到現有的業務流程中， 業務現狀是怎樣的， 哪些線上做， 哪些線下做， 線上線下是如何銜接的， 什麼情況什麼節點有哪些憑證，
常用的調研方法有以下幾種：
（1）問卷調查
筆者認為問卷調查法在資訊收集類的調研活動中是最能發揮優勢的， 可以免去跑現場、找用戶等環節， 就可以獲取大量使用者的有效資訊。 但一般在業務調研活動中， 很少用到。
（2）用戶訪談
與用戶面對面交流， 這種交流比較隨意輕鬆， 尤其對終端使用者的心理壓力小， 可以簡單直接的獲取到用戶的第一手需求。 甚至有些用戶會提出作業過程中真正的痛點和問題所在。 交流內容會相對比較豐富， 也是最耗時的。 這種通過交流的調研方式， 最主要的是要找到業務相關的關鍵用戶（不一定是某個負責人、主管，
（3）參觀
工作中常常會遇到某個領導來蒞臨指導， 某個同行來參觀等等。 參觀也是調研活動中的一種。 通過對管理方式、操作流程、作業效率等方面的觀察和參觀過程中與個別用戶的簡單交流， 熟悉優與劣（參觀一定是有參照物的）。
（4）專題會
專題會一般會在遇到重大問題或者方向、範圍發生偏移或者不確定的時候， 預先安排好會議時間、會議地點、通知所有參會人員參加專題討論。
2.1 前期調研第一階段的調研會集中於對產品的目標、定位、範圍的確定， 該階段多以專題會的形式展開調研， 最終需要出具概要方案， 資訊流、資金流、物流之間的層次關係， 系統內在活動關係等，每一階段的產出物整理也屬於需求梳理、不斷完善需求框架的一部分。
2.2 深度調研經過第一輪的調研，需求框架裡無論是前期用戶提出的需求（問題點）還是產品經理希望通過調研瞭解到的部分內容應該已經有了答案。接下來需要對需求進行分解，比如第一階段需求調研中分析出了採購、銷售、物流與庫存之間的關係。那麼採購有多少種類型，分為多少種情況就需要進行二次調研，將需求從大類劃分出若干小類，從業務主流程劃分出若干操作子流程。
分解的過程即深度調研的過程，在調研過程中，每一個需求大類中有哪些子流程，流程中參與到哪些角色，每個角色是如何操作的，前置條件是什麼都需要在此階段瞭解清楚。在需求分解時，最好能夠通過用戶訪談和專題會結合的方式，討論後每一次產出物的反覆運算更新也是需求逐漸清晰、正確的說明。
調研過程中需要遵循一定的次序和邏輯，以免被調研使用者發生業務交叉混亂導致調研結果出錯的情況（可以再次體會下需求框架的作用）。深度調研結束後可能採集了很多錄音、紙上記錄了很多內容、腦子裡全是調研的問題、用戶的回答。將調研的所有素材整理成有用的資訊，一共有多少業務流程，對應哪些操作子流程，流程中每一個節點由哪個使用者角色操作，在系統操作還是線下操作，在什麼系統操作，會生成什麼單據，單據怎麼流轉，最終構建一張完整的需求網路。
3. 需求分析3.1 優化B端產品在需求優化環節最難的點是應不應該優化，甚至在產品需求分析工作中完全就沒有需求優化環節。從一個諮詢顧問的身份去考慮，業務的現狀和有序執行並不能說明現有的業務流程就是正確的，不臃腫的。但是優化可能就會涉及到流程改造，業務重組，這時候企業管理的需求是如何進行優化需要考慮的重要因素。
常見的簡易優化點：
單純資料處理：特點是工作量大、耗時、易出錯、操作單一、可替代性強，像這樣的情況線上資料標準化處理的意義非常大。出錯高頻點：特點是易出錯、換人也避免不了。可以通過條碼掃描（字元複雜、錄入難度大）、自動計算（人工計算，單位換算之類）、智慧匹配（限制性強、人工識別困難）等方法。還有一部分是涉及到操作問題的優化，如操作異常點、操作流程冗餘、單據冗餘等等問題。
優化以後，涉及到的業務操作需要和對應角色、業務節點負責人進行評審確認。
3.2 重組經過需求優化後的子流程之間會有共通點、差異點，通過場景、用戶角色、操作現狀、產品目標四個方面對需求重新整合、最終交付產品操作流程。
比如原材料採購入庫和配件採購入庫的操作流程一致，操作使用者和入庫計算邏輯可能不一致，那麼在需求重組時，可以合併為一個流程。
4. 邊界定義在產品目標、人力資源條件、行業約束等客觀條件下，需求便會有了邊界。如：
行業邊界：由行業規則、法規約束的邊界。如財稅系統。結構邊界：一個產品由若干個子系統組成，每個子系統承擔什麼角色，完成什麼任務，會有一個相應的活動範圍。所以產品的結構邊界必須要清晰，否則產品結構就會發生混亂，如交易系統與企業人事資料混在一起。功能邊界：制定一個原則，一個功能是為解決同一類業務或者同一種問題產生的。同時需要考慮到人力資源、系統資源等問題。5. 需求轉化需求轉化即是從使用者需求到產品需求的過程，需要做的工作較多，如優先順序的定義、產品版本的切分、產品設計等。
這部分可以利用馬斯洛需求層次理論、Kano模型等結合產品目標、需求優先順序完成產品版本的切分和產品設計。
最後經過產品核心體系的設計，產品流程、產品框架的設計，最終輸出PRD。
以上描述的需求分析的5個階段，每一個階段在實際應用中都是一個不斷反復的過程，其實，需求分析過程是產品經理對自己的認知不斷驗證、推翻再驗證的過程。
本文由 @Hsm_Henry 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議
系統內在活動關係等，每一階段的產出物整理也屬於需求梳理、不斷完善需求框架的一部分。2.2 深度調研經過第一輪的調研，需求框架裡無論是前期用戶提出的需求（問題點）還是產品經理希望通過調研瞭解到的部分內容應該已經有了答案。接下來需要對需求進行分解，比如第一階段需求調研中分析出了採購、銷售、物流與庫存之間的關係。那麼採購有多少種類型，分為多少種情況就需要進行二次調研，將需求從大類劃分出若干小類，從業務主流程劃分出若干操作子流程。
分解的過程即深度調研的過程，在調研過程中，每一個需求大類中有哪些子流程，流程中參與到哪些角色，每個角色是如何操作的，前置條件是什麼都需要在此階段瞭解清楚。在需求分解時，最好能夠通過用戶訪談和專題會結合的方式，討論後每一次產出物的反覆運算更新也是需求逐漸清晰、正確的說明。
調研過程中需要遵循一定的次序和邏輯，以免被調研使用者發生業務交叉混亂導致調研結果出錯的情況（可以再次體會下需求框架的作用）。深度調研結束後可能採集了很多錄音、紙上記錄了很多內容、腦子裡全是調研的問題、用戶的回答。將調研的所有素材整理成有用的資訊，一共有多少業務流程，對應哪些操作子流程，流程中每一個節點由哪個使用者角色操作，在系統操作還是線下操作，在什麼系統操作，會生成什麼單據，單據怎麼流轉，最終構建一張完整的需求網路。
3. 需求分析3.1 優化B端產品在需求優化環節最難的點是應不應該優化，甚至在產品需求分析工作中完全就沒有需求優化環節。從一個諮詢顧問的身份去考慮，業務的現狀和有序執行並不能說明現有的業務流程就是正確的，不臃腫的。但是優化可能就會涉及到流程改造，業務重組，這時候企業管理的需求是如何進行優化需要考慮的重要因素。
常見的簡易優化點：
單純資料處理：特點是工作量大、耗時、易出錯、操作單一、可替代性強，像這樣的情況線上資料標準化處理的意義非常大。出錯高頻點：特點是易出錯、換人也避免不了。可以通過條碼掃描（字元複雜、錄入難度大）、自動計算（人工計算，單位換算之類）、智慧匹配（限制性強、人工識別困難）等方法。還有一部分是涉及到操作問題的優化，如操作異常點、操作流程冗餘、單據冗餘等等問題。
優化以後，涉及到的業務操作需要和對應角色、業務節點負責人進行評審確認。
3.2 重組經過需求優化後的子流程之間會有共通點、差異點，通過場景、用戶角色、操作現狀、產品目標四個方面對需求重新整合、最終交付產品操作流程。
比如原材料採購入庫和配件採購入庫的操作流程一致，操作使用者和入庫計算邏輯可能不一致，那麼在需求重組時，可以合併為一個流程。
4. 邊界定義在產品目標、人力資源條件、行業約束等客觀條件下，需求便會有了邊界。如：
行業邊界：由行業規則、法規約束的邊界。如財稅系統。結構邊界：一個產品由若干個子系統組成，每個子系統承擔什麼角色，完成什麼任務，會有一個相應的活動範圍。所以產品的結構邊界必須要清晰，否則產品結構就會發生混亂，如交易系統與企業人事資料混在一起。功能邊界：制定一個原則，一個功能是為解決同一類業務或者同一種問題產生的。同時需要考慮到人力資源、系統資源等問題。5. 需求轉化需求轉化即是從使用者需求到產品需求的過程，需要做的工作較多，如優先順序的定義、產品版本的切分、產品設計等。
這部分可以利用馬斯洛需求層次理論、Kano模型等結合產品目標、需求優先順序完成產品版本的切分和產品設計。
最後經過產品核心體系的設計，產品流程、產品框架的設計，最終輸出PRD。
以上描述的需求分析的5個階段，每一個階段在實際應用中都是一個不斷反復的過程，其實，需求分析過程是產品經理對自己的認知不斷驗證、推翻再驗證的過程。
本文由 @Hsm_Henry 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議