PRD文檔范例值得收藏的寫作手冊

1、2015年，我寫了一篇梳理PRD的文章 PRD到底該怎么寫？，獲得 3.5 萬次閱讀，423次收藏。至今已過去5年，在這 5年里，我一直從事產(chǎn)品產(chǎn)品相關(guān)的工作，也經(jīng)歷過一次完整的創(chuàng)業(yè)，對PRD 又有了一些新的思考。這篇文章是PRD怎么寫的升級版，彌補(bǔ)了之前文章的不足，對怎么寫 PRD,描述得 更具體、更全面，是我思考的沉淀，也希望對大家有一定幫助。01. 你是否遇到過這樣的問題如果遇到以上一個或多個問題，那么你可能需要反思，自己寫 PRD 的思路 是不是有問題？寫PRD是產(chǎn)品經(jīng)理非常重要的基本功，寫好 PRD,可以提高團(tuán) 隊效率，減少無效的溝通。02.什么是PRD?PRD是Product Re

2、quirement Documen的簡稱，其中文翻譯為：產(chǎn)品需求文檔。該文檔是產(chǎn)品項目由 “概念化 ”階段進(jìn)入到 “圖紙化 ”階段的最重要的一個文 檔。PRD 的主要使用對象有：研發(fā)、測試、交互設(shè)計師及其他業(yè)務(wù)人員。PRD是項目啟動之前，必須經(jīng)過評審達(dá)成共識的最重要文檔。產(chǎn)品經(jīng)理的PRD,就像建筑設(shè)計師的設(shè)計圖紙，是設(shè)計和思考的文檔化呈 現(xiàn)。用戶體驗要素作者在書中有一句很經(jīng)典的話： “文檔不能解決問題，但定義可以 ”， PRD 就是要定義需求。03. 動手之前，先思考這幾個問題1、解決什么問題？解決用戶什么問題？發(fā)現(xiàn)問題比解決方案更重要。給公司能否帶來收益？相關(guān)干系人的需求是什么？是不是老板說

3、這樣做的？是不是 “他們 ”說這樣做的？他們是誰？真正的問題是他們說的那樣嗎？產(chǎn)品經(jīng)理正確的設(shè)計思路如下：這叫 RTPA 設(shè)計框架，是一種逆向思維假設(shè)分析，我們要使用這樣一種思考技巧：假設(shè)初始需求都是錯誤的，即問題并不存在，你需要重新發(fā)現(xiàn)問題。不要需求方一提需求，就開始著手設(shè)計，多問幾個為什么并著手調(diào)查，以了解真正的問題。下面是一次完整的設(shè)計思路示例：2、怎么衡量？不同的干系人，通過什么指標(biāo)去衡量問題是否已解決？有沒有埋點？有沒有業(yè)務(wù)數(shù)據(jù)？誰來運營？3、需要多少資源？為了實現(xiàn)這個解決方案，需要多少資源、多少人？能大致評估嗎 ?4、會不會太復(fù)雜？這個解決方案會不會太復(fù)雜？復(fù)雜是產(chǎn)品的墳?zāi)?。有沒有

4、性價比更高的解決方案？會不會影響現(xiàn)有的業(yè)務(wù)？會不會影響歷史數(shù)據(jù)？5、有風(fēng)險嗎？這個方案會有風(fēng)險嗎?有沒有違法？相關(guān)政策是什么？尤其是金融、游戲領(lǐng)域，國家監(jiān)管比較嚴(yán)，有可能上不了應(yīng)用市場，有可能三方服務(wù)商不會提供服務(wù)。6、有創(chuàng)新嗎？有更創(chuàng)新的解決方案嗎?競品怎么做的，有沒有調(diào)研3 個以上的競品方案。7、用戶怎么說？需求真的是提交人說的那樣嗎?有親身體驗過場景嗎？有跟用戶面對面交流嗎？熟悉相關(guān)領(lǐng)域的基本知識嗎？有看不懂的名詞嗎？動手寫文檔或做設(shè)計方案之前，一定要問問自己以上幾個問題，想清楚了在動手，任何一個問題沒想清楚，都不要進(jìn)行下一步。04. 寫 PRD 的基本步驟搭框架、定流程、扣細(xì)節(jié)，這是從

5、一名產(chǎn)品前輩那了解到的產(chǎn)品設(shè)計流程，寫PRD,也可以按照這個思路。1、搭框架。首先遍歷出所有用戶角色，再針對每個角色，提供相應(yīng)的系統(tǒng)/功能，然后按照某種維度進(jìn)行結(jié)構(gòu)劃分。這個步驟完成后，就可以輸出產(chǎn)品的系統(tǒng)架構(gòu)圖及系統(tǒng)的功能結(jié)構(gòu)圖。產(chǎn)品架構(gòu)圖，出自電商產(chǎn)品設(shè)計全攻略更細(xì)化的功能結(jié)構(gòu)圖產(chǎn)品由一個個功能組成，功能是邏輯結(jié)構(gòu)，一個完整的功能具備輸入、處理、輸出三大特性。從大到小的劃分是：系統(tǒng)功能模塊功能，用戶+功能組成了用例，用例是PRD 文檔里描述占比70%以上的內(nèi)容，所以合理的功能結(jié)構(gòu)，是寫好PRD 的前提。2、定流程。每個產(chǎn)品都有一個核心業(yè)務(wù)流程，這個核心業(yè)務(wù)流程涉及多個角色，這個步驟就是把各

6、個角色和功能聯(lián)系起來。通過核心業(yè)務(wù)流程，閱讀者可以了解產(chǎn)品全貌，對產(chǎn)品有個宏觀的認(rèn)識。此外，每個系統(tǒng)也有各自的核心業(yè)務(wù)流程，全業(yè)務(wù)流程+子系統(tǒng)業(yè)務(wù)流程，可以概括產(chǎn)品的業(yè)務(wù)邏輯。這個步驟輸出產(chǎn)品核心業(yè)務(wù)流程圖，子系統(tǒng)核心業(yè)務(wù)流程圖，活動圖，狀態(tài)機(jī)圖，與外部系統(tǒng)交互可能還有時序圖。3、扣細(xì)節(jié)。這一步的核心的畫原型和功能設(shè)計，通過原型表達(dá)產(chǎn)品的界面和交互。功能設(shè)計主要是從輸入處理輸出三個方面去考慮，用戶執(zhí)行輸入指令后，系統(tǒng)會進(jìn)行邏輯處理，然后輸出結(jié)果。此外，還要考慮功能涉及到哪些數(shù)據(jù)，表結(jié)構(gòu)怎樣設(shè)計，這些會涉及大量細(xì)節(jié)，PRD大部分內(nèi)容，都是在描述這些細(xì)節(jié)。步驟 1 和步驟 2 沒有嚴(yán)格的順序，也可

7、以先梳理業(yè)務(wù)流程，再根據(jù)流程中的具體場景梳理出實際功能或系統(tǒng)結(jié)構(gòu)。05. 文檔的組成部分1、修訂記錄記錄每次文檔更新的時間、作者、修訂內(nèi)容，便于追溯歷史變動；2、全局說明包括名詞解釋、統(tǒng)一異常處理、列表默認(rèn)數(shù)據(jù)規(guī)則等。3、項目背景每個產(chǎn)品，都有一套價值模型。以信貸產(chǎn)品為例，針對用戶的價值指標(biāo)有放款額、審批時長、是否上征信等；針對后臺業(yè)務(wù)人員，有審批時效、通過率、放款率、壞賬率等指標(biāo)；針對老板，有投資回報比、員工成本、凈利潤等價值指標(biāo)，每一個需求，應(yīng)該都是圍繞某個價值指標(biāo)展開。背景從現(xiàn)狀、方案、目標(biāo) 3 方面描述。通過項目背景的描述，可以讓項目參與者感受到自己的工作價值。4、項目范圍項目范圍對應(yīng)

8、搭框架部分，將功能結(jié)構(gòu)圖在此處羅列；5、業(yè)務(wù)流程業(yè)務(wù)流程對應(yīng)定流程部分，將核心業(yè)務(wù)流程、子系統(tǒng)業(yè)務(wù)流程在此處羅列；6、功能需求這個部分在 PRD 中占比最大，搭框架部分，已經(jīng)將產(chǎn)品功能點全部梳理出來了，這部分就是對功能點進(jìn)行逐一描述。功能是從系統(tǒng)的角度來看，我們還要考慮用戶角度，所有我們采用用戶+功能的方式來描述需求，這就是用例。完整用例名稱一定是動賓結(jié)構(gòu)，如添加文章、刪除文章、修改文章、查看文章列表。一個完整的用例包含：描述功能的簡要描述。前置條件要操作此功能，需要具備什么角色、權(quán)限或狀態(tài)。后置條件執(zhí)行完這個用例后，關(guān)聯(lián)的數(shù)據(jù)會有什么變化，頁面怎么跳轉(zhuǎn)。界面每個界面都可以拆分成多個元素，如表

9、單、文本、鏈接、圖片等；表單的每個元素要描述是否可為空、是否有初始內(nèi)容、是否默認(rèn)選中、是否有字?jǐn)?shù)限制等，還有對應(yīng)的錯誤提示；文本要考慮最大顯示長度，超過怎么處理；鏈接一定要指定點擊后跳轉(zhuǎn)到哪個頁面；圖片要考慮顯示的比例，如果未加載出來該顯示什么；還要考慮界面的內(nèi)容是寫死還是通過后臺配置；界面元素：業(yè)務(wù)流程當(dāng)用戶完成輸入并提交時，后端應(yīng)該做什么校驗，不同輸入該怎么處理，不同結(jié)果該返回什么值，最好通過業(yè)務(wù)流程圖+文字來描述，確保邏輯完整。示例：文字版：異常和分支流程異常流程如網(wǎng)絡(luò)錯誤、接口返回異常、服務(wù)器內(nèi)部錯誤等；以登錄為例，分支流程包括找回密碼、密碼登錄等，分支流程非必須，簡單的分支流程可以直接通過主流程體現(xiàn)，具體可以視情況按照一定顆粒度進(jìn)行拆分。數(shù)據(jù)字典這個用例涉及哪些數(shù)據(jù)，可以通過數(shù)據(jù)字典描述，這一步非必須，最終表結(jié)構(gòu)也不一定就是這樣，只是給開發(fā)一個參考。有技術(shù)背景的產(chǎn)品，也