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

一、什么是PRD

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

二、PRD的價值

既然比較核心，那么PRD的價值自然是舉足輕重的。一個產(chǎn)品的開發(fā)周期一般會包含以下幾個環(huán)節(jié)：

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

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

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

1. PRD結(jié)構(gòu)及說明

PRD的結(jié)構(gòu)如下：

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

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

2. PRD核心構(gòu)成

1）修訂記錄

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

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

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

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

修訂記錄案例如下：

2）功能清單

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

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

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

對于功能清單，可以描述的內(nèi)容有：

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

功能清單案例如下：

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

3）流程圖

流程圖主要是兩種：業(yè)務(wù)流程圖 和 產(chǎn)品流程圖。兩種流程圖都至關(guān)重要，在我看來缺一不可！

① 業(yè)務(wù)流程圖

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

業(yè)務(wù)流程圖說清楚業(yè)務(wù)流是怎么樣的即可，案例如下：

② 產(chǎn)品流程圖

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

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

產(chǎn)品流程圖案例如下：

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

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

4）原型圖

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

5）邏輯說明

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

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

四、總結(jié)

最后，關(guān)于梳理PRD，有以下幾點總結(jié)：

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

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