一份優(yōu)秀的PRD能夠幫助你獲取資源，有效推進(jìn)項(xiàng)目，獲得團(tuán)隊(duì)成員的信任。

今天就和大家聊聊如何寫好一篇PRD，希望能夠提供給大家一些干貨。

一、PRD的用戶是誰？

首先，與大家先分享一句話：把需求文檔當(dāng)成一個(gè)“互聯(lián)網(wǎng)產(chǎn)品”去管理，理解它的用戶，關(guān)注它的體驗(yàn)，不停迭代，使其價(jià)值最大化。（引用）

既然把它視為一個(gè)互聯(lián)網(wǎng)產(chǎn)品，那我們需要思考PRD的用戶是誰，他們通過PRD要了解什么內(nèi)容？

根據(jù)用戶以及他們的訴求。

我把PRD分成幾個(gè)階段：

1）MRD階段

這個(gè)時(shí)候，主要需要說服我們的老板、或者團(tuán)隊(duì)內(nèi)部評(píng)審，也會(huì)有需求方，讓大家認(rèn)同你的方案，知道你要做什么怎么做。

所以這個(gè)時(shí)候類似于MRD，把整個(gè)方案路線說清楚就可以，做一個(gè)較粗線條的DEMO圖。

切勿做細(xì)化的設(shè)計(jì)稿，更不要寫詳細(xì)的功能說明，因?yàn)檫@時(shí)候被拍的可能性很大。

2）PRD V1.0

如果通過了第一步評(píng)審，這時(shí)可以做細(xì)化的內(nèi)容，做一個(gè)相對(duì)細(xì)化的DEMO圖，這一步面向開發(fā)、交互，開發(fā)進(jìn)行技術(shù)上的評(píng)估。

交互是下一步真正要做事兒的人，會(huì)關(guān)注一些頁面的細(xì)節(jié)，所以這個(gè)時(shí)候可以做詳細(xì)的DEMO圖，并在DEMO圖右側(cè)配以一些說明，方便交互及UI進(jìn)行工作。

不要寫詳細(xì)的界面操作說明，不過可以在進(jìn)行界面設(shè)計(jì)期間，先寫一些業(yè)務(wù)邏輯相關(guān)的內(nèi)容。

3）PRD V2.0

這個(gè)就是全版了，這么細(xì)化的內(nèi)容，只有真正做這塊功能的開發(fā)同學(xué)才會(huì)細(xì)看，寫細(xì)寫全沒得說了。

了解了不同用戶的訴求，那我們就具體說下PRD編寫的內(nèi)容吧。

二、圍繞用戶體驗(yàn)要素的PRD編寫

為什么要說圍繞用戶體驗(yàn)要素來編寫PRD，因?yàn)楫a(chǎn)品的設(shè)計(jì)是圍繞著這個(gè)經(jīng)典的框架來的，那寫PRD的任務(wù)當(dāng)然是要把這個(gè)內(nèi)容向大家表述清楚。

用戶體驗(yàn)要素

下面就具體說下PRD如何圍繞這個(gè)內(nèi)容編寫。

第一部分：需求概述

其實(shí)不僅僅是做產(chǎn)品，任何事情，第一步肯定是要想清楚要做什么，為什么要做，也就是把戰(zhàn)略層描述清楚，PRD的第一部分就是要把這塊內(nèi)容說清楚，回答出下面的問題。

1）用戶要獲得什么？—— 用戶痛點(diǎn)、需求

建議這塊內(nèi)容，說清楚整體的問題痛點(diǎn)，同時(shí)也要舉具體case，列舉數(shù)字，如用戶的使用頻次，現(xiàn)在的花費(fèi)等等。

2）用戶是誰？—— 用戶細(xì)分、用戶數(shù)量、畫像

用戶是誰，并不是如“商家用戶”這種粗線條的描述，要說清楚對(duì)于當(dāng)前的功能，是哪類用戶在什么場(chǎng)景下的需求，用戶的量級(jí)是怎樣的，有一個(gè)相對(duì)具體的畫像。

3）用戶能通過這個(gè)得到什么？ —— 用戶收益

這里面補(bǔ)充個(gè)內(nèi)容，俞軍老師曾說過，用戶凈收益=新體驗(yàn)-舊體驗(yàn)-替換成本，替換成本可能是獲取成本、認(rèn)知成本、資金等等， 雖然這些內(nèi)容并不是真正可衡量的，但在做一款新產(chǎn)品評(píng)估其價(jià)值時(shí)，可以從這幾個(gè)角度進(jìn)行思考。

4）我們能得到什么？—— 對(duì)企業(yè)能帶來什么收益

這點(diǎn)很重要，做任何產(chǎn)品，給用戶賦能，給用戶帶來價(jià)值，其主要目的還是企業(yè)自身能夠盈利，這點(diǎn)想清楚才能說服老板提供資源呀。

第二部分：產(chǎn)品規(guī)劃

最抽象的戰(zhàn)略層說清楚了，下一步就要大體說下為了實(shí)現(xiàn)上面列舉的各種想法目標(biāo)，要一步一步怎么做了，也就是說清范圍層的內(nèi)容。

1）功能&信息結(jié)構(gòu)圖

范圍層，就是要說清楚，為了實(shí)現(xiàn)戰(zhàn)略做什么事情，什么功能，提供什么內(nèi)容。這塊一般會(huì)通過腦圖或者框架圖來展現(xiàn)，說清楚我們需要哪些數(shù)據(jù)，做哪些功能，各個(gè)功能與功能之間的關(guān)系。

要注意，這部分需要在長(zhǎng)遠(yuǎn)角度，解決這個(gè)問題地整條路線進(jìn)行思考。舉個(gè)例子吧，比如要做個(gè)評(píng)論功能，讓用戶對(duì)產(chǎn)品更了解，并帶來更多銷量。那第一步先增加評(píng)論功能，之后可以對(duì)評(píng)論進(jìn)行分析，為用戶推薦高質(zhì)量的產(chǎn)品，發(fā)現(xiàn)問題產(chǎn)品保證平臺(tái)產(chǎn)品質(zhì)量等等。類似這樣，出一個(gè)整體的規(guī)劃藍(lán)圖。

2）路線規(guī)劃

藍(lán)圖出來了，還是要落地的。所以這一步要把剛才地藍(lán)圖，切成一塊一塊，每一步要做什么，多長(zhǎng)時(shí)間，這個(gè)階段解決怎么的問題，為后面提供什么鋪墊。有些內(nèi)容，也可以出一個(gè)簡(jiǎn)易的DEMO圖，能描述清楚即可。

第三部分：功能概述

這一部分是對(duì)當(dāng)前這一期要做的內(nèi)容的詳細(xì)描述了。這部分面向的主要用戶是UI、交互、開發(fā)、測(cè)試同學(xué)，具體到做事情上，就是把大家的認(rèn)知拉齊。

1）產(chǎn)品流程圖

通過圖的方式，可以快速、方便地告知PRD的每個(gè)用戶這個(gè)功能的思路流程。這里最開始放的是比較粗線條的流程圖，比如買家購(gòu)買商品，加入購(gòu)物車->付款->商家發(fā)貨->確認(rèn)收貨。而一些細(xì)節(jié)，比如買家超時(shí)未付款，或者賣家修改價(jià)錢等等，可以到具體寫到這個(gè)功能點(diǎn)地時(shí)候再出一個(gè)細(xì)化的流程圖。

2）DEMO，原型制作，這個(gè)就不用多說。

3）UI稿，這塊是UI同學(xué)完成后，放上來，統(tǒng)一相關(guān)資料的獲取入口。

4）產(chǎn)品功能點(diǎn)，后面來細(xì)說。

補(bǔ)充兩塊，流程圖和產(chǎn)品功能點(diǎn)：

產(chǎn)品流程圖——UML（統(tǒng)一建模語言）

Unified Modeling Language (UML)又稱統(tǒng)一建模語言，為軟件開發(fā)的所有階段提供模型化和可視化支持，簡(jiǎn)而言之，就是用圖的方式把事情描述清楚。在這里有兩個(gè)概念，類和對(duì)象。類是把一類事物的抽象，而對(duì)象是類的實(shí)例。比如汽車是一個(gè)類，某輛車就是個(gè)對(duì)象了。對(duì)于產(chǎn)品經(jīng)理，這兩個(gè)詞其實(shí)含義基本等同了。

下面我以員工提交權(quán)限審批這件事為例，對(duì)應(yīng)地類（或者說是對(duì)象）有員工、老板、還是審批單，給大家主要介紹4個(gè)圖。

1）活動(dòng)圖

我們也經(jīng)常叫流程圖，就是要描述清楚各個(gè)角色之間的工作流程。

矩形框內(nèi)描述當(dāng)前活動(dòng)，菱形塊列出分叉路線。如果有多個(gè)角色，如下面的例子，則將每個(gè)角色出一個(gè)泳道，對(duì)應(yīng)哪個(gè)角色的活動(dòng)即放到哪個(gè)泳道下。

2）序列圖

這個(gè)圖是各個(gè)對(duì)象之間的一個(gè)描述，與活動(dòng)圖略有相似，可以看下面的例子，我們?cè)谌粘９ぷ髦?，選取其中某一個(gè)把事情說清楚就OK了。

這里每個(gè)對(duì)象會(huì)有一個(gè)生命線，我把系統(tǒng)本身單出來，做了一條生命線，員工、老板在進(jìn)行某些操作后，需要系統(tǒng)這面進(jìn)行保存或者修改狀態(tài)，那右側(cè)即對(duì)應(yīng)與數(shù)據(jù)庫(kù)的交互，后端同學(xué)根據(jù)這個(gè)，大體就了解自己在什么時(shí)候要做什么事情了。

3）狀態(tài)圖

狀態(tài)圖的樣式，雖說和活動(dòng)圖樣式差不多，但其實(shí)內(nèi)容差別還挺大的，狀態(tài)圖是對(duì)一個(gè)對(duì)象的不同狀態(tài)切換進(jìn)行描述。比如權(quán)限審批這個(gè)事情，審批單有“審批中”、“未批準(zhǔn)”、“批準(zhǔn)”這3種狀態(tài)，通過這個(gè)圖可以很清晰地了解各個(gè)狀態(tài)的轉(zhuǎn)換方式。

4）類圖

描述類的內(nèi)部結(jié)構(gòu)和類之間的關(guān)系，這個(gè)用得不多，可以簡(jiǎn)單了解下。

還是這個(gè)功能，我們有員工、審批單、老板這3個(gè)類，他們有些屬性，對(duì)于員工和老板還有一些操作，可以通過這個(gè)類圖來表述出來。其中有個(gè)+-號(hào)，+號(hào)是public，即其他類可見，-號(hào)是private，其他類不可見。比如員工的姓名，其他類無法獲知，但可以通過一些對(duì)象操作獲得。這個(gè)就有些偏開發(fā)的內(nèi)容了，不是特殊需要開發(fā)同學(xué)知道信息，可以不對(duì)這塊進(jìn)行標(biāo)注。

產(chǎn)品功能細(xì)化說明

這塊就是要把功能說得足夠細(xì)，但也是有一些技巧。

1）更新說明

首先，我一般會(huì)在功能最上方，列出更新的清單，一般記錄有：調(diào)整時(shí)間、調(diào)整功能塊、詳細(xì)說明。

2）全局說明

每期功能可能會(huì)有多個(gè)頁面多個(gè)功能塊，但有一些想通的地方，比如對(duì)于數(shù)據(jù)產(chǎn)品，數(shù)字的展現(xiàn)形式，保留2位小數(shù)，增加三分位符號(hào)等；對(duì)于移動(dòng)端產(chǎn)品，一些操作方式等。這個(gè)適用于各個(gè)塊，不用分別在每個(gè)中單獨(dú)說明，而且后續(xù)做其他功能都是可以復(fù)用的，可以先列出來說清楚。

3）具體每個(gè)塊的功能說明

• 前置條件：有些功能可能會(huì)有這個(gè)內(nèi)容，在什么情況觸發(fā)這個(gè)功能，比如在用戶購(gòu)買什么商品后提供某個(gè)功能；
• 主體功能說明
• 流程描述：主流程、分支流程，這個(gè)就可以使用上面介紹的UML圖，把主線條描述清楚；
• 界面描述：操作、文案，文案建議其他顏色標(biāo)注出來，防止和描述弄混；
• 業(yè)務(wù)規(guī)則：這個(gè)是在界面看不到的，比如限制條件、表格的排序規(guī)則、需要記錄的數(shù)據(jù)、還有一些數(shù)字的計(jì)算公式等等；
• 異常描述：這個(gè)不能忽略，尤其是C端產(chǎn)品，考慮需要更為全面，因?yàn)楹芸赡芫褪且粋€(gè)小異常，就導(dǎo)致用戶使用不爽而流失，比如上傳文件沒有考慮超出大小怎么辦，用戶上傳后一直沒反應(yīng)，就會(huì)認(rèn)為這個(gè)產(chǎn)品不好用，轉(zhuǎn)而使用其他產(chǎn)品，所以，異常地考慮很重要。列幾個(gè)常見的異常：如未輸入、輸入錯(cuò)誤、無數(shù)據(jù)，無網(wǎng)絡(luò)，長(zhǎng)時(shí)間未操作，異常退出等等。

最后說下寫這塊內(nèi)容的原則

• 完整：足夠細(xì)，考慮足夠周全；
• 無歧義：RD同學(xué)是拿著這個(gè)文檔真真切切寫代碼，所以說得內(nèi)容，要能夠落到代碼上，比如用戶一段時(shí)間未操作則提示。。。，等待多長(zhǎng)時(shí)間，要寫清楚；
• 有條理：這文檔是有人看的，所以序號(hào)、符號(hào)都適當(dāng)?shù)挠蒙?，讓你的文檔容易閱讀；
• 及時(shí)更新：功能、DEMO的調(diào)整，都需要落到PRD上。

第四部分：數(shù)據(jù)需求

因?yàn)槲冶救耸菙?shù)據(jù)產(chǎn)品的產(chǎn)品經(jīng)理，所以這一部分對(duì)于我們很重要，需要哪些維度、哪些指標(biāo)，指標(biāo)的來源庫(kù)表字段、計(jì)算口徑是什么，這些都要清晰地記錄下來。

除此之后，有個(gè)內(nèi)容可能經(jīng)常會(huì)被忽略，就是數(shù)據(jù)的整理。以某寶的搜索結(jié)果頁為例，一般會(huì)展示圖片、標(biāo)題、價(jià)格、銷量、賣家名稱、包郵會(huì)標(biāo)記出來，這些RD通過UI稿可能會(huì)查看到，但有一些比如鼠標(biāo)移入顯示信息，點(diǎn)擊操作、是否購(gòu)買過，都在商品展示時(shí)體現(xiàn)出來。

這些內(nèi)容，我們可不能指望RD同學(xué)從UI稿中一點(diǎn)點(diǎn)發(fā)現(xiàn)。所以列出這樣的表格，把你認(rèn)為需要的類及其屬性列清楚，有點(diǎn)類似我們上面類圖中對(duì)象屬性要描述的內(nèi)容，目的是讓開發(fā)同學(xué)對(duì)照這個(gè)來進(jìn)行庫(kù)表設(shè)計(jì)，不要遺漏某些點(diǎn)。

第五部分：數(shù)據(jù)埋點(diǎn)

包括按鈕的埋點(diǎn)&內(nèi)容的埋點(diǎn)，可以通過截圖+表格說明的方式，截圖標(biāo)明需要埋點(diǎn)哪些控件，表格說明對(duì)應(yīng)控件的什么信息，如操作PV、UV、輸入內(nèi)容等。

第六部分：效果評(píng)估方案及上線安排

對(duì)于C端產(chǎn)品，這塊內(nèi)容會(huì)更加重要，一般會(huì)有個(gè)灰度發(fā)布過程，因此需要說清楚灰度發(fā)布的方式，放量安排、節(jié)奏，需要關(guān)注的指標(biāo)，這個(gè)指標(biāo)如何進(jìn)行評(píng)估，達(dá)到什么樣程度可以全部上線。

第七部分：人員排期

OK，大功告成了。

三、PRD的承載

最后說一點(diǎn)：PRD的存放。

我嘗試過幾種方式，之前就在axure中完成，在DEMO的右側(cè)進(jìn)行說明，但這個(gè)不好的是：在進(jìn)行更新后，還要發(fā)送給大家，各個(gè)版本的存放加上axure本身下載解壓就比較麻煩，所以并不是最佳方案。

我現(xiàn)在一般是用wiki來完成，只要一個(gè)鏈接，更新后只要告知大家同步下信息就好，就是在寫功能時(shí)候，需要把DEMO對(duì)應(yīng)圖貼上去，RD能夠比較方便知道是對(duì)哪塊內(nèi)容的描述。

對(duì)于上述內(nèi)容，我一般分成2個(gè)wiki頁記錄，一個(gè)記錄需求概述和產(chǎn)品規(guī)劃部分內(nèi)容；一個(gè)記錄產(chǎn)品功能及之后的內(nèi)容，這個(gè)是當(dāng)前這期的事情。一個(gè)總分的結(jié)構(gòu)。

以上是我個(gè)人寫PRD的一些經(jīng)驗(yàn)總結(jié)，希望對(duì)大家有幫助。不過，這個(gè)PRD的編寫并不適于所有公司，一份完善的PRD需要花費(fèi)比較多的時(shí)間，對(duì)大公司來說，對(duì)接方比較多，很有必要這樣一份文檔統(tǒng)一各方的認(rèn)知；而對(duì)于創(chuàng)業(yè)公司，將產(chǎn)品快速落地投放市場(chǎng)進(jìn)行驗(yàn)證更為重要，所以這個(gè)時(shí)候千萬不要把時(shí)間花費(fèi)到PRD上面。

本文由 @高楊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議