產品需求分析步驟詳解？

標籤：

作為產品經理，我們不要接到一個任務，內心就有一種莫名的衝動，想要馬上完成。我們應該靜下來慢慢規劃，想清楚，才是最重要的。需求亦是如此。

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

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

1. 為什麼會產生這個需求？

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

2. 什麼情境下會使用這個需求？

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

3. 是否有可能衍生出新的情境？

為了避免設計的功能因擴充性不足，後期推翻重來，在一開始，就應該做儘可能全面的考慮。通過需求方的情境，擴充思考，是否存在衍生的情境。思考的過程，也是協助你抓住和理解需求本質的過程。

4. 技術層面如何看待這個需求？

接到需求，並充分理解了需求後，跟架構師或技術負責人花幾分鐘時間討論一下，聽聽他從技術上對需求的考慮。通過此過程，你們基本會對需求點及實現方式達成共識，在後期正式開發時，阻礙會小得多。

5. 是否可納入backlog？

確認需求為真實需求後，將其納入到backlog中，並大致描述需求邏輯，方便項目群組成員對待開發工作心裡有數。（應注意backlog是已明確並經過去偽存真的需求，是指導項目組掌控項目的工具，而不是產品經理的備忘錄。同時粒度不宜過細，否則非常不利於維護和溝通使用）

backlog表頭及說明

6. 開啟版本迭代，細化需求

當要開啟一個版本的規劃時，我們從backlog中挑出高優先順序的若干個需求，並細化需求、制定反覆項目計劃。

細化某個需求點時，需要做的事情如下：

A. 版本功能列表說明

在版本功能列表中交代清楚需求在此次版本中的優先順序（高：必須做；中：進度緊張時，可不做）、類型（新增：此前沒有，需重新開發的功能；修改：功能已有，需做調整的功能；刪除：不再需要，刪除的功能）、描述（交代邏輯）、詳情（連結到對應的頁面）：

附在PRD文檔中的目前的版本功能列表說明

B. 商務程序說明

若需求點story較大，有涉及業務的流轉，則需首先梳理商務程序。流程的梳理不僅協助項目群組成員理解需求，也是協助自己梳理思路。

C. 設計頁面和互動

流程清楚以後，就可以著手設計原型了。此時，如下幾點要素是必不可少的考慮因素：

（1）頁面的名稱是什嗎？

設計一個頁面相當於創造了一個從來沒有的新東西，為了與其他東西進行區分，總要給他一個標識。故，每做一個頁面，應先給它命名，且這個名稱是獨一無二的。既然是名字，那麼名詞或動名詞是最合適的，但貴在語義表達準確，即讓閱讀者看到頁面名稱，就能八九不離十的瞭解到這個頁面是用來做什麼的？

（2）頁面由哪些功能組成？

系統功能由一個個頁面承載。每個頁面分擔完成功能中的若干個功能點，因此一個網頁就是由一個個的功能點組成的。當設計一個頁面的時候，就要構思好，這個頁面應包含的功能點應該有哪些？如“寫文章”這個頁面，大致應有：文字編輯、圖片插入、文章發布、文章歸類等幾個功能點。

（3）完成功能需要哪些操作？

完成每個功能點，使用者需要在系統上進行若干步操作。因此在設計一個功能的時候，應交代清楚使用者使用這個功能，需進行哪幾步操作？如完成“文字編輯”這個功能點，需要先點擊操作“寫文章”，再完成“書寫”，完成“插入圖片”，最後“儲存”。

（4）執行某個操作的條件是什嗎？

系統上的每個操作，需要滿足某些條件才可觸發。否則，系統功能無法形成體系，處於紊亂的狀態。如“當文章內容發生變化時”，才可做“儲存”的操作。

一個需求從提出到設計實現，應該遵循特定的生命週期，否則極易出現遺漏、混亂的情況，極其不利於項目的品質和整體把控。

特別應注意的一點是，不要聽到一個需求，內心就有一種莫名的衝動，想要馬上實現此需求。靜下來慢慢規劃，想清楚，才是最重要的。

 

 

來源：人人都是產品經理

產品需求分析步驟詳解？