前言
需求分析，是產品設計的前置過程。由於產品經理身處於溝通的中心，我們需要在很短的時間內評估需求的價值，並給出解決方案。
一個需求會在產品經理的腦海裏經過什麼過程呢？本文將從需求的分析、拆解以及優先級評估這三個維度分享一些方法，希望能夠給大家帶來一些啓發。
一、需求分析的方法
1、基礎元素分析法
第一個方法從需求的完整度出發，目標是挖掘真正需求。一個完整的需求至少需要包含圖1中的4個元素，分別是：
1-1、需求的背景
需求的背景指的是動機，這一項實質上是換位思考，它能夠幫助我們從業務方的角度，從使用場景、用戶心理去理解需求。
在實際工作中，我們所接收到的“需求”常常是表述不清晰的、不完整的，甚至是具有欺騙性的。一個問題會對應許多的解決方案，找到真正的需求，也正是我們的職責。
1-2、需求的受衆
需求的受衆需要注意的問題有兩點：
1）誰是真正的受衆
2）受衆人羣是否具有代表性
需求的來源很多，可能是用戶、業務方等等。我們需要分清楚誰纔是真正的受衆。在一個需求裏不同的角色認知和訴求是不同的，當信息帶上了主觀判斷也就被污染了。
其次則是覆蓋度的問題，對於頻次不夠高或者人羣不夠有代表性的需求，投入產出比會是一個大大的問號。辨清受衆，在評估需求的優先級和制定解決方案時，迷惑性會大大降低。
1-3、需求的目的
需求的目的指需要做什麼，很多時候我們接到的“需求”其實是業務方過濾後的“解決方案”。
以“口渴”爲例，此時業務方提出的需求是要製作一臺飲水機，然而飲水機並不能解決問題。如果我們挖掘到背後的動機是“口渴”，那麼我們可以從補充水分和減少水分的流失來着手提供解決方案。
1-4、需求的目標
在漢語辭典裏的解釋，目的是期望，而目標是成果。目標更爲具象，並且能夠用數據指標來衡量，後續也能夠指導需求的改進。
需求的本質是爲了創造價值，而創造價值最直白的則是開源和節流。具象到目標，可以用創造的收益，提升的效率以及節省的資源等方面進行量化。
2、因果關係分析法
當需求具有上述的4個要素，下一步則是分析邏輯是否足夠嚴密，在這裏我們可以使用因果關係分析法。
圖2用因果關係表述：“因爲某用戶的某個原因，所以希望做某事。”
通過窮舉法獲得更多的因果關係類型，如圖3所示：
窮舉完畢後，我們開始對因果關係進行辯證：
1）原因是否真實？
2）這個原因一定會引起這個結果嗎？
3）這個結果，是否還有其他的原因導致？
...
前陣子恰好收到一個典型的“需求”：
“因爲app註冊頁面改版了，導致註冊數據下降，所以要優化app註冊頁面。”
將這個例子代入上述的3個問題：
1）app註冊頁面是否改版？
答：改版了。
2）app註冊頁面改版一定會導致註冊數據下降嗎？
答：不一定，只能回答有可能。
3）註冊數據下降，優化app註冊頁面一定有作用嗎？
答：不一定，只能回答有可能。
4）註冊數據下降有沒有別的原因導致？
答：渠道推廣減少、投放的渠道匹配度不高、平臺老帶新活動減少等。
經過這樣的分析，我們會發現這個需求的邏輯存在問題，業務方將相關關係轉換爲了因果關係，將關聯原因轉換爲了直接原因。
對於多種原因導致的結果，數學中會使用多元迴歸分析來發現問題。只着眼於一點，這樣的需求就非常經不起推敲了。
3、公式法
明辨了因果之後，我們開始進一步細化。
假設上文所述的註冊人數下降僅受app改版影響，可以繪製出用戶在下載後註冊和登錄的訪問路徑，如圖4所示：
方法也非常簡單，通過時間順序繪製用戶每一步的操作即可。繪製完畢後我們發現，影響註冊數據原因可能是因爲下載之前的流量降低，或者是後續環節的流失率增加。
在這裏我們將抽象的需求轉換爲具象的公式，根據公式優化每一環節的數據指標。
根據圖4，我們可以列出如下的公式：
1）app註冊人數=手機號註冊人數+微信註冊人數
2）微信註冊人數=進入註冊頁面人數-進入註冊頁面人數*跳失率-登錄人數-點擊手機號登錄註冊人數
3）手機號註冊人數=進入註冊頁面人數-進入註冊頁面人數*跳失率-登錄人數-點擊微信登錄註冊人數-進入手機號登錄頁面人數*跳失率-選擇切換登錄方式人數-輸入手機號未獲取驗證碼人數-輸入驗證碼未登錄人數
羅列公式並代入近期的數據進行對比，就能夠發現是哪個環節的數據指標下降了，優化那個數據指標也正是我們的需求。
二、需求的拆解
當明確了我們的需求知道要做什麼，下一步則是對需求的拆解，從而建立產品設計的框架，這個環節我推薦的是UML拆解法。
UML（Unified Modeling Language）其中文的翻譯是統一建模語言，這種方法主要運用於系統設計。這是一種非常好的解構方法，能夠幫助我們在產品設計時邏輯更爲清晰、全面。這種方法有興趣的朋友可以閱讀相關的書籍，在這裏僅做進行簡單介紹。
1、用例圖
圖5-用例圖
用例圖（Use Case Diagram）是顯示一組用例、參與者及它們之間關係的一種圖。在這裏左邊的參與者（Actor）不僅是真實的用戶，還有關聯繫統，這個圖例能夠幫助我們梳理關聯的業務方，明晰系統的邊界以及應當提供的功能。
目前在網絡上有一些倒推某產品PRD的文章或者體驗報告，其拆解方式是從頁面出發倒推功能，這種方式個人認爲會有些取捨不當，我們更應該從用戶和系統的層面進行去設計功能。
2、時序圖
時序圖在百度百科的解釋爲：“通過描述對象之間發送消息的時間順序顯示多個對象之間的動態協作。它可以表示用例的行爲順序，當執行一個用例行爲時，其中的每條消息對應一個類操作或狀態機中引起轉換的觸發事件。”
簡而言之，時序圖是功能與內外部系統之間的交互，表示其每一步的請求以及返回數據的過程。時序圖和產品工作中所使用的泳道圖非常相近，理解時序圖能夠幫助我們理解系統的邊界及耦合程度。
如果在產品設計中常常撰寫相同的功能邏輯，可以考慮將其抽象成爲一個單獨的中臺系統供業務方使用，節省資源也使設計的系統延展性更強。
3、狀態機
用例用於枚舉功能，時序用於理解系統的交互，在產品設計中還有很常見一類設計是狀態的轉換，這是用例圖和時序圖所覆蓋不了的。如權限的控制、用戶交互的切換、狀態的轉移等，更具體的例子可以參考秒殺活動的前中後前端的交互、電商平臺中訂單狀態的切換。
這些場景我們會使用狀態機來描述。狀態機泛指有限狀態機，表示有限個狀態以及在這些狀態之間的轉移和動作。對於複雜的狀態，文字描寫會相對無力，這個時候狀態機就能夠派上用場了。
以上的三種圖像是產品經理需要去理解的，這也是技術評審中所會接觸到知識點。在這裏並不是建議使用這種方式撰寫需求文檔，而是學習UML對需求的解構方法。
在系統設計中產品經理還需要關心的是數據庫的表結構設計，它會影響到後續數據是否能夠提取。
三、需求優先級的評定
最後一個環節是需求優先級的評定，我常用的方法是選取影響優先級的因素並設定比例，經過加權計算出優先級，分數越高優先級越高。
其公式如下：
優先級=因素1比例*因素1分值+因素2比例*因素2分值+....
這張表，影響的因素主要有兩項：投入產出比以及重要程度。投入產出比個人認爲是必選的，而重要程度中的維度可以根據實際情況去增加、減少。同理，加權中比例的設置也是如此。
經過了這3個環節，需求分析也大致結束了。在需求分析中，我們不必要拘泥於具體的某個方法，適合纔是最好的。
沒想到腦海裏迅速完結的過程寫了這麼多，感謝你看到這裏，謝謝。