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