寫好產(chǎn)品文檔，是每個(gè)產(chǎn)品經(jīng)理都要掌握的基本功。，但產(chǎn)品新人總會(huì)遇到各種問題，比如：
不清楚文檔的內(nèi)容，不知如何下筆；
文檔內(nèi)容不規(guī)范，邏輯混亂；
-盲目套用模板，分不清使用場(chǎng)景，耗時(shí)且無(wú)用。
第1章 什么是PRD文檔
1 PRD初識(shí)
PRD是產(chǎn)品需求文檔（Product Requirement Document）的簡(jiǎn)稱，該文檔是產(chǎn)品項(xiàng)目由“概念化”階段向“圖紙化”階段的最主要的一個(gè)文檔。
戰(zhàn)略：產(chǎn)品定位、目標(biāo)市場(chǎng)、目標(biāo)用戶、競(jìng)爭(zhēng)對(duì)手
戰(zhàn)術(shù)：產(chǎn)品的結(jié)構(gòu)、核心業(yè)務(wù)流程、具體用例描述、功能&內(nèi)容描述等
2 PRD的用戶及作用
2.1 PRD的由來(lái)
1、以文檔的形式準(zhǔn)確傳達(dá)需求
2、約束產(chǎn)品經(jīng)理、開發(fā)
3、驗(yàn)收產(chǎn)品質(zhì)量
4、記錄產(chǎn)品迭代
5、專業(yè)能力的體現(xiàn)
2.2 PRD閱讀用戶 （開發(fā)&測(cè)試、產(chǎn)品經(jīng)理、UI設(shè)計(jì)師）
2.3 PRD的作用
產(chǎn)品經(jīng)理：根據(jù)PRD進(jìn)行方案的宣講，并作為最終檢驗(yàn)產(chǎn)品實(shí)現(xiàn)程度的依據(jù)
開發(fā)&測(cè)試：根據(jù)PRD的系統(tǒng)規(guī)則等內(nèi)容作為研發(fā)依據(jù)；根據(jù)PRD的規(guī)則來(lái)編寫用例及測(cè)試
UI設(shè)計(jì)師：根據(jù)PRD的原型作為UI設(shè)計(jì)參考
最終目的都是為了團(tuán)隊(duì)成員能夠理解業(yè)務(wù)，在產(chǎn)品研發(fā)過程中得到更好的執(zhí)行
3 MRD、BRD、PRD的區(qū)別
BRD：商業(yè)需求文檔 Business Requirement Document
MRD：市場(chǎng)需求文檔 Market Requirement Document
PRD：產(chǎn)品需求文檔 Product Requirement Document
| 文檔名稱 | 文檔用戶 | 痛點(diǎn) |
|---|---|---|
| BRD | 老板or 項(xiàng)目負(fù)責(zé)人 | 1、要做什么樣的產(chǎn)品 2、需要哪些資源（人、時(shí)間、場(chǎng)地、錢） 3、最終的走向藍(lán)圖（盈利） |
| MRD | 商務(wù)、運(yùn)營(yíng)、市場(chǎng) | 1、產(chǎn)品的定位 2、需要什么楊的資源 3、拿什么說(shuō)服客戶 |
| PRD | 開發(fā)、測(cè)試、UI設(shè)計(jì)師 | 1、產(chǎn)品的形（流程圖、原型圖、需求說(shuō)明） 2、如何實(shí)現(xiàn)（人，時(shí)間） 3、體驗(yàn)優(yōu)化 |
4 實(shí)現(xiàn)PRD文檔的幾種工具
word 有目錄讓人更容易總覽全局
原型軟件 原型版在功能需求描述時(shí)表現(xiàn)更靈活 Axure（8 or 9），墨刀，摹客
第2章 30分鐘內(nèi)攥寫一份敏捷的PRD文檔
2.1 一份敏捷的PRD要素有哪些
| 開發(fā)模式 | 優(yōu)點(diǎn) |
|---|---|
| 敏捷開發(fā) | 1、開發(fā)周期短（1-2周為一個(gè)周期） 2、更強(qiáng)調(diào)隊(duì)伍的高度協(xié)作 3、更迅速的響應(yīng) |
| 瀑布模式 | 1、為項(xiàng)目提供了按階段劃分的檢查點(diǎn) 2、當(dāng)前一階段完成后，您只需要去關(guān)注后續(xù)階段 3、可在迭代模型中應(yīng)用瀑布模型 4、它提供了一個(gè)模板，這個(gè)模板使得分析、設(shè)計(jì)、編碼、測(cè)試和支持的方法可以在該模板下有一個(gè)共同的指導(dǎo) |
| 迭代增量式 | 1、降低風(fēng)險(xiǎn) 2、得到早期用戶反饋 3、持續(xù)的測(cè)試和集成 4、使用變更 5、提高復(fù)用性 |
| 螺旋模式 | 1、設(shè)計(jì)上的靈活性,可以在項(xiàng)目的各個(gè)階段進(jìn)行變更。 2、以小的分段來(lái)構(gòu)建大型系統(tǒng),使成本計(jì)算變得簡(jiǎn)單容易。 3、客戶始終參與每個(gè)階段的開發(fā),保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性。 4、隨著項(xiàng)目推進(jìn),客戶始終掌握項(xiàng)目的最新信息 , 從而他或她能夠和管理層有效地交互。 5、客戶認(rèn)可這種公司內(nèi)部的開發(fā)方式帶來(lái)的良好的溝通和高質(zhì)量的產(chǎn)品。 |
PRD的要素：
命名、編號(hào)
版本歷史、目錄
引言
需求概述
功能性的需求說(shuō)明
非功能描述
撰寫原則：
貼合團(tuán)隊(duì)實(shí)際情況
清晰、有效
2.2 文檔標(biāo)識(shí)
文檔命名和編號(hào) XX產(chǎn)品V1.0PRD_V2
-
版本歷史
文檔版本號(hào)： V2.1 文檔編號(hào)： 1.0 文檔密級(jí)： 項(xiàng)目組成員可見 歸屬部門/項(xiàng)目： 產(chǎn)品名 慕課網(wǎng) 子系統(tǒng)名 編寫人： xxx 編寫日期 xxx -
版修訂記錄
版本號(hào) 修訂人 修訂日期 修訂描述 -
目錄
目錄.png
2.3 PRD文檔引言
-
產(chǎn)品背景
1、說(shuō)明該產(chǎn)品研發(fā)的背景、市場(chǎng)趨勢(shì)、發(fā)展前景
2、說(shuō)明該產(chǎn)品研發(fā)的目的、意義、里程碑式的建設(shè)
-
預(yù)期讀者
1、該文檔的讀者
2、說(shuō)明該產(chǎn)品每一階段的迭代目標(biāo)，開發(fā)及UI在初期要達(dá)到的效果
-
名詞解釋
1、對(duì)文檔中會(huì)出現(xiàn)的比較新的名稱進(jìn)行解釋
2、 該文檔的參考資料
2.4 需求描述
業(yè)務(wù)流程
用戶角色
- 功能清單
運(yùn)行環(huán)境 該產(chǎn)品上線后的使用環(huán)境，比如支持的瀏覽器版本，操作系統(tǒng)、數(shù)據(jù)庫(kù)的要求等等。測(cè)試人員看到環(huán)境要求后會(huì)在測(cè)試時(shí)重點(diǎn)測(cè)試，而最終上線產(chǎn)品時(shí)需要把最佳的運(yùn)行環(huán)境告知用戶，設(shè)計(jì)和實(shí)現(xiàn)上的限制，比如控件的開發(fā)環(huán)境，接口的調(diào)用方式等等。
-
產(chǎn)品規(guī)劃
對(duì)PRD中要求開發(fā)的內(nèi)容，給出關(guān)鍵里程碑，比如需求評(píng)審?fù)ㄟ^的時(shí)間，開發(fā)完成的時(shí)間、上線的時(shí)間
描述產(chǎn)品可能存在的風(fēng)險(xiǎn)，比如性能瓶頸，沒有解決的問題，用戶不當(dāng)使用的風(fēng)險(xiǎn)等等。
2.5 功能性需求說(shuō)明
簡(jiǎn)要說(shuō)明：介紹此功能的用途，包括其來(lái)源或背景，能夠解決哪些問題
場(chǎng)景描述：產(chǎn)品在那種情況下會(huì)被用戶使用，就是用戶場(chǎng)景模擬，這也是產(chǎn)品經(jīng)理講好故事的必備調(diào)節(jié)
| 用戶場(chǎng)景 | 【描述用戶操作場(chǎng)景，如：用戶從首頁(yè)登錄】 |
|---|---|
| 功能描述 | 【描述該場(chǎng)景下的功能特性】 |
業(yè)務(wù)規(guī)則：每種產(chǎn)品開發(fā)時(shí)都有相應(yīng)的業(yè)務(wù)規(guī)則，將這些規(guī)則清晰的描述出來(lái)，讓開發(fā)、測(cè)試人員能夠直觀的明白該規(guī)則，且沒有產(chǎn)生歧義。業(yè)務(wù)規(guī)則必須是完整的，準(zhǔn)確的，易懂的
原型圖（涉及到頁(yè)面交互的部分）
前置條件：該需求實(shí)現(xiàn)依賴的前提條件。比如，上傳照片時(shí)，需要存有圖片文獻(xiàn)
后置條件：操作后引發(fā)的后續(xù)處理
2.6 非功能性描述
-
性能需求
產(chǎn)品使用的并發(fā)性能，相應(yīng)性能、安全性能、預(yù)期效果描述
需求變更的機(jī)會(huì)
運(yùn)營(yíng)需求 產(chǎn)品上線后如何運(yùn)營(yíng)，目標(biāo)受眾是什么，建議的推廣策略、問題反饋的途徑、風(fēng)險(xiǎn)監(jiān)控、亮點(diǎn)宣傳等等，以及與運(yùn)營(yíng)人員的協(xié)作方式
風(fēng)險(xiǎn)分析 對(duì)產(chǎn)品上線后可能遇到的風(fēng)險(xiǎn)、問題進(jìn)行可能性、嚴(yán)重性分析，并提出對(duì)應(yīng)的策略，保持產(chǎn)品的持續(xù)運(yùn)營(yíng)。
2.7 總結(jié)
-
做好功能關(guān)聯(lián)性，避免功能模塊缺失
在組織結(jié)構(gòu)時(shí)，一開始不要陷入細(xì)節(jié)，從大到小進(jìn)行組織
從場(chǎng)景出發(fā)
對(duì)照產(chǎn)品、按照頁(yè)面順序羅列功能點(diǎn)，然后往框架里面丟
-
匯總通用CASE大全，作為自查清單
比如初識(shí)化時(shí)元素有哪些
比如外界打擾（網(wǎng)絡(luò)異常），如何反應(yīng)
表單提交或者操作時(shí)的各種狀態(tài)等等
-
做好備選方案，考慮全面
評(píng)審時(shí)技術(shù)提出B方案，這時(shí)需要給出A方案的優(yōu)勢(shì)
如該方案無(wú)法實(shí)施，可以立馬反應(yīng)
第3章 用產(chǎn)品思維解析PRD文檔
3.1 實(shí)戰(zhàn)解析PRD 在線問診APP
- 寫前準(zhǔn)備
在寫PRD文檔之前，我們需要先羅列出產(chǎn)品功能的信息內(nèi)容
羅列信息的方式：文本，思維導(dǎo)圖，架構(gòu)圖
3.2 文檔與業(yè)務(wù)說(shuō)明
-
全局說(shuō)明
名詞、術(shù)語(yǔ)的說(shuō)明 比如：預(yù)約掛號(hào)指用戶在網(wǎng)上預(yù)約，在線下及進(jìn)行就診
權(quán)限彈窗 例如游客身份登錄，無(wú)法進(jìn)行就診操作
權(quán)限彈窗.png
* 時(shí)間規(guī)范 比如格式為yyyy-mm-dd hh:mm:ss
* 異常情況 例如網(wǎng)絡(luò)異常，未綁定手機(jī)號(hào)
- 業(yè)務(wù)流程 舉例：預(yù)約掛號(hào)流程
總結(jié)：
文檔說(shuō)明部分：一定要及時(shí)更新，讓團(tuán)隊(duì)成員可以清晰進(jìn)度
業(yè)務(wù)流程：最好分角色，分場(chǎng)景，分過程詳細(xì)說(shuō)明
3.3 角色與功能結(jié)構(gòu)
-
用戶角色
用戶角色 用戶描述 患者 主要使用預(yù)約掛號(hào)，在線問診服務(wù) 醫(yī)生 主要使用發(fā)布信息，在線接診服務(wù) 藥師 主要使用處方流轉(zhuǎn)服務(wù) 其他用戶 所有使用在線問診APP的外部用戶 -
功能清單 功能清單時(shí)產(chǎn)品功能的列表集合，一般包括功能模塊，子模塊，功能點(diǎn)，優(yōu)先級(jí)和功能描述
功能模塊 主要功能點(diǎn) 優(yōu)先級(jí) 首頁(yè) 掛號(hào) 高 問診 高 購(gòu)藥 中 特色服務(wù) 低 找醫(yī)生 中 精選專區(qū) 低 健康商城 低 產(chǎn)品信息結(jié)構(gòu)圖
3.4 需求詳細(xì)說(shuō)明
- 原型圖
需求描述 需求說(shuō)明：首頁(yè)包含掛號(hào)，問診，購(gòu)藥，醫(yī)生列表
-
功能說(shuō)明
支持搜索，輸入框形式
支持消息通知，點(diǎn)擊消息按鈕可跳轉(zhuǎn)到消息頁(yè)面
支持掛號(hào)，問診，購(gòu)藥
交互：點(diǎn)擊掛號(hào)按鈕，跳轉(zhuǎn)到預(yù)約掛號(hào)頁(yè)面
交互：點(diǎn)擊問診按鈕，跳轉(zhuǎn)到預(yù)約問診頁(yè)面
-
交互：點(diǎn)擊醫(yī)生模塊，進(jìn)入醫(yī)生詳情頁(yè)面
需求說(shuō)明示例.png
-
非功能描述
性能描述：展示訂單數(shù)據(jù)的時(shí)候需要即時(shí)展示，不可以感受到明顯的后臺(tái)查詢過程
兼容需求：需要滿足iphone 8以上，安卓系統(tǒng)
風(fēng)險(xiǎn)分析：用戶使用率不高，盈利不能支撐產(chǎn)品運(yùn)營(yíng)
總結(jié) ：需求描述一定要細(xì)，一定要全面
3.5 PRD文檔的后續(xù)工作
-
需求評(píng)審
召開需求評(píng)審會(huì)，向項(xiàng)目成員闡述需求
成員：后端、前端、UI、測(cè)試
需求更改：針對(duì)成員提出的建議完善PRD文檔
修訂歷史
版本號(hào) 修訂人 修訂日期 修訂描述 1.0 北風(fēng)大叔 新建 1.1 北風(fēng)大叔 修改首頁(yè)掛號(hào)模塊，新增線下預(yù)約功能 -
測(cè)試
產(chǎn)品經(jīng)理需要在開發(fā)完成后，走一遍流程，看是否閉環(huán)
把自己想象成各種角色，帶入各種場(chǎng)景
剩下的測(cè)試，交給專業(yè)的測(cè)試人員就好
-
產(chǎn)品上線需要的文檔
PRD文檔
用戶操作手冊(cè)（分角色）
功能清單
總結(jié)： PRD只是產(chǎn)品工作開展的一步，后續(xù)的持續(xù)完善，跟進(jìn)才是決定產(chǎn)品優(yōu)劣的關(guān)鍵
第4章 課程盤點(diǎn)
4.1 寫PRD文檔時(shí)，產(chǎn)品經(jīng)理如何做到不被開發(fā)懟
- PRD 輸出效率
leve1： PRD輸出速度慢+低質(zhì)量
leve2： PRD輸出速度快+低質(zhì)量
leve3： PRD輸出速度快+高質(zhì)量
- PRD質(zhì)量
什么樣的PRD文檔才算達(dá)標(biāo)呢： 程序看的懂，測(cè)試不罵人 。產(chǎn)品架構(gòu)、復(fù)用準(zhǔn)則、邏輯思維、異常處理以及可讀性體現(xiàn)
-
如何保證質(zhì)量
“先禮后兵”：用程序員的思維思考，決不妥協(xié)用戶體驗(yàn)
有邏輯的講故事
不放過細(xì)節(jié)，異常情況
4.2 產(chǎn)品PRD自查清單
需求的產(chǎn)出不難，需求產(chǎn)出后的設(shè)計(jì)細(xì)節(jié)容易有遺漏。針對(duì)產(chǎn)品經(jīng)理寫的PRD文檔進(jìn)行各項(xiàng)指標(biāo)的檢查。
-
產(chǎn)品PRD自查清單
序號(hào) 類型 檢查項(xiàng) 是否檢查 備注 1 介紹 背景以及功能說(shuō)明 2 介紹 需求涉及范圍：如平臺(tái)、app、公眾號(hào)、小程序等 3 介紹 需求涉及用戶、崗位、描述、角色、權(quán)限等 4 表單 文本框的輸入長(zhǎng)度、格式說(shuō)明 5 表單 文件、圖片上傳的大小、說(shuō)明 6 表單 時(shí)間控件精確年月日時(shí)分秒 7 表單 明確表單輸入項(xiàng)（啟用，禁用）、輸出項(xiàng) 8 表單 需必填校驗(yàn)說(shuō)明 9 表單 數(shù)據(jù)重復(fù)校驗(yàn)說(shuō)明 10 表單 單選、復(fù)選、下拉選項(xiàng)默認(rèn)值說(shuō)明 11 表單 單選、復(fù)選、下拉的數(shù)據(jù)來(lái)源說(shuō)明 12 表單 添加多組數(shù)據(jù)時(shí)最大值、最小值的限制 13 表單 提示文案有無(wú)遺漏 14 業(yè)務(wù) 需求在系統(tǒng)中的整體流程圖以及流程閉環(huán)檢查。如需求在系統(tǒng)從 開始到需求處理的整個(gè)過程到結(jié)束的每個(gè)步驟通過流程圖的方式說(shuō)明清楚 15 業(yè)務(wù) 數(shù)據(jù)狀態(tài)說(shuō)明、變更說(shuō)明、如開發(fā)中、測(cè)試中、已測(cè)試、 審核中、審核完成所有狀態(tài)的說(shuō)明及狀態(tài)切換的測(cè)試條件 16 場(chǎng)景 多場(chǎng)景的描述 17 數(shù)據(jù) 針對(duì)功能新增，刪除，編輯等操作按鈕的控制說(shuō)明 18 數(shù)據(jù) 按鈕功能的操作是否需要二次彈框確認(rèn)，以及確認(rèn)文案 19 數(shù)據(jù) 列表數(shù)據(jù)的列寬大致說(shuō)明，以及是否需要固定，如名稱控制列寬能顯示30個(gè)字符，如 超過用。。。表示，鼠標(biāo)懸浮顯示全稱 20 數(shù)據(jù) 數(shù)據(jù)的排序說(shuō)明 21 數(shù)據(jù) 數(shù)據(jù)權(quán)限說(shuō)明 22 數(shù)據(jù) 查詢條件是否有默認(rèn)值，有則需要說(shuō)明 23 數(shù)據(jù) 數(shù)據(jù)是否需要分頁(yè)顯示 24 數(shù)據(jù) 數(shù)據(jù)的編輯，刪除的控制說(shuō)明，如數(shù)據(jù)被引用后點(diǎn)擊刪除、反選或者編輯的處理 25 數(shù)據(jù) 是否關(guān)聯(lián)其他數(shù)據(jù)或者功能說(shuō)明 26 交互 點(diǎn)擊按鈕的效果、如按鈕點(diǎn)擊前、點(diǎn)擊后 27 交互 彈出層、下拉框的高度、寬度說(shuō)明 28 交互 數(shù)據(jù)加載中，請(qǐng)求中，等待相應(yīng)的說(shuō)明 29 交互 文案提示的位置 30 交互 頁(yè)面之間交互的說(shuō)明 31 初始化 功能模塊是否初始化數(shù)據(jù)，有則需要說(shuō)明 32 初始化 歷史數(shù)據(jù)是否需要進(jìn)行特殊處理，有則需要說(shuō)明 33 測(cè)試 需求測(cè)試重點(diǎn)需要單獨(dú)進(jìn)行說(shuō)明 34 報(bào)表/圖表 共用查詢條件和每個(gè)報(bào)表的關(guān)系檢查是否有沖突、如公共查詢 條件有時(shí)間范圍查詢，但報(bào)表是閱讀、年度查詢 35 報(bào)表/圖表 每個(gè)報(bào)表或者圖表的默認(rèn)查詢條件 36 報(bào)表/圖表 報(bào)表的數(shù)據(jù)來(lái)源，包含每個(gè)統(tǒng)計(jì)數(shù)據(jù)的來(lái)源 37 報(bào)表/圖表 報(bào)表或者圖表的最大、最小限制說(shuō)明、避免圖表過于單一或者過于復(fù)雜 38 報(bào)表/圖表 數(shù)據(jù)精度說(shuō)明，如數(shù)字保留2位小數(shù) 39 報(bào)表/圖表 報(bào)表或者圖表的動(dòng)效說(shuō)明 說(shuō)明 總結(jié)：需求的自查、有效有用的自查、是一個(gè)非常有效也有用的方法之一，能避免PRD文檔出現(xiàn)低級(jí)錯(cuò)誤或者明顯的遺漏，導(dǎo)致后續(xù)時(shí)間成本、溝通成本、人力成本的增長(zhǎng)
4.3 高效產(chǎn)出PRD的“三不”
PRD 的普遍交付形式 Axure原型+文本，即可視化
-
不寫廢話
去掉大家都知道的規(guī)則，如 密碼顯示***
詳細(xì)說(shuō)明特殊的規(guī)則，如切換按鈕的條件
-
不做高保真
缺點(diǎn)1：需求變更時(shí)，修改成本高，影響開發(fā)的進(jìn)度
缺點(diǎn)2：影響UI的判斷，畫蛇添足
用線框圖體現(xiàn)功能框架即可
體現(xiàn)核心功能，需求說(shuō)明詳細(xì)即可
-
不重復(fù)
全局規(guī)則很重要，這可以省去很多重復(fù)的說(shuō)明，比如網(wǎng)絡(luò)故障
產(chǎn)品經(jīng)理可以收藏或者積累一套組件，節(jié)省不必要的創(chuàng)新
不是所有的設(shè)計(jì)都要?jiǎng)?chuàng)新，有時(shí)一致才是尊重用戶
4.4 圍繞用戶體驗(yàn)的PRD文檔
- 戰(zhàn)略層
用戶畫像（什么場(chǎng)景，那類用戶）
用戶的痛點(diǎn)
我們能得到什么
- 范圍層
輸出功能+信息結(jié)構(gòu)圖
輸出整體的規(guī)劃，具體到時(shí)間點(diǎn)
結(jié)構(gòu)層 流程圖的形式，從邏輯上梳理思路，并達(dá)成一致
框架層 制作產(chǎn)品demo，即原型圖，這塊的需求說(shuō)明很重要！ 數(shù)據(jù)埋點(diǎn)，可以用截圖+表格形式體現(xiàn)
表現(xiàn)層 輸出產(chǎn)品UI圖，表現(xiàn)如何看UI同學(xué)的實(shí)力
