起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識PRD修煉真經?卷二：一份標準化產品需求文檔的邏輯思路
最近比較忙，水逆沒有動力更新，接上一篇《PRD修煉真經?卷一》。
特別聲明：此文目的是解構標準化PRD中各章節的邏輯，并不是PRD的模版。
不用自宮，也能成功。
功能需求
功能需求是PRD核心內容，前面說引言是幫助理解文檔本身，概述幫助理解項目和產品本身，那么功能需求部分就是幫助理解業務和功能。下面對功能需求的各部分內容進行詳細說明。
概要功能需求
概要功能需求是用于描述提供給用戶的產品特性和功能。通常使用框圖、表、文字結合的方式說明，便于快速理解。
業務需求
幫助理解產品的業務需求和內容
產品描述：總整體上解釋和描述產品定位，產品目標。如，該產品是一款專注于xxx的平臺，A業務解決用戶xxx的問題，B業務解決運營xxx的問題。
個人認為，PRD中業務需求粒度不宜過細，畢竟PRD是偏向于可量化指標，以指導設計為主。但有的時候，產品MRD、PRD會合并成同一個文檔。這種情況下，可以在產品描述中，展開MRD相關內容，如市場分析，用戶分析，競品分析，可行性結論等。
概要功能列表：列出文檔涉及的功能列表清單
- 需求編號常見于大型后臺系統，便于查找。
- 需求分析可以描述該需求內因，外因，kano等級，緊急程度等，便于快速了解。
- 優先級指導先后順序，可用與火車頭發布模式。
我見過很多需求文檔中，優先級設定沒有規則。我個人優先級順序原則是:
- 產品可用性的需求
- 產品用戶體驗性需求
- 產品擴展性需求
- 產品生態需求
產品結構圖
幫助了解產品功能和總體形態的概貌。
全局功能結構：表達這個產品整體的功能層次和邏輯關系，通常用腦圖來表達。
頁面結構圖：以頁面為基準，描述產品各頁面的層次結構，常用于移動端產品，可用結構圖表達。
利用墨刀等原型工具，可以通過創建頁面工作流快速完成。
業務流程
幫助理解產品的業務關系和流程。
產品用例圖：以不同的用戶或角色為基點，通過用例，表達用戶會使用的功能邊界，常見于后臺系統。
示例來源于網絡
整體流程圖：用于描述某個整體任務時，各模塊之間的配合關系，常見于后臺系統。
示例來源于網絡
全局數據流：用于描述紀錄或表單等信息的流轉關系或層次結構，常用于后臺系統。
示例來源于網絡
根據產品類型，選擇需要的表達模型去構建PRD。
詳細功能需求
這部分大家應該都不陌生，是PRD核心中的核心，用于描述功能的量化指標，是研發部門關注的重點。
對于詳細功能，我把它分為兩種類型，一種是業務功能，一種是報表功能。根據不同的類型，結構有所不同。
業務功能
功能名稱
一般直接使用功能名稱作為標題項，便于生成目錄和在文檔結構圖中快速定位。一個story一個小節
概述：
包含功能的一般性描述，包含以下幾點內容
需求描述：推薦一個一句話描述需求的模版給大家“xxx（角色）在xxx的情況下，通過xxx的方式，達到xxx的目的”。
業務場景：描述用戶的使用場景，可以用擬人化的語言去表達，如：“小王到達A寫字樓后，停車場管理員告知車位已滿，小王掃掃描車位二維碼，尋找附近的空閑停車場?！?/p>
參與者：表述此功能具體使用人有哪些，如某功能是管理員使用還是員工使用。
業務流程
詳細描述次業務涉及的主要事件流程，可通過流程圖輔助說明
- 前置條件：在開始前，系統可檢測的有意義的條件。如：意見反饋查詢功能中，用戶已提交意見反饋
- 觸發事件：觸發次系統功能的事件。如：用戶點擊、收到通知
- 基本事件流：常規，正常情況下的預期事件流。如：1、點擊xxx進入頁面，2、輸入xxx，3、選擇xxx，4、點擊確定保存xxx。可以通過流程圖輔助說明。
- 擴展事件流：備選，可選事件流。如：1、可通過點擊｛導出｝，進入導出流程。
- 異常事件流：異常情況下事件流。如：空狀態下，服務異常時的事件流。
- 后置條件：在結束后，系統可檢測的有意義的條件。如：1、保存后，界面數據更新。
相關功能
與本功能相關，但較復雜，難以一起表達時，拆分到細分場景后所關聯的功能?？梢悦枋龀鏊鼈冎苯拥妮斎胼敵鲫P系。
界面原型
原型截圖或者鏈接至原型文檔。
另外，有必要時，需要說明界面中數據項的詳細描述
業務規則
針對此功能或某個數據相的業務規則描述，如果在業務流程中描述過，不需要重復描述。
例如：錢包余額不足時，可轉為刷銀行卡支付。
設計約束
描述需要設計、開發特別注意的事項。如：沒有說明的抽象框架設計；可兼容某些特性；不可用狀態時的顯示要求。
如果是公共性的約束，可以通過全局說明，來闡述通用約束。如：對話框樣式，加載樣式等
驗收標準
描述產品驗收時要滿足的內容，是測試人員重點關注事項。
原則上優先保證正常流下的業務結果正確，異常邊界不報錯，提示明確即可。
如：能夠注冊成功，失敗原因提示正確。
報表功能
功能名稱
一般直接使用報表名稱作為標題項，便于生成目錄和在文檔結構圖中快速定位。如：某某報表，編寫時一個報表一個小節。
概述
因報表一般情況下的用戶是管理者，因此報表類功能概述主要便于理解業務場景和管理者意圖和目的
- 目的：管理者因為什么需要查看此報表
- 使用部門／職位：用于理解使用者的職責，包括地理級別，如：xx財務經理崗位，省級/市級。
- 相關場景與評率：大概多久查一次，緯度有多大。
報表內容
詳細描述報表各項數據的來源和計算規則。
- 數據來源：該數據項的基于哪些數據生成。如：消費金額統計，來源于xx訂單紀錄
- 計算規則：該數據的統計公式。如：消費金額統計，xx訂單中“實收”的累加總額。
界面原型
報表展示原型。個人建議報表原型最好模擬一些真實數據和用戶確認最終效果。
報表框架
描述報表模塊的通用框架需求，如：打印，打印預覽，導出，總計，排序，默認緯度，篩選條件，分頁，是否支持動態報表模版等
設計約束、驗收標準
與業務功能相同，這里不再重復說明。
數據字典
列出有關功能的數據元素，或信息結構。若原型部分已經描述過，可以省略。
【未完待續】
相關閱讀
作者：小星星，8年互聯網工作經驗，5年技術，3年產品。
本文由 @小星星 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
對于我這個業務出身的產品 ，搞懂這篇就費力了，日常工作涉及不到這個層面，我把功能邏輯 結構 業務流程 原型弄給開發測試就夠用了
軟件工程專業出身，現在做產品助理，我感覺作者寫的很像我寫的畢業論文，涵蓋了很多面，產品出的prd實際上可能用不到這么多（至少我們公司是這樣的哈）。我們是給內部人員看的，一般都是原型圖，流程圖、詳細的業務流程。差不多就這些。
看到卷二直接給我看懵逼了
大佬，你發文兩年之后才看到。小白進來很懵，所以您能不能大致說一下這份prd使用的是什么樣的產品？什么行業、多大體量、什么端，謝謝啦~看的我有點懷疑自己能不能入行成功了??
大佬您這寫的是前端的還是后端的？注明一下嗎？完全兩種寫法啊。大佬
大佬，既然是開發出身。為毛角色分析中的用力圖畫的四不像，及不像是用力圖也不像流程圖？用力圖中的“include”“extend”“generalization”請講清楚啊？prd中沒有沒發現你注明狀態圖嗎？每條數據流或者操作沒有狀態以及狀態的枚舉值？prd雖然每個產品有自己的風格，但是四大要素要講清楚吧？“角色””功能”“流程”“狀態”“原型”都不少吧？如果涉及到兩個系統的交互，是不是要添加個時序圖把？
說實話，內容太多研發，交互都不樂意看
如果是外包出去做，有些是必要的，所以還是得看你的團隊情況，輸出自己的模板，不要生搬硬套
覺得非常好，樓主有沒有示范的PRD文檔范本？
不錯，就是產品工作量巨大….有一些可寫可不寫的太多
應該分類模板來規約，大概可以這么定義：
1.手機APP、小程序，H5適用，最簡化模板
2.后臺、PC客戶端適用，中等模板
3.大型產品適用，完整版模板
大佬，能加加我嗎？我想求教一下
?? 可以加我微信hjxdxcool
大神可以加微信交流下嗎
收藏+贊，表示剛接觸prd一臉懵逼，不過自己實際寫完之后在來看這個還是很有啟發的