需求分析，是產品設計的前置過程。

由于產品經理身處于溝通的中心，我們需要在很短的時間內評估需求的價值，并給出解決方案。

一個需求會在產品經理的腦海里經過什么過程呢？本文將從需求的分析、拆解以及優先級評估這三個維度分享一些方法，希望能夠給大家帶來一些啟發。

一、需求分析的方法

1. 基礎元素分析法

圖1-需求的基礎元素

第一個方法從需求的完整度出發，目標是挖掘真正需求。

一個完整的需求至少需要包含圖1中的4個元素，分別是：

1.1 需求的背景

需求的背景指的是動機，這一項實質上是換位思考，它能夠幫助我們從業務方的角度，從使用場景、用戶心理去理解需求。

在實際工作中，我們所接收到的“需求”常常是表述不清晰的、不完整的，甚至是具有欺騙性的。

一個問題會對應許多的解決方案，找到真正的需求，也正是我們的職責。

1.2 需求的受眾

需求的受眾需要注意的問題有兩點：

1. 誰是真正的受眾；

2. 受眾人群是否具有代表性。

需求的來源很多，可能是用戶、業務方等。我們需要分清楚誰才是真正的受眾。

在一個需求里不同的角色認知和訴求是不同的，當信息帶上了主觀判斷也就被污染了。

其次，則是覆蓋度的問題。對于頻次不夠高或者人群不夠有代表性的需求，投入產出比會是一個大大的問號。辨清受眾，在評估需求的優先級和制定解決方案時，迷惑性會大大降低。

1.3 需求的目的

需求的目的指需要做什么，很多時候我們接到的“需求”其實是業務方過濾后的“解決方案”。

以“口渴”為例，此時業務方提出的需求是要制作一臺飲水機，然而飲水機并不能解決問題。如果我們挖掘到背后的動機是“口渴”，那么我們可以從補充水分和減少水分的流失來著手提供解決方案。

1.4 需求的目標

在漢語辭典里的解釋，目的是期望，而目標是成果。

目標更為具象，并且能夠用數據指標來衡量，后續也能夠指導需求的改進。

需求的本質是為了創造價值，而創造價值最直白的則是開源和節流。具象到目標，可以用創造的收益，提升的效率以及節省的資源等方面進行量化。

2. 因果關系分析法

當需求具有上述的4個要素，下一步則是分析邏輯是否足夠嚴密，在這里我們可以使用因果關系分析法。

圖2-需求目的的推導

圖2用因果關系表述：“因為某用戶的某個原因，所以希望做某事。”

通過窮舉法獲得更多的因果關系類型，如圖3所示：

圖3-因果關系類型

窮舉完畢后，我們開始對因果關系進行辯證：

• 原因是否真實？

• 這個原因一定會引起這個結果嗎？

• 這個結果，是否還有其他的原因導致？

• ……

前陣子恰好收到一個典型的“需求”：

“因為APP注冊頁面改版了，導致注冊數據下降，所以要優化APP注冊頁面。”

將這個例子代入上述的3個問題：

1. APP注冊頁面是否改版？答：改版了。

2. APP注冊頁面改版一定會導致注冊數據下降嗎？答：不一定，只能回答有可能。

3. 注冊數據下降，優化APP注冊頁面一定有作用嗎？答：不一定，只能回答有可能。

4. 注冊數據下降有沒有別的原因導致？答：渠道推廣減少、投放的渠道匹配度不高、平臺老帶新活動減少等。

經過這樣的分析，我們會發現這個需求的邏輯存在問題，業務方將相關關系轉換為了因果關系，將關聯原因轉換為了直接原因。

對于多種原因導致的結果，數學中會使用多元回歸分析來發現問題。只著眼于一點，這樣的需求就非常經不起推敲了。

3. 公式法

明辨了因果之后，我們開始進一步細化。

假設上文所述的注冊人數下降僅受APP改版影響，可以繪制出用戶在下載后注冊和登錄的訪問路徑，如圖4所示：

圖4-用戶路徑

方法也非常簡單，通過時間順序繪制用戶每一步的操作即可。繪制完畢后我們發現，影響注冊數據原因可能是因為下載之前的流量降低，或者是后續環節的流失率增加。

在這里我們將抽象的需求轉換為具象的公式，根據公式優化每一環節的數據指標。

根據圖4，我們可以列出如下的公式：

• APP注冊人數=手機號注冊人數+微信注冊人數

• 微信注冊人數=進入注冊頁面人數-進入注冊頁面人數*跳失率-登錄人數-點擊手機號登錄注冊人數

• 手機號注冊人數=進入注冊頁面人數-進入注冊頁面人數*跳失率-登錄人數-點擊微信登錄注冊人數-進入手機號登錄頁面人數*跳失率-選擇切換登錄方式人數-輸入手機號未獲取驗證碼人數-輸入驗證碼未登錄人數

羅列公式并代入近期的數據進行對比，就能夠發現是哪個環節的數據指標下降了，優化那個數據指標也正是我們的需求。

二、需求的拆解

當明確了我們的需求知道要做什么，下一步則是對需求的拆解，從而建立產品設計的框架，這個環節我推薦的是UML拆解法。

UML（Unified Modeling Language）其中文的翻譯是統一建模語言，這種方法主要運用于系統設計。這是一種非常好的解構方法，能夠幫助我們在產品設計時邏輯更為清晰、全面（對這種方法有興趣的朋友可以閱讀相關的書籍，在這里僅做進行簡單介紹）。

1. 用例圖

圖5-用例圖

用例圖（Use Case Diagram）是顯示一組用例、參與者及它們之間關系的一種圖。

在這里，左邊的參與者（Actor）不僅是真實的用戶，還有關聯系統，這個圖例能夠幫助我們梳理關聯的業務方，明晰系統的邊界以及應當提供的功能。

目前在網絡上有一些倒推某產品PRD的文章或者體驗報告，其拆解方式是從頁面出發倒推功能。這種方式個人認為會有些取舍不當，我們更應該從用戶和系統的層面進行去設計功能。

2. 時序圖

圖6-時序圖例圖

時序圖在百度百科的解釋為：“通過描述對象之間發送消息的時間順序顯示多個對象之間的動態協作。它可以表示用例的行為順序，當執行一個用例行為時，其中的每條消息對應一個類操作或狀態機中引起轉換的觸發事件。”

簡而言之，時序圖是功能與內外部系統之間的交互，表示其每一步的請求以及返回數據的過程。

時序圖和產品工作中所使用的泳道圖非常相近，理解時序圖，能夠幫助我們理解系統的邊界及耦合程度。

如果在產品設計中常常撰寫相同的功能邏輯，可以考慮將其抽象成為一個單獨的中臺系統供業務方使用，節省資源也使設計的系統延展性更強。

3. 狀態機

圖7-狀態機例圖

用例用于枚舉功能，時序用于理解系統的交互，在產品設計中還有很常見一類設計是狀態的轉換，這是用例圖和時序圖所覆蓋不了的。如權限的控制、用戶交互的切換、狀態的轉移等。更具體的例子可以參考秒殺活動的前中后前端的交互、電商平臺中訂單狀態的切換。

這些場景我們會使用狀態機來描述。

狀態機泛指有限狀態機，表示有限個狀態以及在這些狀態之間的轉移和動作。對于復雜的狀態，文字描寫會相對無力，這個時候狀態機就能夠派上用場了。

以上的三種圖像是產品經理需要去理解的，這也是技術評審中所會接觸到知識點。在這里并不是建議使用這種方式撰寫需求文檔，而是學習UML對需求的解構方法。

在系統設計中產品經理還需要關心的，是數據庫的表結構設計，它會影響到后續數據是否能夠提取。

三、需求優先級的評定

最后一個環節是需求優先級的評定，我常用的方法是選取影響優先級的因素并設定比例，經過加權計算出優先級，分數越高優先級越高。

其公式如下：

優先級=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求評估加權表

這張表，影響的因素主要有兩項：投入產出比以及重要程度。

投入產出比個人認為是必選的，而重要程度中的維度可以根據實際情況去增加、減少。同理，加權中比例的設置也是如此。

經過了這3個環節，需求分析也大致結束了。在需求分析中，我們不必要拘泥于具體的某個方法，適合才是最好的。