不要接到一個任務，內心就有一種莫名的沖動，想要馬上完成。我們應該靜下來慢慢規(guī)劃，想清楚，才是最重要的。需求亦是如此。enjoy~

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

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

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

當需求方向你闡述完某個需求后，向她詢問：提這個需求的目的是什么？即為什么會產生這個需求？這個問題幫你完全理解需求，幫你辨別需求的真?zhèn)巍?/p>

2. 什么場景下會使用這個需求？

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

3. 是否有可能衍生出新的場景？

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

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

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

5. 是否可納入backlog？

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

?

backlog表頭及說明

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

當要開啟一個版本的規(guī)劃時，我們從backlog中挑出高優(yōu)先級的若干個需求，并細化需求、制定迭代計劃。

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

A. 版本功能列表說明

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

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

B. 業(yè)務流程說明

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

C. 設計頁面和交互

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

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

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

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

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

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

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

（4）執(zhí)行某個操作的條件是什么？

系統(tǒng)上的每個操作，需要滿足某些條件才可觸發(fā)。否則，系統(tǒng)功能無法形成體系，處于紊亂的狀態(tài)。如“當文章內容發(fā)生變化時”，才可做“保存”的操作。

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

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

本文由 @小麻雀?原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。