文檔｜產品經理通用的PRD模版
有部分朋友在公眾號后臺留言怎么撰寫一份文檔類的PRD。文檔撰寫由于占據產品經理大部分工作時間之一，所以高效、閱讀能讓下游開發(fā)者懂是一個基礎能力。
今天轉載一份刀哥的PRD文檔撰寫模板，幫助正在想辦法做文檔PRD撰寫的同學提升成績。
01 你是否遇到過這樣的問題？
PRD里關鍵需求描述不準確，研發(fā)過程中不斷修改，導致項目延期；
產品總監(jiān)、項目經理、研發(fā)、測試總是不斷挑刺，信譽度降低，自信心受打擊；
到新公司負責新項目，前任產品經理留下的文檔晦澀難懂，不知所云。
如果遇到以上一個或多個問題，那么你可能需要反思，自己寫PRD的思路是不是有問題？寫PRD是產品經理非常重要的基本功，寫好PRD，可以提高團隊效率，減少無效的溝通。
02 什么是PRD？
PRD是Product Requirement Document的簡稱，其中文翻譯為：產品需求文檔。該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最重要的一個文檔。
PRD的主要使用對象有：研發(fā)、測試、交互設計師及其他業(yè)務人員。
研發(fā)可以根據PRD獲知整個產品的邏輯，作為編碼的依據； 測試可以根據PRD編寫測試用例，為正式測試做準備； 交互設計師可以根據PRD設計交互細節(jié)； 業(yè)務人員可以通過PRD提前了解產品，為運營和推廣做準備；
PRD是項目啟動之前，必須經過評審達成共識的最重要文檔。
產品經理的PRD，就像建筑設計師的設計圖紙，是設計和思考的文檔化呈現。
《用戶體驗要素》作者在書中有一句很經典的話：“文檔不能解決問題，但定義可以”，PRD就是要定義需求。
03 動手之前，先思考這幾個問題
1. 解決什么問題？
解決用戶什么問題？發(fā)現問題比解決方案更重要。給公司能否帶來收益？相關干系人的需求是什么？是不是老板說這樣做的？是不是“他們”說這樣做的？他們是誰？真正的問題是他們說的那樣嗎？
產品經理正確的設計思路如下：
這叫RTPA設計框架，是一種逆向思維假設分析，我們要使用這樣一種思考技巧：假設初始需求都是錯誤的，即問題并不存在，你需要重新發(fā)現問題。
不要需求方一提需求，就開始著手設計，多問幾個為什么并著手調查，以了解真正的問題。
下面是一次完整的設計思路示例：
2. 怎么衡量？
不同的干系人，通過什么指標去衡量問題是否已解決？有沒有埋點？有沒有業(yè)務數據？誰來運營？
3. 需要多少資源？
為了實現這個解決方案，需要多少資源、多少人？能大致評估嗎?
4. 會不會太復雜？
這個解決方案會不會太復雜？復雜是產品的墳墓。有沒有性價比更高的解決方案？會不會影響現有的業(yè)務？會不會影響歷史數據？
5. 有風險嗎？
這個方案會有風險嗎?有沒有違法？相關政策是什么？尤其是金融、游戲領域，國家監(jiān)管比較嚴，有可能上不了應用市場，有可能三方服務商不會提供服務。
6. 有創(chuàng)新嗎？
有更創(chuàng)新的解決方案嗎?競品怎么做的，有沒有調研3個以上的競品方案。
7. 用戶怎么說？
需求真的是提交人說的那樣嗎?有親身體驗過場景嗎？有跟用戶面對面交流嗎？熟悉相關領域的基本知識嗎？有看不懂的名詞嗎？
動手寫文檔或做設計方案之前，一定要問問自己以上幾個問題，想清楚了在動手，任何一個問題沒想清楚，都不要進行下一步。
04 寫PRD的基本步驟
搭框架、定流程、扣細節(jié)，這是從一名產品前輩那了解到的產品設計流程，寫PRD，也可以按照這個思路。
2. 搭框架
首先遍歷出所有用戶角色，再針對每個角色，提供相應的系統(tǒng)/功能，然后按照某種維度進行結構劃分。這個步驟完成后，就可以輸出產品的系統(tǒng)架構圖及系統(tǒng)的功能結構圖。
產品架構圖，出自《電商產品設計全攻略》
更細化的功能結構圖
產品由一個個功能組成，功能是邏輯結構，一個完整的功能具備輸入、處理、輸出三大特性。從大到小的劃分是：系統(tǒng)>功能模塊>功能，用戶+功能組成了用例，用例是PRD文檔里描述占比70%以上的內容，所以合理的功能結構，是寫好PRD的前提。
2. 定流程
每個產品都有一個核心業(yè)務流程，這個核心業(yè)務流程涉及多個角色，這個步驟就是把各個角色和功能聯系起來。通過核心業(yè)務流程，閱讀者可以了解產品全貌，對產品有個宏觀的認識。
此外，每個系統(tǒng)也有各自的核心業(yè)務流程，全業(yè)務流程+子系統(tǒng)業(yè)務流程，可以概括產品的業(yè)務邏輯。
這個步驟輸出產品核心業(yè)務流程圖，子系統(tǒng)核心業(yè)務流程圖，活動圖，狀態(tài)機圖，與外部系統(tǒng)交互可能還有時序圖。
3. 扣細節(jié)
這一步的核心的畫原型和功能設計，通過原型表達產品的界面和交互。功能設計主要是從輸入處理輸出三個方面去考慮，用戶執(zhí)行輸入指令后，系統(tǒng)會進行邏輯處理，然后輸出結果。此外，還要考慮功能涉及到哪些數據，表結構怎樣設計，這些會涉及大量細節(jié)，PRD大部分內容，都是在描述這些細節(jié)。
步驟1和步驟2沒有嚴格的順序，也可以先梳理業(yè)務流程，再根據流程中的具體場景梳理出實際功能或系統(tǒng)結構。
03 文檔的組成部分
1. 修訂記錄
記錄每次文檔更新的時間、作者、修訂內容，便于追溯歷史變動；
2. 全局說明
包括名詞解釋、統(tǒng)一異常處理、列表默認數據規(guī)則等。
名詞解釋：每個行業(yè)都有專業(yè)術語，可以提前將晦澀難懂的術語提前做好解釋，便于達成共識，更好溝通； 統(tǒng)一異常處理：網絡異常、后臺服務異常的交互邏輯； 列表默認數據規(guī)則：默認列表的排序方式，默認顯示條數，超過多少條翻頁，缺省值展現方式； 所有涉及全局的描述，都可以羅列在這里。
3. 項目背景
每個產品，都有一套價值模型。以信貸產品為例，針對用戶的價值指標有放款額、審批時長、是否上征信等；針對后臺業(yè)務人員，有審批時效、通過率、放款率、壞賬率等指標；針對老板，有投資回報比、員工成本、凈利潤等價值指標，每一個需求，應該都是圍繞某個價值指標展開。
背景從現狀、方案、目標3方面描述。
現狀：描述當前需求方遇到的問題，最好能跟價值模型關聯； 方案：針對這個問題，所提供的解決方案概述； 目標：期望獲得多少價值指標提升；
通過項目背景的描述，可以讓項目參與者感受到自己的工作價值。
4. 項目范圍
項目范圍對應搭框架部分，將功能結構圖在此處羅列；
5. 業(yè)務流程
業(yè)務流程對應定流程部分，將核心業(yè)務流程、子系統(tǒng)業(yè)務流程在此處羅列；
6. 功能需求
這個部分在PRD中占比最大，搭框架部分，已經將產品功能點全部梳理出來了，這部分就是對功能點進行逐一描述。
功能是從系統(tǒng)的角度來看，我們還要考慮用戶角度，所有我們采用用戶+功能的方式來描述需求，這就是用例。完整用例名稱一定是動賓結構，如添加文章、刪除文章、修改文章、查看文章列表。
一個完整的用例包含：
描述（非必須） 前置條件 后置條件 界面交互 業(yè)務流程 異常和分支流程 數據字典（非必須）
1）描述
功能的簡要描述。
2）前置條件
要操作此功能，需要具備什么角色、權限或狀態(tài)。
3）后置條件
執(zhí)行完這個用例后，關聯的數據會有什么變化，頁面怎么跳轉。
4）界面
每個界面都可以拆分成多個元素，如表單、文本、鏈接、圖片等；
表單的每個元素要描述是否可為空、是否有初始內容、是否默認選中、是否有字數限制等，還有對應的錯誤提示；
文本要考慮最大顯示長度，超過怎么處理；
鏈接一定要指定點擊后跳轉到哪個頁面；
圖片要考慮顯示的比例，如果未加載出來該顯示什么；
還要考慮界面的內容是寫死還是通過后臺配置；
界面元素：
5）業(yè)務流程
當用戶完成輸入并提交時，后端應該做什么校驗，不同輸入該怎么處理，不同結果該返回什么值，最好通過業(yè)務流程圖+文字來描述，確保邏輯完整。
示例：
文字版：
6）異常和分支流程
異常流程如網絡錯誤、接口返回異常、服務器內部錯誤等；
以登錄為例，分支流程包括找回密碼、密碼登錄等，分支流程非必須，簡單的分支流程可以直接通過主流程體現，具體可以視情況按照一定顆粒度進行拆分。
7）數據字典
這個用例涉及哪些數據，可以通過數據字典描述，這一步非必須，最終表結構也不一定就是這樣，只是給開發(fā)一個參考。有技術背景的產品，也可以做得更細。以注冊功能涉及的用戶表為例：
產品經理一定要懂基本的數據庫知識，程序=數據結構+算法。用戶使用產品時，本質上是在和數據進行交互，只是在用戶和數據之間，加了一些列算法。
7. 非功能需求
數據需求。常見的就是數據埋點，產品經理需要梳理出埋點事件表，告知開發(fā)，讓開發(fā)在編碼過程中進行埋點。
監(jiān)控需求。需要監(jiān)控某個接口或某些服務，當出現異常時，可以發(fā)送報警信息至相關人員。
性能需求。需要支撐多大的并發(fā)，運維人員可以提前準備部署方案。
06 最后
一定要用正確的思路去寫PRD，更要想清楚PRD所呈現方案的價值。方向不對，努力白費。記住，找準問題比解決方案更重要。
來一起打卡，每天體驗1款APP
產品、運營、設計能力如何進階？其實就是多體驗產品、多拆解就對了。如果你現在想找一個地方既能打卡做日常訓練、還能找到優(yōu)秀的拆解案例，可以點擊下方鏈接，一起來打卡，每天體驗1款APP。（打卡完成，原路退回門票還能賺錢：
