編輯導(dǎo)語：作為一個(gè)產(chǎn)品經(jīng)理，PRD文檔是必須要掌握的，PRD文檔是產(chǎn)品需求文檔，是可以將概念化的需求轉(zhuǎn)變?yōu)閳D紙化的文檔，做項(xiàng)目時(shí)起到輔助作用。本文作者分享了關(guān)于PRD文檔5W2H的詳細(xì)分析，我們一起來看一下。

經(jīng)常會(huì)有剛?cè)胄械漠a(chǎn)品小伙伴們問：“PRD文檔應(yīng)該怎么寫？要寫什么內(nèi)容？要細(xì)致到什么程度？用什么寫呀？”

這個(gè)問題我們可以根據(jù)5W2H分析法來進(jìn)行一一拆解。（以下內(nèi)容都是根據(jù)筆者自己做過的項(xiàng)目總結(jié)，適用于筆者本人合作的團(tuán)隊(duì)；實(shí)際的文檔內(nèi)容以及產(chǎn)出形式，只要自己的團(tuán)隊(duì)能接受都OK的。）

一、What | 什么是PRD

PRD（Product Requirements Document），產(chǎn)品需求文檔，是產(chǎn)品經(jīng)理硬實(shí)力的表現(xiàn)形式之一。

“是將商業(yè)需求文檔（BRD）和市場(chǎng)需求文檔（MRD）用更加專業(yè)的語言進(jìn)行描述”——百度詞條

簡(jiǎn)而言之，就是將天馬行空的概念具象化為實(shí)際的業(yè)務(wù)邏輯、UI頁面、菜單按鈕、字段定義、數(shù)據(jù)結(jié)果，最終輔導(dǎo)開發(fā)人員將系統(tǒng)研發(fā)出來，落地開花。

二、Why | 為什么需要PRD文檔

PRD文檔是產(chǎn)品項(xiàng)目由“概念化”進(jìn)入“圖紙化”的最主要的文檔，編寫主要有幾個(gè)目的：

• 概念具象化：產(chǎn)品人員搜集了各方的需求進(jìn)行去偽存真的處理之后，需要對(duì)單個(gè)的需求點(diǎn)整合 –> 抽象 –> 具象，輸出為黑字白紙的落地文檔；并且的文檔的編寫過程中，可以從全局的角度和細(xì)節(jié)中去驗(yàn)證邏輯是否正確；
• 協(xié)助項(xiàng)目開發(fā)：從項(xiàng)目立項(xiàng)開始、到項(xiàng)目評(píng)審、項(xiàng)目開發(fā)、項(xiàng)目驗(yàn)收，PRD文檔貫穿了整個(gè)產(chǎn)品的誕生過程，重要性可想而知；
• 產(chǎn)品定版證據(jù)：產(chǎn)品文檔編寫完畢之后就要進(jìn)行封版處理，不能在開發(fā)過程中頻繁變動(dòng)需求，否則交付會(huì)無限延期；
• 記錄產(chǎn)品演進(jìn)藍(lán)圖：若研發(fā)過程中需求有變動(dòng)會(huì)首先排查文檔的定版內(nèi)容，對(duì)變動(dòng)需求單獨(dú)進(jìn)行處理；若為版本迭代，也可以根據(jù)以前的版本記錄進(jìn)行追蹤查源；
• 預(yù)防人員變動(dòng)：若公司的人員流動(dòng)性比較強(qiáng)，文檔保存不當(dāng)，會(huì)導(dǎo)致產(chǎn)品的持續(xù)性研發(fā)迭代變得異常困難。

三、When | 什么時(shí)候需要PRD文檔

需要使用文檔的時(shí)機(jī)和文檔的適用對(duì)象是緊密相連的，下文一并詳細(xì)說明。

四、Who | 誰會(huì)閱讀PRD文檔

1. 公司領(lǐng)導(dǎo)——調(diào)研結(jié)束后、項(xiàng)目評(píng)審前

在經(jīng)過一系列的公司戰(zhàn)略會(huì)議、市場(chǎng)調(diào)研、競(jìng)品分析研究之后，產(chǎn)品就要進(jìn)入到實(shí)際的設(shè)計(jì)階段；公司領(lǐng)導(dǎo)或者產(chǎn)品直屬領(lǐng)導(dǎo)會(huì)查看部分PRD文檔，以確保需求沒有偏離軌道。

2. 設(shè)計(jì)師、研發(fā)人員——項(xiàng)目評(píng)審前后、研發(fā)過程中

項(xiàng)目評(píng)審前一般會(huì)提前下發(fā)PRD文檔，預(yù)留一些時(shí)間讓研發(fā)人員熟悉將要做的業(yè)務(wù)和內(nèi)容；以免在評(píng)審時(shí)不清楚具體需求是什么，也無法提出相應(yīng)的意見，結(jié)果在開發(fā)過程中不斷問產(chǎn)品經(jīng)理的情況。

3. 測(cè)試人員——研發(fā)過程中、測(cè)試中

項(xiàng)目研發(fā)過程較長(zhǎng)，一般會(huì)讓測(cè)試人員提前介入測(cè)試，而非等開發(fā)完結(jié)后再統(tǒng)一測(cè)試，此舉也是為了避免項(xiàng)目研發(fā)出現(xiàn)偏差，或者測(cè)試后預(yù)留的修復(fù)bug時(shí)間不足。

如果要做足功課的話，測(cè)試人員基本要與研發(fā)人員同時(shí)熟悉PRD文檔，以免測(cè)試工作脫離了實(shí)際的業(yè)務(wù)場(chǎng)景。

4. 運(yùn)營(yíng)人員——測(cè)試中、上線后

有些業(yè)務(wù)部門可能會(huì)提前參與到項(xiàng)目驗(yàn)收中，需要熟悉產(chǎn)品的關(guān)鍵業(yè)務(wù)流程。

功能性比較復(fù)雜的產(chǎn)品，有些公司是會(huì)專門設(shè)置職位為一線的市場(chǎng)、銷售人員進(jìn)行使用培訓(xùn)。

5. 產(chǎn)品的接任者

如字面意思，產(chǎn)品的接任者。

五、Where | 在哪里閱讀PRD

這個(gè)應(yīng)該沒什么好說的，考慮PRD文檔的使用對(duì)象，一般就是在PC端閱讀吧，無需考慮閱讀的硬件適配啥的。

如果有人非要用手機(jī)閱讀，那只能眼睛受累了。

六、How | 如何編寫PRD文檔

寫了那么多，終于要到重點(diǎn)部分了。

曾聽過來自技術(shù)的一句話“一份好的PRD文檔，開發(fā)看見之后應(yīng)該是能行云流水的寫代碼，如果寫兩下就卡殼，那肯定是文檔質(zhì)量或業(yè)務(wù)邏輯出了問題?！?/p>

那一份好的PRD文檔，應(yīng)該包括哪些內(nèi)容呢？

1. 目錄或者導(dǎo)航索引

方便使用人員快速找到所需的文檔信息，個(gè)人認(rèn)為建立層級(jí)分明的側(cè)邊欄索引比文檔目錄要使用便捷度高一些。

2. 關(guān)于文檔

內(nèi)容說明：基本沒人看的廢話。

適用對(duì)象：如上文所寫；主要是為了強(qiáng)調(diào)文檔是公司內(nèi)部保密資產(chǎn)，不可對(duì)外流出。

術(shù)語詞匯：很重要，對(duì)于新的系統(tǒng)出現(xiàn)的業(yè)務(wù)用詞或者行業(yè)內(nèi)的專有名詞，需要詳細(xì)說明。

（專有名詞說明）

3. 系統(tǒng)概述

功能模塊清單：列明系統(tǒng)版本所包含的子模塊、列表清單、菜單、備注、功能的需求等級(jí)；方便產(chǎn)品經(jīng)理清晰梳理系統(tǒng)覆蓋的業(yè)務(wù)內(nèi)容。

系統(tǒng)用戶角色說明

說明系統(tǒng)設(shè)計(jì)的所有用戶角色，對(duì)應(yīng)角色的職能。

數(shù)據(jù)權(quán)限、角色權(quán)限清單：

復(fù)雜的系統(tǒng)需要區(qū)別用戶角色、提供專門的權(quán)限清單，方便開發(fā)人員提前做好數(shù)據(jù)隔離、功能權(quán)限隔離；

4. 版本規(guī)劃

版本規(guī)劃藍(lán)圖，又稱產(chǎn)品roadtrip。

在產(chǎn)品的前期調(diào)研中，會(huì)盡量全面的考慮產(chǎn)品的完整生命周期應(yīng)該如何發(fā)展；但是研發(fā)資源是緊缺的，而且市場(chǎng)是需要經(jīng)過驗(yàn)證的，時(shí)間也不等人，所以B端也會(huì)存在MVP的概念。

所以大型的產(chǎn)品一般會(huì)規(guī)劃分期實(shí)現(xiàn)，需要注意的是——每一期的產(chǎn)品規(guī)劃必須是一個(gè)完整的業(yè)務(wù)閉環(huán)，否則項(xiàng)目上線了會(huì)面了無法使用的尷尬局面。

本期需要實(shí)現(xiàn)的功能要和開發(fā)人員詳細(xì)溝通，如需預(yù)留接口的地方要做到心中有數(shù)。

例如：產(chǎn)品規(guī)劃要做多種支付通道，但是本期只做一種支付通道，那么支付通道的類型選擇，需要提前定義為便于拓展的字典，而非寫死的字段。

（某產(chǎn)品的三期規(guī)劃藍(lán)圖）

5. 框架圖、流程圖

組織架構(gòu)圖、信息框架圖：目前市面上對(duì)組織架構(gòu)圖和信息框架圖也沒有特別嚴(yán)格清晰的定義，主要是為了講解產(chǎn)品的整體框架是如何搭建的，具體框架包含的模塊，模塊所附帶的功能等；能將事情講清楚就行，不用過于在意架構(gòu)圖中是否需要詳細(xì)列明每個(gè)模塊下的細(xì)分功能點(diǎn)。

（某TMS系統(tǒng)單獨(dú)模塊的組織架構(gòu)圖）

業(yè)務(wù)流程圖：核心的業(yè)務(wù)流程圖顆粒度比較粗，講述關(guān)鍵節(jié)點(diǎn)的操作和數(shù)據(jù)流轉(zhuǎn)，以及關(guān)鍵環(huán)節(jié)的參與對(duì)象。

（某TMS系統(tǒng)核心業(yè)務(wù)流程圖）

核心業(yè)務(wù)流程定下來后，可以對(duì)業(yè)務(wù)流程進(jìn)行細(xì)化；顆粒度最細(xì)的是具有邏輯判斷、異常流描述的流程圖。

本人的習(xí)慣是在進(jìn)行具體的功能文字描述時(shí)，比較復(fù)雜的業(yè)務(wù)流程會(huì)配備流程圖，圖形比文字更容易理解。

（細(xì)化流程：常見的注冊(cè)流程圖）

6. 功能需求描述

功能需求的描述，需要覆蓋以下內(nèi)容：

• 功能描述：1-3句話概括功能要點(diǎn)，建立開發(fā)對(duì)功能大致了解；
• 業(yè)務(wù)場(chǎng)景描述：比較不容易理解的業(yè)務(wù)流程，可以描述實(shí)際業(yè)務(wù)場(chǎng)景，或者在評(píng)審環(huán)節(jié)，多詳細(xì)講解業(yè)務(wù)發(fā)生的線下場(chǎng)景，需要解決的用戶痛點(diǎn)，便于開發(fā)建立對(duì)業(yè)務(wù)更全面的認(rèn)知，產(chǎn)生共鳴；
• 前置條件：動(dòng)作發(fā)生的限制條件；例如操作該功能應(yīng)該具備的權(quán)限；例如司機(jī)接單的前置條件是已經(jīng)完成實(shí)名認(rèn)證等；
• 后置條件：動(dòng)作發(fā)生后引起的結(jié)果；例如指派訂單動(dòng)作后，系統(tǒng)會(huì)更新一條訂單記錄，同時(shí)司機(jī)收到待運(yùn)訂單消息；
• 異常情況：動(dòng)作后可能存在的異常情況；；例如指派訂單后，需要對(duì)訂單進(jìn)行取消或者撤回處理（根據(jù)個(gè)人的項(xiàng)目經(jīng)驗(yàn)，異常情況的考慮在業(yè)務(wù)描述中基本占比能到30%-50%，甚至可能更高，異常比較考驗(yàn)產(chǎn)品人員對(duì)業(yè)務(wù)的熟悉情況、逆向思考的邏輯能力以及邏輯的縝密性）；
• 排序方式：數(shù)據(jù)產(chǎn)生后，以什么條件進(jìn)行排序；時(shí)間順序、逆序；數(shù)值正序、倒序等；
• 交互規(guī)則：可以附帶小卡片式頁面跳轉(zhuǎn)邏輯、彈窗展示描述等；
• 計(jì)算規(guī)則：有計(jì)算值的，給出計(jì)算公式；計(jì)算過程比較復(fù)雜的，最好是可以提供一份測(cè)算表格，方便開發(fā)人員比對(duì)實(shí)現(xiàn)的效果是否正確；
• 字段說明：對(duì)字段的類型、長(zhǎng)度、默認(rèn)值、計(jì)算規(guī)則等進(jìn)行說明；之前寫過一篇《增刪改查顯算傳，7字箴言搭建B端底層框架》的文章，對(duì)字段進(jìn)行過詳細(xì)講解，大家有興趣可以看一下；
• 核心字典狀態(tài)定義：清晰描述字典值變動(dòng)的條件和業(yè)務(wù)狀況，字典之間的切換不要有冗余狀態(tài)或者瞬時(shí)狀態(tài)；例如支付業(yè)務(wù)中，常見的字典有：待支付、支付成功、支付失??；若是瞬時(shí)到賬的支付方式，此處加入已凍結(jié)狀態(tài)，就屬于字典冗余；需要預(yù)留接口的字典，暫時(shí)用不上的，需要對(duì)字典禁用，以免開發(fā)不清楚情況使用了錯(cuò)誤的字典值。

（核心字典狀態(tài)定義）

（功能需求描述）

（字段說明）

7. 頁面原型

只要做好了以上的工作，原型只是水到渠成的事情——可謂“邏輯思考10小時(shí)，原型作圖2分鐘”。

對(duì)于比較簡(jiǎn)單的需求，也很常用的是直接在原型頁面上編寫PRD文檔。

（原型直接標(biāo)注需求描述）

8. 數(shù)據(jù)說明

可能公司不同對(duì)產(chǎn)品的要求有區(qū)別，目前經(jīng)歷過的有：

• 要求寫明基本的請(qǐng)求參數(shù)，即字段說明；
• 要求設(shè)計(jì)基礎(chǔ)的業(yè)務(wù)表結(jié)構(gòu)，表明數(shù)據(jù)之間的建模關(guān)系，一對(duì)一、一對(duì)多、多對(duì)多等；
• 也有要求產(chǎn)品做業(yè)務(wù)數(shù)據(jù)建模；正在了解中，希望以后有機(jī)會(huì)可以寫一下。

（ER圖，數(shù)據(jù)之間的關(guān)系）

9. 全局規(guī)范

對(duì)通用交互原則、產(chǎn)品規(guī)則的描述，大型的團(tuán)隊(duì)一般會(huì)配專門的交互設(shè)計(jì)師，在原型設(shè)計(jì)的基礎(chǔ)上對(duì)產(chǎn)品交互進(jìn)行優(yōu)化。

10. 非功能性需求描述

• 埋點(diǎn)需求：對(duì)特定用戶的行為和活動(dòng)路徑進(jìn)行數(shù)據(jù)捕捉、獲取的手段，為產(chǎn)品的持續(xù)優(yōu)化迭代提供數(shù)據(jù)支撐；常用第三方埋點(diǎn)平臺(tái)而非自研埋點(diǎn)平臺(tái)，后者研發(fā)成本較高（偏向于產(chǎn)品的運(yùn)營(yíng)方向）。
• 產(chǎn)品性能需求：目前淺薄的了解過并發(fā)性能、響應(yīng)性能、安全性能等（技術(shù)向，了解不深）。

11. 文檔編寫工具

• Word文字描述 + 原型截圖：常用形式；
• Axure原型 + 批注/說明：需求簡(jiǎn)單情況適用；
• 口述：緊急需求適用，后期需補(bǔ)充文檔。

小結(jié)：PRD文檔的描述，需要保持交互邏輯的一致性（避免二級(jí)頁面，時(shí)而為“彈窗”時(shí)而為“跳轉(zhuǎn)頁面”）、文案風(fēng)格的一致性、功能命名的一致性、字段命名的一致性（避免個(gè)人名稱字段此列表叫“名稱”彼列表叫“姓名”的情況）。

七、How much | 文檔版本控制

5W2H原則，這里使用how much其實(shí)有點(diǎn)不太合適；但是文檔的版本記錄，還是值得一說的。

一般從0-1的產(chǎn)品文檔相對(duì)好寫一些，評(píng)審結(jié)束后研發(fā)期間，基本會(huì)對(duì)文檔進(jìn)行封版處理。

如果有不得已的情況需要對(duì)文檔進(jìn)行變動(dòng)，一定及時(shí)告知相關(guān)負(fù)責(zé)人員，例如產(chǎn)品領(lǐng)導(dǎo)、技術(shù)開發(fā)人員、測(cè)試人員，并及時(shí)維護(hù)文檔，每一次的變更都需要留下文字記錄。

個(gè)人認(rèn)為對(duì)閱讀者來說比較好的方式是：文檔頭部增加版本變更記錄，同時(shí)在文檔內(nèi)部用不同的顏色將變動(dòng)的內(nèi)容標(biāo)注出來。

已經(jīng)上線的版本變更，需要著重梳理變動(dòng)內(nèi)容和前后業(yè)務(wù)流程的關(guān)聯(lián)影響，特別是產(chǎn)品的業(yè)務(wù)耦合性比較強(qiáng)的，很容易發(fā)生修改一處需求，引起多出報(bào)錯(cuò)的情況。

版本變更記錄，需要包含的信息有：

• 版本號(hào)：重大變更V1.0.0/V2.0.0；小規(guī)模修改：V1.1.0/V1.2.0；
• 提交時(shí)間；
• 狀態(tài)：新增、變更或者刪除需求；
• 簡(jiǎn)要描述變更的內(nèi)容；
• 部門：需求提出人；
• 更改人：需求文檔變更人；
• 批準(zhǔn)人/批準(zhǔn)部門。

八、總結(jié)

PRD文檔的編寫是需要萬分聚精會(huì)神的細(xì)致的工作，基礎(chǔ)中現(xiàn)功底。

在評(píng)審結(jié)束后，PRD文檔交接給設(shè)計(jì)人員、開發(fā)人員，如果文檔編寫的足夠扎實(shí)，那基本不太會(huì)出現(xiàn)返工的情況，研發(fā)的過程也會(huì)比較順暢。

好的文檔，會(huì)讓研發(fā)人員覺得靠譜、安心，也會(huì)給產(chǎn)品經(jīng)理帶來一份自信。

特別是某天你躺在床上驚坐起，感覺自己漏了什么關(guān)鍵內(nèi)容，趕快打開文檔，發(fā)現(xiàn)聚精會(huì)神的狀態(tài)下自己的邏輯思考很嚴(yán)密沒有遺漏的時(shí)候，那種快樂你一定也體會(huì)過。

時(shí)間久了，你會(huì)更相信自己的判斷，能更從容的應(yīng)對(duì)來自各方的質(zhì)疑。

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

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