前言：面對千變萬化的需求，也許很難抽象出一套普適的方法論，不妨一起來看看需求分析過程中的那些常見套路，或許能有一些值得借鑒和思考。

當我們接到一個新需求點時，應遵循的需求分析步驟有哪些？

首先，要根據需求設計功能，就要做到理解需求的來龍去脈。為此，需要搞清楚以下問題：

1、需求產生的原因

當需求方向你闡述完某個需求后，向她詢問：提這個需求的目的是什麼？即為什麼會產生這個需求？這個問題幫你完全理解需求，幫你辨別需求的真偽。

2、需求使用場景

即搞清楚什麼人在什麼情況下會用到此功能。只有明白了這個，才知道如何更好地設計功能來滿足需要。

在需求場景模擬的過程中，為了避免設計的功能因擴展性不足，通過不斷的推導，在一開始，就應該做儘可能全面的考慮。通過需求方的場景，擴展思考，是否存在衍生的場景。思考的過程，也是幫助你抓住和理解需求本質的過程。

3. 辨別真假需求

不要誰的需求都聽，每個人都有自己的想法，也有自己的需求，沒有哪個產品能滿足所有用戶，系統分析需求之前應該先搞清楚需求提出人身份，是目標用戶嗎？是產品重度使用者嗎？是功能服務對象嗎？不是說來源不可靠的需求就完全不做分析，但這一點也需要考慮在你的分析範疇內。

我們接到需求后，充分理解了需求后，跟團隊夥伴一起花個時間討論一下，聽聽他們的意見和建議對需求的考慮。通過此過程，基本上對需求點及實現方式達成一致，在後期正式開發時，會減小很多阻礙

4、 需求解決方案

當我們弄清楚了用戶需求后，就需要提供一個產品解決方案來解決用戶的需求，在提供解決方案的時候，我們不能只考慮用戶需求，還需要考慮戰略的需求，老闆的需求，產品運營的需求，業務人員的需求，競爭的需求，作為產品經理自己本身的價值觀需求等，基於這些需求，我們來構建產品，在這個產品方案裡面會有很多產品的功能，這個功能就是我們常說的產品需求。

5、 開啟版本迭代，細化需求

提交需求就是把產品需求完整清晰的告知給需要協作的小夥伴，讓他們清楚的了解產品的需求， 一般通過以下三個交付物來告知：

• 產品流程圖

產品流程圖是說明產品操作和相應過程的文檔，一般有兩類：

一類是業務流程圖，基於業務邏輯來設計，一般包含主要流程和功能模塊，用來說明產品的架構；

另一類是功能流程圖，一般基於用戶任務來設計，包含人物角色，操作過程的關鍵節點，狀態，判斷，結果等

• 產品原型

上面的流程圖主要偏重於對產品後端和邏輯的描述，而產品原型的作用正好與流程圖互補，偏重於對產品界面信息架構，跳轉邏輯和交互功能的展示說明，通過產品原型，可以將抽象的產品具體化，讓產品更容易被理解，產品原型一般由線框圖構成，在業界大部分人使用axure來製作，有的公司有交互設計師，原型製作工作由交互設計師來承擔，大部分互聯網公司是沒有交互設計師的，所以產品原型一般由產品經理來完成，一般長下面這樣:

• 產品需求文檔

產品需求文檔，簡稱prd,主要以文字形式來闡述產品的詳細需求，與流程圖，產品原型配合使用來說明產品需求，核心內容是對要實現的每個產品功能及裡面用戶角色、前置條件、後置條件、界面、流程，數據統計等內容的描述，主要面向研發人員，使用word來撰寫和閱讀。

以上這三種交付物是產品經理協作過程中比較常見的交付物，尤其是在大公司中這些是必備的。但這不是強制的標準，很多中小公司都沒有產品文檔這個部分，有的直接用產品原型標註文字說明來做文檔，有的是用excell來寫文檔，所以具體的交付物根據自己所處公司的實際要求來看，這些交付物的目的是為了輔助溝通，不管什麼樣的交付物，只要能達到簡單，快速，高效溝通的目的就可以。

6、評審需求

在提交了產品需求后，需要組織研、運營、設計、測試等人員對產品需求評審，在評審過程中，對產品的目標、背景、問題、思路、解決方案等進行介紹，評審的目的一個是為了讓產品更完善，更具有可行性，另一個目的，也是讓所有參與實施的人員對產品需求認可，目標達成一致，只有被所有參與人員認可並評審通過的產品需求才能被開發，評審是產品工作中非常重要的環節，如果這部分工作做不好，開發過程中的摩擦和修改需求的概率非常大。

結語：需求分析是基於用戶溝通、背景認知、人性理解，層層還原一個需求本源的過程。我們對一個需求的還原程度越高越准，越有機會在後續產品設計給出合理的方案。

創享學院一家專註於互聯網產品經理的實訓基地

產品夢，創享圓