本文主要講述了產品經理如何做好需求分析，包括兩個核心要點：識別評估需求價值和規范需求分析流程，以及具體實施的八個步驟。

產品經理要經常處理的工作之一，那一定是需求分析了。

需求分析做得好，產品方案落地效果佳。反之，輕則浪費團隊資源時間、重則被業務方開會聲討，甚至私下給老板打你小報告。

如果這種情況持續發生，那這產品經理的小小崗位，怕是遲早會被公司優化領盒飯去了~

當我經過 1200+ 業務需求落地的花式吊打后，發現產品經理要做好需求分析，其實核心就兩點：識別評估需求價值、規范需求分析流程。

一、需求價值的 2 種評估方式

在進行需求分析前，我們一般要先對需求池中的內容，進行相關的價值評估。

需求價值評估一般有兩種方式：需求即時評估、需求定期評估。

需求即時評估，指的是每當接到新需求時，就進行需求價值的大致判斷，并完成需求池的相關排序和記錄。

你也可以定期對需求池統一進行價值評估，頻率可以是幾天、一周、甚至個把月，怎么開心怎么來，這主要取決于需求量大小。

我的習慣是這兩種方式結合使用，復雜需求等到抽空統一處理，而一些簡單需求在接到的那一刻，就完成了初步價值判斷。

這樣做的好處是，日積月累下你對需求池整體價值的把握了然于胸。

二、識別需求價值的 7 個維度

那如何才能判斷一個需求的價值高低呢？

你可以從“戰略契合、市場潛力、商業價值、符合目標、覆蓋人群、使用頻率、研發成本”等 7 個維度進行評估：

• 戰略契合：并不是什么需求都必須要做，如果需求與用戶畫像沖突、年度戰略規劃不符，即使需求價值再高也不做；
• 市場潛力：相關需求的未來市場有多大？例如 iPhone 面世后，原先全球的手機用戶，未來將面臨更新換代的需求；
• 商業價值：通過落地需求方案，能直接、間接為公司帶來多少增量收入；
• 符合目標：通過產品專業的需求挖掘，確保業務方提出的需求，符合其業務目標的占比有多大；
• 覆蓋人群：需要考慮有同樣需求的用戶，到底是什么量級；
• 使用頻率：推測出每個用戶在一年中，遇到該需求的頻率；
• 學習成本：提供的方案，對用戶來說，是否能快速學會和易于上手；
• 研發成本：一個需求開發落地，所需要的工作日時間。

在日常工作中，接到新需求不一定都要考慮這么多因素，你可根據實際情況，進行刪減部分。  

一些小功能需求，稍微考慮“覆蓋人群、使用頻率、研發成本”也夠了。

完成了這個步驟后，你對需求池內容也有了大致印象，接下來就是挑出近期要落地的需求，按價值高低逐一進行需求分析了。

三、需求分析 8 步法

我在需求分析時，一般會進行這 8 個步驟：需求背景、目標受眾、數據分析、業務規則、功能場景、版本目標、功能說明、版本規劃。

可以說，一個需求經過這個框架思考后，后面的產品文檔撰寫就順利多了。

1. 需求背景

進行需求分析的最重要一個步驟，就是了解需求背景。

產品經理在描述需求背景時，一般會通過第三方視角（例如某業務角色-銷售）分析需求方的相關 3 個要素：現狀、問題、期望。

• 現狀：說明需求方的業務現狀和需求起源是什么；
• 問題：弄清楚他們當前遇到的問題或難點；
• 期望：假設條件、資源都滿足的情況下，需求方期望達到的理想狀態是怎樣的。

2. 目標受眾

目標受眾的分析步驟，需要你羅列出需求涉及的相關群體。

并對其完成“人群特征、消費習慣、需求痛點”等方面的深入了解。

模版參考：

關聯方涉及：A、B、C

A：人群特征、消費習慣、需求痛點

B：人群特征、消費習慣、需求痛點

C：人群特征、消費習慣、需求痛點

3. 數據分析

數據分析的目的，主要是通過數據反饋，快速了解需求的發生頻率和影響范圍。

我們一般在設計產品方案前，會去拉取相關功能數據，或市面上的行業報告，以此進行需求分析和趨勢預測。

目標是對需求落地有個大致預期和價值判斷，方便產品經理完成后續的版本排期工作。

4. 業務規則

業務規則，是基于公司的目標或利益，定義的工作標準或流程。

例如京東的送貨普遍次日達、自營七天無理由退貨。

還有拼多多最近熱議的僅退款服務，這些都可以算作業務規則。

我們在進行需求分析時，務必要和需求方溝通清楚，并弄懂業務規則的各種細節。

我的習慣是，單獨創建一個表格，管理歷史業務規則的細節內容，遇到業務問題查起來就方便多了。

5. 用戶場景

用戶場景，是產品經理根據用戶在特定的環境、動機、需求下，模擬想象出用戶行為的一種思考方式。

比如針對不同的吃飯需求，一般有這幾個場景

• 為了減肥吃一些清淡食物；
• 工作時圖方便我們會叫外賣吃；
• 出國在外，會去品嘗當地的特色美食；
• 半夜肚子餓了，跑到樓下吃個燒烤或夜宵；
• 和情侶約會，訂個逼格高的西餐廳共進晚餐。

我們可以通過這種方式，大致遍歷出某個需求的多個用戶場景，以此作為方案設計的參考依據。

6. 方案目標

當我做完前面幾個需求分析步驟后，一般在腦子里就會形成方案的大致思路了。

將方案思路進行延伸、抽象化思考，可以推導出更通用、普適的方案目標。

這個目標一般用一句話來概括，例如“基于需求方的多變運營活動需求，通過活動、任務、抽獎、獎品、賬戶等配置模塊，實現任意營銷活動功能”。

7. 功能說明

功能說明一般是方案目標的補充，大致概括下方案涉及的功能模塊有哪些，以及它們的作用。

例如：活動模塊，主要用來配置活動時間、活動內容等信息。

8. 版本規劃

完成了功能模塊的梳理，你還要根據功能特性和資源情況，平衡拆分好迭代版本。

并思考應該在什么時間、什么節點、什么節奏、用什么方案，完成你的整體規劃才合適，而且需要 ROI 收益最高。

順便分享下，一些關于版本規劃的經驗：

• 資源超級充裕時：你可以 C 端、后臺功能自研；
• 當資源略顯不足：C 端進行自研，功能可以通過數據庫配置，減少后續迭代維護成本；
• 如資源異常緊張：你還可以借用 A 項目接口，實現 B 項目上線。
• 資源完全不夠用：這個時候就要動點腦瓜子，發揮下產品經理的腦洞，直接用現成的開源項目，拼接組裝出一套可用的解決方案。

順便說下，如果你只是對一些簡單需求進行分析，那么以上的需求分析流程，可以簡化為“需求背景、方案目標、功能說明”這三步。