PRD（產品需求文檔）在產品開發中起著至關重要的作用，某種意義上，它有著“承前啟后”的意義，承載著獲取的需求，并引導著下游的落地實現。那么，一份好用、接地氣的PRD，該怎么寫呢？一起來看看作者的總結。

一、什么是PRD

所謂的PRD，即產品需求文檔，英文是“Product Requirements Document”，是詳細描述產品架構、頁面、功能等全方位需求的輸出物。PRD在IT行業里是比較核心的產物，影響著產品產出效果。

二、PRD的價值

既然比較核心，那么PRD的價值自然是舉足輕重的。一個產品的開發周期一般會包含以下幾個環節：

從上圖可以看出，PRD承載了獲取的需求，又引導著下游的落地實現。也很容易理解：PRD好比一個說明書，告訴上下游部門這個東西落地后到底是個什么樣子。所以如果PRD失水準，研發出來的東西可能就會跟預期相差較大，影響業務的實際效果。

三、如何寫一份接地氣的PRD

一份接地氣的PRD應該是什么樣的呢？我以我的總結經驗跟大家分享下，對新手同學會比較受用。

1. PRD結構及說明

PRD的結構如下：

1. 修訂記錄：記錄每次PRD更新的內容。
2. 需求價值：主要是需求場景和為什么做這個需求、產品或者項目（下統稱“需求”），可以讓下游人員更好的理解需求和需求的合理性。
3. 功能清單：描述下這個需求有哪些功能，對這些功能稍微詳細描述下。
4. 流程圖：分為業務流程圖和產品流程圖。
5. 名詞解釋：對文檔內某些個性化的名次進行解釋說明。
6. 通用組件說明：對于不同的交互、場景所用到的，但是通用型的頁面組件進行描述說明，比如toast。
7. 原型圖說明：繪制下原型圖，然后對原型圖和細節進行描述說明。
8. 邏輯說明：對需求的產品邏輯進行詳細描述說明。
9. 其他：其他必要的內容。

每個人對PRD結構認知可能都不一樣，對于我來說，我更看重 修訂記錄、功能清單、流程圖、原型圖說明、邏輯說明，這也是我認為的PRD核心構成。

2. PRD核心構成

1）修訂記錄

修訂記錄記錄里PRD的更新過程，誰也不敢保證PRD經過評審之后沒有任何的改動。那么只要更新了，就在修訂記錄里把更新的內容標注進去，方便周知、查閱。

修訂記錄主要包含四個信息：

• 修訂版本：我們要給每次修訂記錄定一個版本號（我個人也會把版本號放到PRD的文檔名稱中，這個看個人習慣了），可以采用“V1.0”、“V1.1”這種方式來定義。一般大的更新，小數點前面的數字+1；小的更新，小數點后面的數字+1。
• 修訂人：當前更新的這個版本PRD是誰寫的，就寫誰的名字。
• 修訂日期：當前這個版本PRD更新完成的日期。
• 修訂內容：修訂內容分為三種類型：更新、新增、刪除。在寫更新內容的時候可以寫：更新了xxxxx，新增了xxxxx，刪除了xxxxx，三種類型區分開來寫，方便閱讀理解。

修訂記錄案例如下：

2）功能清單

在功能清單里，要把需求設計到的主要功能陳述下，這里對產品經理的體系化思考能力會有些要求。簡單來說，就是要把需求的方方面面都想清楚了，想全乎了！本質上是要求產品經理對這個需求背后的業務邏輯要熟悉和理解。

在梳理功能清單過程中，可以先從這個需求最核心的功能入手，思考核心的功能有哪些；思考完了后，再繼續對核心功能進行拆分，即為了支撐這個核心功能，需要有哪些子功能…

那么需要一層層把功能點或需求點拆分到什么顆粒度呢？這里我個人認為沒什么特殊的要求，只要你認為能讓受閱者理解需求的大體要做什么即可。

對于功能清單，可以描述的內容有：

• 端口：是app還是后臺web？
• 模塊：是登錄還是交易？
• 功能點：即模塊下的功能點，有多少寫多少。
• 功能描述：每個功能點的大致描述。
• 涉及頁面：這個功能會涉及到的頁面。
• 字段：有哪些比較重要的字段。
• 備注：有什么需要補充的，就描述下。

功能清單案例如下：

功能清單還是比較考驗產品經理思維和需求分析能力的，一定要多思考?？赡苡腥藭幸蓡?，功能清單是分析的過程，為什么要寫在PRD里？要知道，功能清單不僅幫助我們整理思路，還可以讓受閱者更快速理解需求，提高評審效率和質量。

3）流程圖

流程圖主要是兩種：業務流程圖 和 產品流程圖。兩種流程圖都至關重要，在我看來缺一不可！

① 業務流程圖

所謂業務流程圖，描述的是對應的業務流轉途徑是怎么樣的，反應的是需求背后的業務邏輯。所以產品經理必須要熟知業務，否則做出來的東西很可能是存在偏差的。為什么要畫業務流程圖，一是驗證產品經理對需求的理解程度，二是讓下游部門快速理解需求。

業務流程圖說清楚業務流是怎么樣的即可，案例如下：

② 產品流程圖

產品流程圖大家應該都比較熟悉了，描述的是在使用這個產品或功能時，用戶行為或數據等流轉路徑，反應的是產品邏輯！這里面可能就會包含各種各樣的產品邏輯，其中比較重要的邏輯一定要體現在流程圖中，方便研發、測試快速理解需求。

但通常情況下，一個流程圖完全不足以描述清楚所有產品邏輯，所以產品經理至少要把核心主流程繪制出來，其他認為比較重要的也可以單獨繪制，或者在邏輯梳理部分繪制。

產品流程圖案例如下：

在流程圖中，不同的流程組件建議標上注釋，方便閱讀理解。

需要注意的是，功能清單和流程圖都是受閱者在閱覽詳細需求前對需求進行快速整體認知的手段，是非常重要的。當研發、測試通過功能清單和流程圖理解需求后，可能會聯想到之前做過類似的需求，其中的問題和坑可能也會聯想起來，那么在評審的時候可能就會提問相關的細節問題。整體來看會提高評審的質量（當然也并不是所有研發測試都是這樣，這里不一概而論，但還是建議要梳理出來功能清單和流程圖）。

4）原型圖

原型圖也叫線框圖，可能是每個產品經理第一個接觸到并熟練應用的技能，甚至有的產品經理還很熱衷于畫原型。原型圖很重要，但我真的建議不要耗費太多精力在畫原型甚至交互上面，能把的原型畫出來就好，沒必要糾結是否對齊啊，顏色好不好看，交互事情是否ok啊什么的，除非公司有硬性要求（這種公司建議招個交互設計師）。

5）邏輯說明

邏輯說明是整個PRD的重中之重，要投入精力來思考來撰寫。整個需求下來會有各種各種的邏輯，比如行為交互邏輯、數據交互邏輯、數據取數邏輯等等，邏輯一旦錯誤，那么交付的產品極大概率是有問題的。清楚地描述邏輯可以采用純文字方式（閱讀體驗感不好），也可以采用頁面流程圖、產品流程圖、表格、文字、圖片等多種混合方式?？傊?，目的只有一個，把邏輯梳理清楚！

一個PRD包含上述5個核心構成基本就差不多了。當然，也并不是所有PRD都要有上述構成，比如報表需求。如果在PRD里加入其他能說明問題的內容當然也是ok的，主要還是看受眾、公司想要看什么。

四、總結

最后，關于梳理PRD，有以下幾點總結：

1. 理解業務是梳理PRD的前提。
2. PRD的核心是梳理產品邏輯，畫原型幾乎是個體力活。
3. PRD也是個產品，所以也要考慮你的受眾、體驗、效果，必要時可量化你的PRD效果，不斷總結、提高自己。
4. 寫PRD的工具沒有什么限制，word、ppt、excel、axure、協作文檔等都可以，我個人比較習慣用axure。
5. 還是要根據公司對PRD的要求來寫，如果沒有要求的話，只要能把需求說清楚，就放飛自我吧。

希望對大家有所幫助，歡迎交流～