作為產品經理，需求分析很重要，但你真的弄懂需求，分析對用戶的真實需求了嗎？產品經理到底如何做需求分析？作者深度解析了相關步驟，希望對你有所幫助。

友情提示：這篇文章比較長，全是干貨！建議先收藏再閱讀，如果你覺得內容不錯，記得幫刀哥分享一下，本文目錄：

1. 你真的懂需求嗎？
2. 為什么需求分析如此重要？
3. 需求來自于場景
4. 需求分析的方法：用戶故事地圖
5. 如何挖掘真實用戶需求：逆向分析法
6. 產品需求建模的三大工具
7. 如何管理用戶需求和產品需求？
8. 一個需求的一生

產品經理在平時的工作中，需求這個詞，出現的頻率絕對是最高的，沒有之一。

當我們說到需求時，其實有用戶需求、功能需求、市場需求、商業需求等。

你真的弄清楚了這些需求分別代表著什么意思嗎？又知道這些需求之間的區別嗎？

如果沒弄懂的話，你做需求分析的邏輯可能都是錯的，更不可能做出優秀的產品方案。

因為不同的需求，分析的邏輯和使用的方法都是不一樣的。

比如，分析用戶需求，需要使用逆向設計法，探索用戶更底層的需求。

比如，分析功能需求，需要使用UML建模，將用戶需求轉為可實現的產品需求。

比如，分析商業需求，需要使用精益畫布，從產品和市場的角度，從成本和營收的角度，從問題和解決方案的角度，去分析商業模式是否成立，能否讓公司盈利。

這篇文章，刀哥跟你一起探索需求，為您開啟正確的需求分析之旅。

一、你真的弄懂需求了嗎？

需求，簡單的來說，就是一種需要。

需求方可能是用戶、市場、企業或者產品。

需求方是用戶時，是用戶需求，用戶遇到問題或者無聊時，需要通過產品/服務來解決。

需求方是市場時，是市場需求，市場需求是用戶需求的集合，需要更多的產品/服務來解決。

需求方是企業時，通常是商業需求，企業需要通過產品實現盈利。

需求方是產品時，是產品需求，產品需求包括功能需求和非功能需求。

作為產品經理，我們經常接觸到的是用戶需求和功能需求。

本文，也將重點討論這兩個需求。

二、為什么做好需求分析如此重要？

相信大家對這張圖不陌生，雖然是個段子，但卻真實體現了需求分析過程中的失真。

首先，在用戶需求分析的時候，如果沒有抓到本質，可能直接導致后面的工作沒有意義。

做完了以后發現，和預期不符，要么變更需求重新做，要么直接失敗，做出一堆沒用的產品/功能。

其次，在做產品需求分析時，如果沒有有效的方法，需求描述不清楚，后面的研發過程會非常痛苦。

總之，需求，是任何產品的起點，為產品的直接負責人，產品經理要準確的定義這個起點，讓正確的事情相繼發生，否則，就會出現方向不對，努力白費。

三、需求來自于場景

要準確識別用戶需求，我們必須要了解場景，因為用戶的需求，一定是來自于場景。

用戶需求場景是指用戶在某種環境下，做某件事來滿足某種需求。

影響需求有兩個核心要素，一個是環境，一個是用戶當前的狀態。

我們舉一些例子，來理解場景對需求的影響。

胖子一定會有減肥的需求嗎？并不一定，有些胖子天天喝快樂肥宅水，吃油炸食品，過得很快樂，并不一定需要減肥。

只有當胖子因為自己血糖高、血壓高，身體因為肥胖而不健康的時候（用戶狀態），或者因為肥胖被人恥笑，找不到對象時，他才會減肥（環境）。

而當他真正去減肥的時候，他的需求可能是身體健康（如果胖且健康，就不會減肥），或者是找到彼此欣賞的對象（如果胖也能得到贊賞，并且能找到對象，就不減肥了）。

慢性子的人永遠都是不慌不慌嗎？并不一定，當他上班快遲到的時候，他也很慌。

大齡單身狗一定會焦慮找不到對象嗎？并不一定，他本身就是不婚主義者，很享受單身生活，毫無焦慮。

需求，一定來自于特定的場景！

需求，一定來自于特定的場景！

需求，一定來自于特定的場景！

只有真正理解了這個道理，才能真正理解用戶，做出合適的解決方案。

前段時間我到商場玩，花了300塊錢，換來了一堆沒啥用的小玩偶，小玩具，市場價最多50元。

在任何一個理智人看來，這都是不劃算的，難道是因為我傻嗎？

并不是。而是因為我在特定的場景里，產生了需求，做出了消費的行為。

這個場景就是電玩城。

那天我帶著孩子去商場玩，見到商場里有個電玩城，有很多夾娃娃的、夾玩具的……

孩子看到這些玩具，興奮得很，非得讓我去夾。

剛開始我買了100塊的幣，想著夾完就不完了，結果幣塊用完的時候，有一個孩子想要的玩具，始終夾不到。

我不想讓孩子失望，就又花了100，夾了很久，終于夾到了，幣也差不多用完了。

后來又看了一些其他玩具，又花了100。

最后看夾到的這些玩具，市場價可能就50塊錢，300塊可以買很多更好的玩具了。

這就是在特定場景，產生特定需求的案例，在電玩城的環境里，已經在我們在商場玩耍的這個狀態下，我們產生的可能并不一定是獲得某個物品的需求，而是獲得通過概率游戲，去獲得物質獎勵的刺激感。

四、需求分析的方法：用戶故事地圖

1. 用戶故事和用戶故事地圖

我們做需求分析，概括起來，可以分為兩步：

1. 識別用戶需求
2. 轉化成功能需求

在識別用戶需求，并轉為功能的過程中，有幾個關鍵要素：用戶、功能和希望達成的目標。

使用用戶故事，剛好可以把這幾個關鍵要素串聯起來。

用戶故事可以發現用戶需求，并定義解決方案，即功能。

通過團隊一起頭腦風暴，梳理用戶故事地圖，就可以做到既見森林又見樹木。

用戶故事地圖，是由用戶故事組成的全景圖，用戶故事由核心步驟和用戶故事組成。

核心步驟是完成目標需要完成的關鍵環節，用戶故事是根據核心步驟拆分出來的更具體的小任務。

例如，用戶在電商產品中，核心步驟可以分為：瀏覽商品——下單——付款——收貨——評價，在瀏覽商品這個步驟里，可以分為更具體的用戶故事，如查看首頁、搜索、對比、查看詳情、查看評論等。

用戶故事地圖，有這樣幾個作用：

1、和業務、研發，甚至用戶一起梳理需求，不遺漏關鍵功能；

2、在團隊內達成共識，讓項目成員有全局感，既見樹木，又見森林；

3、更好的規劃版本，每次新迭代，都是做的當前最重要的功能，不浪費研發資源；

2. 梳理用戶故事地圖的方法

梳理用戶故事地圖，需要組織一次頭腦風暴會議，參與人須是各崗位關鍵角色，包括產品負責人、項目負責人、業務負責人、技術和老板等，人數控制在7人以內，但不要少于3人。

這些角色可以從多個角度提供建議，使產品/功能更加完善。

開會前，要提前準備一些材料。最好準備一個白板、不同顏色的便利貼、膠帶等等。

如果沒有條件，也可以使用線上工具。

圖片來自網絡，侵刪

1、第一步，進行產品定義。我們要確定我們的用戶是誰？解決什么問題？用戶目標是什么？產品目標是什么？通過這些問題，可以基本框定整體的范圍。

2、第二步，梳理骨干故事。梳理故事要確定好一級故事、二級故事，保證故事的完整性，同時要廣度優先，而非深度。最后的效果就是看到故事群。

3、第三步，拆分故事。在剛剛梳理的每一個二級故事下面做停留，去拆分二級故事獲取更多細節內容。圍繞這個故事寫更多細節。

在這個過程中，先讓大家在一定時間內按照自己的想法寫出來，把每一條寫在一張卡片上，做到相互不干擾，然后每個人出聲說出自己的卡片內容，讓所有人了解并貼在墻上。

項目組人在寫想法的時候，相當于腦暴的過程，這時可以通過一些問題來刺激大家腦暴出更多的內容，比如：

• 用戶在這步具體做什么?
• 用戶還有其他選擇么?
• 用戶怎么做才能更爽?
• 出現問題如何處理?

在真實業務當中，發生特殊情況該怎么辦？所以這一步我們將盡量多地關注到所有場景的故事。

做完這步，我們已經獲取到了足夠多的細節信息，整個團隊都會做到對產品又見森林又見樹木的狀態。

4、第四步，溝通確認。這一步是將前面豐滿而又臃腫的故事，通過對標標題、充分討論，把公認的留下來，無用的剔除掉，同時區分要做的故事細節的優先級。

完成所有故事梳理后，就出現了下面這張圖：用戶故事地圖。

五、挖掘真實需求：逆向分析法

當我們梳理用戶故事時，會有一個常見的誤區，把用戶提出的方案，當作我們最終的解決方案。

用戶想要一匹更快的馬，如果我們把用戶的方案當最終的方案，就永遠只會去想，如何給用戶提供更快的馬。

更加科學的做法是，當我們接到用戶提的方案時，先不要著急定方案，而是按照下面的步驟去思考。

1. 逆向調查

用戶為什么會有這樣的需求，背后的真實目的是什么，可以借助黃金思維圈工具，從What到How再到Why。

比如，用戶想要一匹更快的馬，只是表象，真實的動機是，想更快地到達目的地?！靖斓鸟R】只是他能想到的最好的方案。

2. 找到真實需求

繼續往下面挖掘，用戶想更快的到達目的時，是為了更快地完成交貨。

更快地交貨，是為了促進更多的成交，賺到更多的錢。

賺更多的錢，是為了過上美好的生活，實現自由、快樂。

……

每個需求，挖到最后，都是人性的需求。

不過，我們應該重點關注，我們可以影響的那個層級，不必無限往下挖掘。

3. 調研

挖掘到用戶的真實需求后，就可以著手調研解決方案了。

用戶的提案，是基于用戶的認知，用戶只會基于自己的認知提出解決方案。

我們通過調研，是要找到更好的方案，我們的認知一定是要能高于用戶的。

用戶想要一匹更快的馬，我們發現用戶是想更快地到達目的地。

于是我們去調研，有沒有更好的讓用戶從A到B的方案。

經過調研，我們發現，根據目前人類最先進的技術，可以制造一輛四個輪子的汽車，比馬更快。

再往后，技術還會發展，可能還有高鐵、飛機。

4. 假設并設計

基本明確方案后，就可以假設一個方案，并著手設計。

通過設計方案，實現方案，去驗證我們的方案是否達到預期，形成一個閉環。

這一步可以使用OSM模型，即目標、策略和度量。

制定一個方案想要達成的目標（O），然后，圍繞這個目標，去設計方案（S），最后，通過關鍵數據指標（M）來衡量所采用的策略是否達到預期。

六、產品需求建模三大利器

在完成用戶需求分析后，我們需要將分析出來的功能，轉化成產品需求，并交付給研發團隊來實施。

交付的形式是PRD。PRD里面包含功能需求和非功能需求。

功能需求里面包含業務流程、業務規則、界面交互等。

在推導功能需求之前，我們要對需求建模。

產品經理，需求建模有3個常用的工具：ER圖、業務流程圖和狀態機。

1. ER圖

1）什么是ER圖？

E-R圖，也叫做實體關系圖，是用來描述現實世界的模型。ER圖是由美籍華人陳品山于1976年提出的一種數據建模工具。

實體是指客觀存在的事物，比如人、對象、概念、事件，都可以看作實體，通過梳理實體，以及實體之間的關系，可以梳理出產品的大致信息結構。

通過E-R圖來梳理信息結構，對產品經理來說，有以下幫助：

1、給開發提供數據庫建表依據。程序=數據結構+算法，有了數據結構，對開發來說，對即將開發的系統就有了更清晰的框架。

2、可以指導產品經理進行原型設計。在動手畫原型之前，梳理ER圖，根據已知的信息畫在原型上就行，而不用一邊畫原型，一邊想字段。

3、提升產品經理的抽象及歸納能力。梳理E-R圖，是一個建模的過程，建模需要通過業務溝通、流程梳理，從這些分析活動中提煉出核心實體。

2）ER圖的核心組成

E-R圖由實體、屬性和聯系組成。實體是抽象出來的人（如學生、講師）、對象（如課程）、概念（如章節）。實體一般是個名詞，用一個方框來描述。

屬性是對實體不同維度的描述，用橢圓來表示，并和實體連接起來。但是大部分情況下，我更喜歡直接在實體里面去添加屬性，維護成本更低，可擴展性更強。

實體與實體之間，通過一個菱形來連接，菱形里描述實體之間的聯系，比如用戶<創建>訂單，課程<關聯>講師，菱形里一般是個動詞。

實體和實體之間，有幾種數量對應關系，即基數，基數有1對1，1對多，多對多。在菱形兩邊的線上，通過1、N、M來表達數量關系。

以下是標準的ER圖：

3）ER圖的三種模型

ER圖按照其目的，可以分為三種類型的模型，分別是概念模型、邏輯模型和物理模型。

1. 概念模型，主要呈現的是系統主要的實體，即核心業務對象，不會描述屬性和基數。
2. 邏輯模型，主要呈現的是實體，關系，基數和屬性。
3. 物理模型，主要呈現實體，關系，基數和更詳細的屬性，更詳細的屬性包括鍵值、主鍵、外鍵等。

產品經理平時用到的，主要是概念模型和邏輯模型，在需求分析階段輸出時，可以利用其指導我們進行原型設計即可。

邏輯模型也可以作為開發創建數據庫的依據，開發在創建數據庫的時候，會使用物理模型。

以下是三個模型的對比：

所謂的列，你可以理解為屬性，列的類型是屬性的數據類型。

比如，用戶作為一個實體，有姓名、年齡、生日等屬性，姓名是字符、年齡是數字、年齡是日期。

4）ER圖示例

邏輯模型ER圖

物理模型ER圖

ER圖的畫法非常簡單，但是用處特別大，實體關系更是一種思考模型，可以讓產品經理“透過現象看本質”。ER圖可以指導產品進行需求分析，產品設計，還可以作為開發人員建表的依據。

ER圖包括實體、屬性和關系，分為概念模型、邏輯模型和物理模型，產品經理經常用到的是概念模型和邏輯模型，開發人員使用物理模型。

ER圖的工具，刀哥推薦使用processon，當然Axure也可以，因為ER圖相對簡單，其實使用什么工具差異都不太大。

2. 業務流程圖

1）什么是業務流程

業務流程是不同角色，完成業務目標的先后順序，是一系列步驟、程序，是對每個環節進行的程序化處理。

角色可以是任何對象，例如人、系統、部門、公司…

一個業務流程由多個連續的活動組成，復雜的業務流程還分為子流程。

業務流程有多種類型，例如部門人與人之間的業務流程、用戶(人)與系統(產品)的交互業務流程、系統與系統之間的業務流程。

人與人之間的業務流程如公司的請假、調休、轉崗、離職等，OA系統里面會有很多這種流程。

人與系統的業務流程如注冊、登錄、找回密碼這些基礎流程，還有如打車、叫外賣、購物的業務流程。系統可以看作是一個黑箱子，箱子里面又包含有前端和后端等。

系統與系統的業務流程主要在于進行數據交互，系統使用結構化設計，將整個系統拆分成很多聚合度很高、耦合度很低的模塊，模塊之間除了內部交互外，還需要外部系統進行交互，系統之間的交互通常使用接口。

每個業務流程都由多個連續的活動組成，例如請假這個業務流程，里面的活動有填寫請假單、審批請假單等活動。注冊的流程涉及填寫手機號、獲取驗證碼、輸入密碼等活動。

2）業務流程分析

業務流程分析就是在開始動手畫之前對業務和執行過程進行詳細的調查，并回答以下問題：

（1）業務流程的目的或者想達到的目標是什么？

（2）業務流程從哪里開始？如何完成？包含哪些活動和步驟？結束的條件是什么？

（3）這個業務流程有哪些角色參與？

（4）流程的活動之間有哪些控制流（判斷、同步分支和匯合，稍后會說到）業務流程畫法

3）業務流程圖的基本元素

業務流程圖的基本元素包括：活動、判定、開始和結束、文檔、數據、控制元素，如下圖：

不論用什么工具，記住這幾個基本元素，就可以覆蓋所有的業務流程。不管什么流程圖，都可以僅用以上幾個元素表達，比如跨部門職能流程圖，就是加泳道而以，頁面流程圖，可以用『文檔/數據』那個元素表示。

4）繪制業務流程圖的注意事項

繪制業務流程圖，應該注意以下幾點：

a. 首先從核心業務流程圖入手，它們是系統中起關鍵作用的部分。

b. 繪圖應該根據流程方向盡量從上至下、從左至右，保持一致性。

c. 使用統一的符號。

d. 一個流程只有一個起點，有一個或多個終點。

e. 盡量避免交叉，并行的活動采用并行元素。

f. 盡量識別出表格和文檔。

5）幾種常見流程示例

① 人與人

以某高校期末考試流程為例，期末考試前，教務處負責安排全校課程的考試時間和地點，下發『考試安排表』。

正式考試之前，各任課老師準備好試卷，填寫『試卷審批表』，交由系主任審批簽字，簽字后再交由教務處打印試卷。

學生參加考試并答卷，產出成績單，任課老師閱出成績，并將答卷封裝存檔，如果不及格，教務處安排補考。

② 人與系統

③ 系統與系統

在梳理系統與系統之間的業務流程圖時，切記不要梳理得太細。

不要在流程圖上體現太多的分支流程和異常流程。

如果過細的話，會把這份流程圖變得非常復雜，可讀性太差。

最后，因為過于復雜而沒人愿意看，自己后面看的時候可能都會繞暈，開發測試更是不愿意看。

最好的做法是，核心系統間的流程圖簡要描述即可，通過這個圖重點描述幾個事情：

1、核心業務，涉及到多少個系統。

2、系統之間，如何進行交互和流轉。

3、在這些流轉過程中，分為幾個大的步驟（縱向分階段）。

然后，對復雜的業務邏輯，通過單個業務流程圖來進行拆解。

在單個業務流程圖中，盡量廣而全地描述分支流程和異常流程。

3. 狀態機圖

狀態圖，用于描述某個實體的狀態變化和流轉規則。

狀態機圖對于梳理業務邏輯和開發實現，有很大的幫助。在實際工作場景中，寫一大堆文字來描述狀態流轉，效果通常都不太好。對于狀態定義及流轉的描述，狀態機圖是最好的工具，沒有之一。

狀態描述最常見的應用場景，是對各類訂單的描述，如電商的訂單狀態、快遞物流狀態、支付狀態等。

狀態機也不復雜，只需遵循以下幾個原則，即可畫出高質量的狀態機圖：

1、有限集合。狀態都是有限的，需要枚舉所有狀態。并且每個狀態都能體現一個實體的某個階段。

2、狀態互斥。狀態之間，一定沒有重合的地方，必須互斥。

3、可能具備子狀態。子狀態的前提，是有子訂單，比如，電商的主訂單是購物訂單，基于這個購物訂單，衍生出了支付訂單、物流訂單、售后訂單，在待發貨這個狀態下，有退款中和退款完成兩個子狀態。

4、持續一定時長。狀態是能持續一定時長的，而不是瞬間狀態，比如創建一個訂單，創建這個過程，由代碼執行，需要一定的時間，但是很短暫，我們如果定義一個“創建中”的狀態，就沒有必要。

5、包括已中待其中一個詞。定義一個狀態時，通常使用“已”、“中”、“待”其中一個。

以下是一個電商訂單的實例：

從示例圖中，我們可以看出，一個完整的狀態機圖，包含幾個核心要素：

1、開始和結束。開始通常代表產生對象的開始，結束代表狀態已經進入終態。

2、狀態流轉的條件。從一個狀態流轉到另外一個狀態，必定有1個或多個事件。

3、狀態本身。定義訂單當前的階段。

狀態機圖跟實體關系圖一樣，畫法很簡單，但是代表的是對狀態的定義和規則的思考，幫助巨大。

可以使用ProcessOn、Visio、Axure就可以很方便地畫出來。

4. 小結

對產品/功能完成建模后，我們就完成需求分析很重要的一步，我們來總結下這三個建模工具：

使用ER建模和流程建模，其實背后還代表著一種設計思想。

ER圖代表DDD，即領域驅動設計，我們在梳理ER圖的時候，可以識別所有業務對象，這本身也是一個熟悉陌生領域的過程。

流程圖代表PDD，即流程驅動設計，在梳理業務流程圖的過程中，考慮更細節的分支流程和異常流程，從而可以補全用戶故事地圖，從而真正做到既有廣度，又有深度。

另外，其實還有一些其他的建模工具，如用例圖、時序圖。感興趣的朋友可以自行去研究，刀哥公眾號也有相關的文章。

刀哥認為，熟練掌握這3個建模工具，就可以覆蓋工作中大部分的場景了。

七、如何管理用戶需求和產品需求？

1. 原始需求和產品需求

前面我們說過，需求有用戶需求和產品需求。

用戶提交的需求，還沒有經過深入思考，整理解決方案的，叫做原始需求。

使用逆向分析法，對原始需求進行進一步的挖掘，然后整理出可交付給研發實施的需求，叫產品需求。

原始需求和產品需求是多對多的關系，多個原始需求可能對應同一個產品需求。

一個原始需求，也可能對應多個產品需求。

比如在B端系統上，業務方提出，希望做一個會員系統，這是一個原始需求。

但是對應的產品需求，可能包括積分模塊、成長值模塊、優惠券模塊、還有對前端APP的改造，包括很多模塊。

原始需求，提交方通常是帶著方案來的，我們千萬不要把用戶的方案當方案，而是用戶提案背后的真實目的。

C端產品，可能對應到馬斯洛模型。B端產品，可以使用逆向分析法。

C端產品，用戶可能并不會直接提出需求，需要很強的洞察力和同理心，去感知用戶的需求。

B端產品，可以讓提交人提交一個需求提報表，讓提交人重點描述背后的期望以及想實現的價值。

需求提報表，核心包括提交人、優先級、問題描述、預期目標、預期收益、期待解決方案、期待上線日期等字段。

需求提交的模板可以在刀哥產品資料集里面獲取，關注刀哥公眾號，即可獲取。

2. 需求的類型和價值

需求按照軟件工程這個維度分，可以分為功能需求和非功能需求。

按照不同提交主體，又可以分為業務需求、用戶需求和技術需求。

業務需求是由中高層提出，主要是一些策略和管理制度等，如績效規則、風控策略、規則制度……

用戶需求由一線產品直接使用者提出，主要使用產品具體的體驗以及相關利益，可以使用客戶旅行地圖這個模型去分析。

技術需求是由技術提出，為了提升系統的擴展性、易用性，更好的服務業務，技術要做一些技術優化，很多時候，隨著業務的發展，技術架構不能滿足業務發展的需求時，需要進行重構。

在做任何一個需求時，我們都需要思考實現這個需求的價值，從不同的角度出發，需求有以下幾種價值：

商業價值。能否為公司帶來收益？

業務價值。能否降本增效或者提高安全、風控？

用戶價值。能否解決用戶問題，或帶來“效用”？

技術價值。能否提升產品的擴展性、易用性？

3. 如何管理需求池？

不管從什么渠道，接到什么需求，第一步我們都記錄到原始需求池。

然后根據模塊，由不同的產品人員負責并分析，然后變更原始需求池的狀態。

原始需求經過分析后，有些可能是偽需求，有些實現后可能也沒什么價值，有些轉成了產品需求。

轉成產品需求后，再記錄到產品需求池里，根據項目進度進行維護更新。

還記得之前說的ER圖嗎？我們把原始需求和產品需求看成兩個實體，就是以下關系：

管理需求池，可以用TAPD或禪道這樣的工具，在項目團隊內可以很好的流轉，如果團隊配合得好，使用規范的話，可以導出需求池，隨時知曉需求的整體進度。

但是項目工具使用不規范，我們有時還得借助Excel的工具，由專人進行維護（通常是項目經理），才能更好的管理好需求池。刀哥的公眾號有Excel版本的需求池模板，大家可以自行去獲取并下載。

4. 如何衡量需求的優先級？

需求的優先級，需要從多個維度進行綜合評估，包括公司戰略、市場動態、競爭對手、內部資源等。

但是歸納起來，就這幾個核心點：

• 投產比：可量化的需求，投入多少研發資源，可以獲得多少收益。收益可能直接給公司帶來的營收，也可能是間接的降本增效。
• 風控：不太好量化，但是處理了這類需求，就可降低外部用戶薅羊毛的風險，內部飛單的風險，系統崩潰的風險等。
• 合規：不太好量化，但是如果不處理這里需求的話，可能面臨被有關部門處罰，APP下架等。
• 體驗：不太好量化，但是處理以后可以提升用戶的使用體驗，比如更好的交互，更快的響應速度，更好的情緒感受。

但是，我們做任何一個需求，盡量都要去量化。

刀哥一直記得一句很經典的話，沒有量化的產品，就像沒有儀表盤的飛機，是盲飛，你敢坐盲飛的飛機嗎？

量化后的數據，可以給產品經理提供決策依據。量化后才能更好的驗證需求是否達成了預期。

量化有幾個思路。

1、看業務指標?？瓷暇€后的需求是否帶來業務增量。

2、看行為指標。通過埋點，統計使用次數、人數及轉化率?？垂δ艿氖褂们闆r，

2、看NPS。通過凈推薦值，看用戶的綜合主觀評價。

5. 小結

需求分為原始需求和產品需求，原始需求是用戶提出的，產品需求是產品經理經過思考和分析提出的。

需求有業務需求、用戶需求和價值需求。需求的價值有商業價值、業務價值、用戶價值和技術價值。產品經理要能夠識別需求的類型和價值，才能做出更好的分析。

管理需求池可以利用項目管理工具，也可以簡單地用excel，管理的重點是跟進與維護。

需求的優先級可以通過投產比，安全，合規等幾個方面去考慮。

做需求，一定要量化，有量化，才能驗證需求是否符合預期，通過收集需求，做方案，看數據，才能形成有效的項目循環，并提升能力。

八、一個需求的一生

一個需求，從挖掘到分析、調研，再到整理成產品需求，再到研發測試上線，用下面這張圖，可以很好呈現。

這張圖來自騰訊的TAPD，這里又要安利下這個項目管理工具，可以管理從需求到交付的全過程。

了解需求的全生命周期，也就掌握了項目管理的核心方法，項目管理的起點，就是需求。

首先，產品經理規劃需求，需求可能來自于業務、技術或者用戶，經過分析，將這些需求按照一個一定顆粒度拆分，每個需求都有可能研發的詳細需求文檔。

然后，將這些需求組合，按照優先級，形成發布計劃。研發根據發布計劃拆分任務，規劃迭代，進入研發，研發完成后，產品經理驗收，并交付給需求方。

最后，需求對應的功能上線后，產品經理去收集用戶反饋，分析功能的使用情況，是否有達到預期，然后根據分析結果，再次迭代優化。

九、寫在最后

需求分為用戶需求、產品需求、市場需求和商業需求。用戶需求使用逆向分析法、產品需求使用UML、市場需求商業需求使用精益畫布，不同需求，分析的工具和方法論不一樣。

做好需求分析，可以讓正確的事情相繼發生，讓產品有價值、研發有價值。

需求來自于場景，產品經理必須認知到這一點，只有熟悉了場景，才能理解用戶，做出好的解決方案。

分析用戶需求，可以使用用戶故事地圖法，使用用戶故事地圖，可以做到既見森林，又見樹木。

挖掘用戶真實的需求，可以使用逆向分析法，用戶會說需要一匹更快的馬，但想要的是更安全快速到達目的地。

產品需求建模三大工具，掌握這3個工具，就能梳理邏輯縝密的需求方案，這三個工具是ER圖、流程圖和狀態機。

需求有業務需求、技術需求和用戶需求，不同的需求對應的價值也不一樣。

需求的優先級，可以從投產比、風控、合規等方面考慮，需求一定要量化，量化才能衡量，量化可以從幾個角度去考慮，業務指標、行為指標和NPS。

一個需求，從誕生到最后實現，需要經過一系列的過程，可以使用敏捷開發的思路，認識了需求的生命周期，是做好項目管理的基礎。