對(duì)產(chǎn)品經(jīng)理來說，必備的一項(xiàng)技能就是寫出邏輯清晰可以實(shí)施的PRD。本文作者就從why，what，how三個(gè)層面對(duì)PRD文檔撰寫展開了分析，供大家參考學(xué)習(xí)。

上一篇文章已經(jīng)詳細(xì)講解了產(chǎn)品原型的保真度區(qū)別，原型設(shè)計(jì)的注意要點(diǎn)，規(guī)范標(biāo)準(zhǔn)，本篇文章將針對(duì)PRD文檔撰寫的why，what，how三個(gè)層面進(jìn)行分析。

01 寫PRD的目的

產(chǎn)品需求文檔，即Product Requirement Documen，PRD的主要使用對(duì)象有：開發(fā)、測(cè)試、項(xiàng)目經(jīng)理、設(shè)計(jì)師、運(yùn)營及其他業(yè)務(wù)人員。開發(fā)可以根據(jù)PRD獲知整個(gè)產(chǎn)品的邏輯；測(cè)試可以根據(jù)PRD建用例；項(xiàng)目經(jīng)理可以根據(jù)PRD拆分工作包，并分配開發(fā)人員；設(shè)計(jì)師可以通過PRD來設(shè)計(jì)交互細(xì)節(jié)。

PRD文檔是將產(chǎn)品項(xiàng)目由“概念化”階段推進(jìn)到“圖紙化”，將需求落實(shí)到可開發(fā)的。PRD文檔在產(chǎn)品項(xiàng)目中是一個(gè)“承上啟下”的作用，“向上”是對(duì)MRD內(nèi)容的繼承和發(fā)展，“向下”是要把MRD中的內(nèi)容技術(shù)化，側(cè)重的是對(duì)產(chǎn)品產(chǎn)品功能和性能（即“產(chǎn)品需求”）的說明，相對(duì)于MRD中的同樣內(nèi)容，要更加詳細(xì)，并進(jìn)行量化。

02 PRD撰寫的前提條件

進(jìn)行了需求收集與分析，構(gòu)建了系統(tǒng)架構(gòu)，繪制了功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖、產(chǎn)品結(jié)構(gòu)圖，2大流程圖（業(yè)務(wù)、頁面流程圖）以及所有頁面的原型稿、交互稿。完成這些部分之后，對(duì)以上部分進(jìn)行有機(jī)的整合，撰寫PRD文檔。

03 PRD內(nèi)容

3.1 文檔編寫記錄

記錄文檔創(chuàng)建，修改的情況，文檔的編寫狀態(tài)，編寫人

示例：

3.2 文檔修訂記錄

記錄每次修改的修改內(nèi)容，更詳細(xì)的進(jìn)行記錄每次修改的情況，對(duì)修改情況做概要性的描述，使查看人能夠清晰的感知修訂情況

示例：

3.3 目錄

根據(jù)PRD文檔的章節(jié)自動(dòng)生成生成，如果有變化進(jìn)行更新整個(gè)目錄的更新即可

示例：

3.4 概述

3.4.1 背景介紹

簡要說明產(chǎn)品/項(xiàng)目需求產(chǎn)生的背景，要達(dá)到的目的和需要實(shí)現(xiàn)的功能

示例：

通過建立招商加盟平臺(tái)的商戶管理系統(tǒng)，商戶（招商公司）能夠在商戶后臺(tái)直接發(fā)布項(xiàng)目、文章，進(jìn)行自有項(xiàng)目的推廣。商戶（招商公司）能夠在商戶后臺(tái)支付會(huì)員、廣告宣傳、站外文章發(fā)布等增值服務(wù)費(fèi)用?？梢越哟齺碜稍?cè)L問的用戶，并進(jìn)行交談，記錄用戶線索，形成用戶檔案。

商戶管理系統(tǒng)同時(shí)能為商戶提供數(shù)據(jù)分析功能，對(duì)在該商家的訪問、咨詢、成交用戶進(jìn)行分析，對(duì)商戶發(fā)布文章的宣傳效果，廣告投放效果進(jìn)行綜合分析，為商家的進(jìn)一步業(yè)務(wù)開拓提供決策依據(jù)。

3.4.2 涉及范圍

描述本次需求，主要涉及到公司內(nèi)部的哪些平臺(tái)，并簡要描述各平臺(tái)應(yīng)該做哪些事情

示例：

3.4.3 閱讀對(duì)象

描述本文檔的的閱讀對(duì)象有哪些，一般包含：公司業(yè)務(wù)總負(fù)責(zé)人、各平級(jí)部門經(jīng)理、產(chǎn)品經(jīng)理、UI設(shè)計(jì)師、研發(fā)工程師、測(cè)試工程師等與本項(xiàng)目相關(guān)的所有人員。

3.4.4 名詞解釋

對(duì)項(xiàng)目或者行業(yè)的專業(yè)詞匯的解釋，對(duì)于較為獨(dú)特的行業(yè)，或者專有名詞的，復(fù)雜的系統(tǒng)，一定要進(jìn)行名詞解釋。名詞解釋的目的：所有成員中達(dá)成認(rèn)知的一致，防止一個(gè)事物多種命名的情況產(chǎn)生，提高信息的傳遞效率，消除歧義。

3.5 結(jié)構(gòu)圖

產(chǎn)品相關(guān)結(jié)構(gòu)圖一般包含3種：功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖、產(chǎn)品結(jié)構(gòu)圖

3.5.1 功能結(jié)構(gòu)圖

定義：?功能結(jié)構(gòu)圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖。

作用：?產(chǎn)品設(shè)計(jì)時(shí)，輔助思路梳理，避免功能概念模糊、缺失。

繪制功能結(jié)構(gòu)時(shí)，盡量避免信息結(jié)構(gòu)要素出現(xiàn)的可能性，形容一個(gè)功能點(diǎn)時(shí)建議多采用“動(dòng)詞+名詞”的語言描述形式 。

示例：

3.5.2 信息結(jié)構(gòu)圖

定義：指脫離產(chǎn)品的實(shí)際頁面，將產(chǎn)品的數(shù)據(jù)抽象出來，組合分類的圖表。

作用：幫助PM梳理復(fù)雜內(nèi)容的信息組成，避免信息內(nèi)容在展示過程中出現(xiàn)遺漏、混亂、重復(fù)；

作為開發(fā)工程師建立數(shù)據(jù)庫的參考依據(jù)；信息結(jié)構(gòu)圖的繪制通常晚于功能結(jié)構(gòu)圖，往往是在產(chǎn)品設(shè)計(jì)階段的概念化過程中，在產(chǎn)品功能框架已確定、功能結(jié)構(gòu)已完善好的情況下才對(duì)產(chǎn)品信息結(jié)構(gòu)進(jìn)行分析設(shè)計(jì)。

示例：

3.5.3 產(chǎn)品結(jié)構(gòu)圖

定義：?產(chǎn)品結(jié)構(gòu)圖是綜合展示產(chǎn)品信息和功能邏輯的圖表??？梢岳斫鉃楫a(chǎn)品結(jié)構(gòu)圖是對(duì)產(chǎn)品原型的簡化表達(dá)，產(chǎn)品結(jié)構(gòu)圖就是通過信息架構(gòu)設(shè)計(jì)，將功能和信息以一種合理自然的邏輯，把功能結(jié)構(gòu)圖和信息結(jié)構(gòu)圖中的內(nèi)容放入產(chǎn)品中的每一個(gè)頁面的結(jié)果。

示例：

一般而言，直接采用產(chǎn)品結(jié)構(gòu)圖，對(duì)于概要描述，根據(jù)情況使用功能結(jié)構(gòu)圖，使用xmind制作產(chǎn)品功能結(jié)構(gòu)圖，并對(duì)產(chǎn)品功能進(jìn)行簡要描述。

3.5.4 產(chǎn)品功能概要

功能等級(jí)基本為三級(jí)+描述備注（模塊、功能、子功能或者其它叫法），根據(jù)功能結(jié)構(gòu)圖而來，控制好級(jí)別，并進(jìn)一步描述功能的內(nèi)容和作用，對(duì)功能排列優(yōu)先級(jí)，功能是否要進(jìn)行分期開發(fā)，如果需要分期開發(fā)，則對(duì)應(yīng)的開發(fā)周期需要注明，是否有另外的說明和備注，如果有則可以添加備注，盡量不要使用Excel中批注，很容易遺漏。

示例：

3.6 核心業(yè)務(wù)流程

對(duì)于本次需求中最核心的業(yè)務(wù)，采用泳道+文字描述的方式，對(duì)核心業(yè)務(wù)的階段、步驟以及異常情況及判斷進(jìn)行描述。

在畫業(yè)務(wù)流程之前，要深入了解核心業(yè)務(wù)，與相關(guān)業(yè)務(wù)人員進(jìn)行深入的溝通，確認(rèn)。確定泳道（即任務(wù)），確定產(chǎn)品有哪幾個(gè)階段，思考業(yè)務(wù)在各個(gè)階段的形態(tài)，如果業(yè)務(wù)流程涉及多個(gè)部門的，需要共同進(jìn)行溝通探討，并可對(duì)部分流程進(jìn)行優(yōu)化。思考清楚后開始畫業(yè)務(wù)流程圖，在畫的過程中也在頭腦中進(jìn)行梳理，盡可能的不遺漏任何的分支或異常情況。

可以采用的思考方法：

1. MECE——是Mutually Exclusive Collectively Exhaustive，中文意思是“相互獨(dú)立，完全窮盡”。也就是對(duì)于一個(gè)重大的議題，能夠做到不重疊、不遺漏的分類，而且能夠藉此有效把握問題的核心，并解決問題的方法，也是找出異常流程的重要方法之一；
2. 5W1H分析——是對(duì)選定的事項(xiàng)、流程或操作，都要從原因（何因Why）、對(duì)象（何事What）、地點(diǎn)（何地Where）、時(shí)間（何時(shí)When）、人員（何人Who）、方法（何法How）等六個(gè)方面提出問題進(jìn)行思考?？梢詫ふ伊鞒痰母纳品较颍瑯?gòu)思新的工作方法，以取代現(xiàn)行的工作流程方法；
3. 運(yùn)用ECRS四原則——即取消、合并、重組和簡化的原則，可以幫助人們找到更好的效能和更佳的工序方法。）。

業(yè)務(wù)流程圖并不是一成不變的，在多次討論會(huì)后中可能會(huì)有調(diào)整和變動(dòng)。但每次調(diào)整或變動(dòng)都需要進(jìn)行明確，保證流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，則子流程以及后續(xù)很多工作都會(huì)導(dǎo)致極大的變動(dòng)性，也會(huì)影響整體項(xiàng)目的進(jìn)度，特別是在研發(fā)已經(jīng)介入的情況，如果流程還存在不清晰的地方，開發(fā)工作也會(huì)反復(fù)。

3.6.1 核心業(yè)務(wù)流程

跨職能的泳道圖——泳道圖中需將業(yè)務(wù)數(shù)據(jù)流所涉及的所有業(yè)務(wù)平臺(tái)加入到泳道中，同時(shí)需區(qū)分正常流程和異常流程。

示例：

業(yè)務(wù)流程描述：

用文字描述上述流程圖中的所有流程，用以作為流程的補(bǔ)充說明，注意，流程中的每一步需以單獨(dú)的數(shù)字序號(hào)進(jìn)行描述。

示例：

優(yōu)惠券發(fā)放、使用、核銷流程

（1）優(yōu)惠活動(dòng)創(chuàng)建

1. 優(yōu)惠活動(dòng)由平臺(tái)設(shè)置。
2. 平臺(tái)創(chuàng)建優(yōu)惠活動(dòng)，費(fèi)用由平臺(tái)、設(shè)備提供方、或其它方承擔(dān)，具體承擔(dān)方由運(yùn)營進(jìn)行設(shè)置之前與各方溝通確認(rèn)，并在設(shè)置的之時(shí)進(jìn)行確定。
3. 此處活動(dòng)的設(shè)置，主要設(shè)置基本信息，如活動(dòng)的優(yōu)惠類型（滿減、立減、折扣類型可適當(dāng)減少，比如第一期只用滿減），針對(duì)什么商品類別或是單個(gè)商品，針對(duì)區(qū)域店鋪或者單個(gè)店鋪。

（2）優(yōu)惠券發(fā)放

1. 從優(yōu)惠活動(dòng)中選擇活動(dòng)，設(shè)置優(yōu)惠投放方案，如發(fā)放時(shí)間，有效期，針對(duì)門店，針對(duì)用戶（新用戶or老用戶），自動(dòng)發(fā)放還是用戶手動(dòng)領(lǐng)取
2. 設(shè)置投放方案后是否立即啟用，如果啟用，則在設(shè)置的投放時(shí)間向用戶投放
3. 不支持正在投放的優(yōu)惠券臨時(shí)修改，只能停止作廢，后臺(tái)作廢之后，用戶端不管是否還在有效期內(nèi)，均不能領(lǐng)取及使用
4. 正在使用的優(yōu)惠券，優(yōu)惠活動(dòng)原始模板不能更改，如要改變，需單獨(dú)創(chuàng)建。

（3）領(lǐng)取使用

1. 如果是系統(tǒng)自動(dòng)發(fā)放的優(yōu)惠券，用戶不需要單獨(dú)進(jìn)行領(lǐng)取，優(yōu)惠券自動(dòng)領(lǐng)取，在用戶端優(yōu)惠券中心可以看到
2. 如果需要用戶領(lǐng)取的，用戶可在領(lǐng)券中心進(jìn)行領(lǐng)取
3. 用戶在領(lǐng)取優(yōu)惠券之后，升降柜的優(yōu)惠券使用可讓用戶自己選擇，雙開門柜為拿貨之后自動(dòng)結(jié)算，則自動(dòng)選擇優(yōu)惠券使用，以優(yōu)惠最大的券為準(zhǔn)。

（4）核銷結(jié)算

1. 用戶使用優(yōu)惠券購買商品之后，如果用戶發(fā)生退款，則優(yōu)惠券不退會(huì)，且不可再使用（即優(yōu)惠券只能使用一次）
2. 如果訂單中包含多個(gè)商品，均有使用優(yōu)惠券，如果退款退貨只退其中一部分，則優(yōu)惠券也只退其中一部分，按比例進(jìn)行攤薄
3. 進(jìn)入清分結(jié)算的訂單，有使用優(yōu)惠券時(shí)，則在清分中按實(shí)際支付進(jìn)行清分，并標(biāo)注使用優(yōu)惠券
4. 優(yōu)惠券不進(jìn)入清分，優(yōu)惠券只進(jìn)行費(fèi)用承擔(dān)，但使用該優(yōu)惠券的訂單結(jié)算完成后，該筆優(yōu)惠券的費(fèi)用承擔(dān)狀態(tài)為完成。

備注：

1. 優(yōu)惠券采用創(chuàng)建與發(fā)放分開的形式，創(chuàng)建為創(chuàng)建優(yōu)惠活動(dòng)，不配置具體的發(fā)送方案
2. 用戶領(lǐng)取優(yōu)惠券后，在購買商品時(shí)，進(jìn)行金額的抵扣（用戶級(jí)別不一，則抵扣金額和券的類別有差異）

系統(tǒng)異常處理流程：

主要描述跨系統(tǒng)、角色間的業(yè)務(wù)流轉(zhuǎn)方面的異常處理邏輯。還有其它的一些通用異常處理：

1. 獲取地理位置權(quán)限失敗
2. 發(fā)送通知權(quán)限獲取失敗
3. 網(wǎng)絡(luò)情況

優(yōu)惠券流程示例：

1. 優(yōu)惠券發(fā)放錯(cuò)誤，停止活動(dòng)，則已發(fā)放的優(yōu)惠券用戶不能再使用，優(yōu)惠券失效
2. 優(yōu)惠券過期失效，不能再使用，并標(biāo)記已過期失效，并給予提示
3. 退款訂單中已使用的優(yōu)惠券，不再恢復(fù)到可使用狀態(tài)（即便未過期），直接作廢
4. 其它

3.7 產(chǎn)品界面級(jí)功能及交互需求說明

根據(jù)產(chǎn)品原型上的頁面結(jié)構(gòu)，構(gòu)建功能需求說明樹。

示例：

3.7.1 功能一（界面）

粘貼產(chǎn)品功能界面，并對(duì)產(chǎn)品功能界面的功能、交互進(jìn)行描述

示例：

使用流程：

以任務(wù)流方式，描述用戶在完成該功能時(shí)的步驟、業(yè)務(wù)邏輯。

示例（登錄）：

頁面交互：

各頁面間的交互，互動(dòng)鏈接關(guān)系，以一個(gè)功能所涉及的相關(guān)頁面為

示例

異常處理：

描述業(yè)務(wù)發(fā)起過程中的異常處理流程。

1. 手機(jī)號(hào)做位數(shù)及類型限制，位數(shù)只能11位，只能是數(shù)字。
2. 密碼由字母+數(shù)字構(gòu)成，字母區(qū)分大小寫，密碼的組合方式為“大寫字母or小寫字母+數(shù)字”，如果用戶輸入字符與此規(guī)則不匹配，則進(jìn)行提醒用戶按規(guī)范輸入
3. 如果用戶未輸入賬號(hào)密碼點(diǎn)擊登錄，手機(jī)賬號(hào)：提示“手機(jī)賬號(hào)未填寫”；密碼：提示“密碼未填寫”；賬號(hào)與密碼不匹配時(shí)，
4. 輸入的賬號(hào)未進(jìn)行注冊(cè)，提交檢測(cè)在后臺(tái)無記錄，提示：用戶賬號(hào)不存在
5. 用戶輸入的賬號(hào)與密碼不匹配，則提示：用戶名或密碼輸入錯(cuò)誤

3.8 安全需求

描述項(xiàng)目需要遵循的安全標(biāo)準(zhǔn)及需要進(jìn)行安全驗(yàn)證等。驗(yàn)證包括手機(jī)短信、身份信息、銀行信息，信用信息（芝麻信用）所有這些均有第三方接口進(jìn)行驗(yàn)證，支付費(fèi)用即可進(jìn)行驗(yàn)證。

3.9 數(shù)據(jù)監(jiān)測(cè)分析

數(shù)據(jù)監(jiān)測(cè)

采用數(shù)據(jù)埋點(diǎn)、數(shù)據(jù)采集等方法統(tǒng)計(jì)用戶行為數(shù)據(jù)。

第一種方式：自己開發(fā)——優(yōu)點(diǎn)是保密性高，所有數(shù)據(jù)都在自己的平臺(tái)中，但是很費(fèi)時(shí)間，要想做的好，對(duì)技術(shù)也有一定要求

第二種方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解決問題，另外growio，百度都有無埋點(diǎn)方式，就是不需要一個(gè)個(gè)數(shù)據(jù)點(diǎn)進(jìn)行單獨(dú)的埋點(diǎn)，而是監(jiān)測(cè)所有有數(shù)據(jù)傳輸，操作行為的點(diǎn)，接入sdk之后，可以自主選擇數(shù)據(jù)點(diǎn)進(jìn)行分析。這種方式，不會(huì)存在遺漏，靈活度也非常高。

數(shù)據(jù)分析

第一種方式也是完全自主開發(fā)，在早期的時(shí)候，數(shù)據(jù)量不大的時(shí)候，可以直接將數(shù)據(jù)導(dǎo)出進(jìn)行Excel表的分析，

第二種方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在選擇第三方的時(shí)候要注意，是否滿足企業(yè)要求（當(dāng)下及后期），是否可以進(jìn)行私有化部署，后期擴(kuò)展的靈活性，是否簡單易用，費(fèi)用。

3.10 系統(tǒng)日志需求

對(duì)系統(tǒng)處理業(yè)務(wù)的操作記錄或者邏輯記錄在日志中，便于后期查找、追溯。

3.11 驗(yàn)收標(biāo)準(zhǔn)

說明需求驗(yàn)收上線的評(píng)價(jià)指標(biāo)及參與驗(yàn)收的人員，可以制作驗(yàn)收單，產(chǎn)品是最終負(fù)責(zé)人。

3.12 其它產(chǎn)品需求

3.12.1 性能需求

明確產(chǎn)品的性能，知道產(chǎn)品性能上限，隨著業(yè)務(wù)的發(fā)展，清楚改善節(jié)點(diǎn)。在早期考慮綜合成本的情況并滿足業(yè)務(wù)需求的情況下，可以對(duì)性能做一定的妥協(xié)。

• 并發(fā)量：簡單的可以說，同一秒的登錄量，同時(shí)在線，訂單并發(fā)量最高可以允許多少。比如客服系統(tǒng)，允許同時(shí)對(duì)話200，也就是允許同時(shí)存在200對(duì)話通道。
• 圖片加載：圖片加載的時(shí)間，頁面跳轉(zhuǎn)切換的時(shí)間，在不同網(wǎng)速下，允許的時(shí)長（不同網(wǎng)絡(luò)情況下，信號(hào)有強(qiáng)弱，可能根本4G、5G信號(hào)，或者用戶的卡是3G）

3.12.2 兼容性、適配需求

PC——兼容目前主流的瀏覽器，比如IE8、及Firefox3.5、safari、chrome等主流瀏覽器的主流版本，將相關(guān)版本進(jìn)行羅列，同時(shí)考慮H5的跨設(shè)備適用性問題（比如官網(wǎng)在pc和手機(jī)的查看，看到過有些系統(tǒng)將功能復(fù)雜的后臺(tái)沒有做適配要在手機(jī)查看使用一團(tuán)糟的情況，功能復(fù)雜的后臺(tái)基本是不太適合在手機(jī)上操作的）。

機(jī)型——通過各種渠道（talkingdata，友盟）查目前的主流機(jī)型，市場(chǎng)占比，根據(jù)公司情況，選擇占比靠前的測(cè)試機(jī)型，或者采用第三方測(cè)試平臺(tái)（testin，testbird）

3.13 相關(guān)文檔

A、原型地址

XX平臺(tái)商戶后臺(tái)墨刀地址（密碼XXX）：

XX平臺(tái)系統(tǒng)后臺(tái)墨刀地址（密碼XXX）：

B、消息通知模板

C、其它

商標(biāo)，軟著，域名、服務(wù)器、支付平臺(tái)、消息接口、其它需要準(zhǔn)備各類平臺(tái)賬號(hào)及及截止時(shí)間節(jié)點(diǎn)，部分事項(xiàng)可以并行，部分事項(xiàng)有嚴(yán)格的先后順序，在進(jìn)行計(jì)劃安排時(shí)，需要作出區(qū)分，盡可能縮短時(shí)間，不要出現(xiàn)絕大部分人等一個(gè)人的情況出現(xiàn)。

04 產(chǎn)品向各方需求文檔內(nèi)容

4.1 給設(shè)計(jì)師文檔

思維導(dǎo)圖、流程圖、功能清單、原型圖（含交互）。

4.2 給研發(fā)文檔

思維導(dǎo)圖、功能清單、流程圖、原型圖、UI設(shè)計(jì)圖、PRD文檔、數(shù)據(jù)埋點(diǎn)文檔

4.3 給運(yùn)營文檔

思維導(dǎo)圖、流程圖、功能清單、PRD文檔、產(chǎn)品使用說明書，上線資料準(zhǔn)備清單（上線前需要準(zhǔn)備的比如需要錄入的商家信息）。

以上是PRD文檔相關(guān)內(nèi)容，下一篇文章將是——版本命名、驗(yàn)收規(guī)范、發(fā)版管理；

#相關(guān)閱讀#

產(chǎn)品管理流程及規(guī)范2——產(chǎn)品規(guī)劃及相關(guān)文檔

產(chǎn)品管理流程及規(guī)范3：產(chǎn)品原型設(shè)計(jì)

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

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