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