對產品經理來說，必備的一項技能就是寫出邏輯清晰可以實施的PRD。本文作者就從why，what，how三個層面對PRD文檔撰寫展開了分析，供大家參考學習。

上一篇文章已經詳細講解了產品原型的保真度區別，原型設計的注意要點，規范標準，本篇文章將針對PRD文檔撰寫的why，what，how三個層面進行分析。

01 寫PRD的目的

產品需求文檔，即Product Requirement Documen，PRD的主要使用對象有：開發、測試、項目經理、設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；項目經理可以根據PRD拆分工作包，并分配開發人員；設計師可以通過PRD來設計交互細節。

PRD文檔是將產品項目由“概念化”階段推進到“圖紙化”，將需求落實到可開發的。PRD文檔在產品項目中是一個“承上啟下”的作用，“向上”是對MRD內容的繼承和發展，“向下”是要把MRD中的內容技術化，側重的是對產品產品功能和性能（即“產品需求”）的說明，相對于MRD中的同樣內容，要更加詳細，并進行量化。

02 PRD撰寫的前提條件

進行了需求收集與分析，構建了系統架構，繪制了功能結構圖、信息結構圖、產品結構圖，2大流程圖（業務、頁面流程圖）以及所有頁面的原型稿、交互稿。完成這些部分之后，對以上部分進行有機的整合，撰寫PRD文檔。

03 PRD內容

3.1 文檔編寫記錄

記錄文檔創建，修改的情況，文檔的編寫狀態，編寫人

示例：

3.2 文檔修訂記錄

記錄每次修改的修改內容，更詳細的進行記錄每次修改的情況，對修改情況做概要性的描述，使查看人能夠清晰的感知修訂情況

示例：

3.3 目錄

根據PRD文檔的章節自動生成生成，如果有變化進行更新整個目錄的更新即可

示例：

3.4 概述

3.4.1 背景介紹

簡要說明產品/項目需求產生的背景，要達到的目的和需要實現的功能

示例：

通過建立招商加盟平臺的商戶管理系統，商戶（招商公司）能夠在商戶后臺直接發布項目、文章，進行自有項目的推廣。商戶（招商公司）能夠在商戶后臺支付會員、廣告宣傳、站外文章發布等增值服務費用?？梢越哟齺碜稍冊L問的用戶，并進行交談，記錄用戶線索，形成用戶檔案。

商戶管理系統同時能為商戶提供數據分析功能，對在該商家的訪問、咨詢、成交用戶進行分析，對商戶發布文章的宣傳效果，廣告投放效果進行綜合分析，為商家的進一步業務開拓提供決策依據。

3.4.2 涉及范圍

描述本次需求，主要涉及到公司內部的哪些平臺，并簡要描述各平臺應該做哪些事情

示例：

3.4.3 閱讀對象

描述本文檔的的閱讀對象有哪些，一般包含：公司業務總負責人、各平級部門經理、產品經理、UI設計師、研發工程師、測試工程師等與本項目相關的所有人員。

3.4.4 名詞解釋

對項目或者行業的專業詞匯的解釋，對于較為獨特的行業，或者專有名詞的，復雜的系統，一定要進行名詞解釋。名詞解釋的目的：所有成員中達成認知的一致，防止一個事物多種命名的情況產生，提高信息的傳遞效率，消除歧義。

3.5 結構圖

產品相關結構圖一般包含3種：功能結構圖、信息結構圖、產品結構圖

3.5.1 功能結構圖

定義：?功能結構圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖。

作用：?產品設計時，輔助思路梳理，避免功能概念模糊、缺失。

繪制功能結構時，盡量避免信息結構要素出現的可能性，形容一個功能點時建議多采用“動詞+名詞”的語言描述形式 。

示例：

3.5.2 信息結構圖

定義：指脫離產品的實際頁面，將產品的數據抽象出來，組合分類的圖表。

作用：幫助PM梳理復雜內容的信息組成，避免信息內容在展示過程中出現遺漏、混亂、重復；

作為開發工程師建立數據庫的參考依據；信息結構圖的繪制通常晚于功能結構圖，往往是在產品設計階段的概念化過程中，在產品功能框架已確定、功能結構已完善好的情況下才對產品信息結構進行分析設計。

示例：

3.5.3 產品結構圖

定義：?產品結構圖是綜合展示產品信息和功能邏輯的圖表??？梢岳斫鉃楫a品結構圖是對產品原型的簡化表達，產品結構圖就是通過信息架構設計，將功能和信息以一種合理自然的邏輯，把功能結構圖和信息結構圖中的內容放入產品中的每一個頁面的結果。

示例：

一般而言，直接采用產品結構圖，對于概要描述，根據情況使用功能結構圖，使用xmind制作產品功能結構圖，并對產品功能進行簡要描述。

3.5.4 產品功能概要

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

示例：

3.6 核心業務流程

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

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

可以采用的思考方法：

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

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

3.6.1 核心業務流程

跨職能的泳道圖——泳道圖中需將業務數據流所涉及的所有業務平臺加入到泳道中，同時需區分正常流程和異常流程。

示例：

業務流程描述：

用文字描述上述流程圖中的所有流程，用以作為流程的補充說明，注意，流程中的每一步需以單獨的數字序號進行描述。

示例：

優惠券發放、使用、核銷流程

（1）優惠活動創建

1. 優惠活動由平臺設置。
2. 平臺創建優惠活動，費用由平臺、設備提供方、或其它方承擔，具體承擔方由運營進行設置之前與各方溝通確認，并在設置的之時進行確定。
3. 此處活動的設置，主要設置基本信息，如活動的優惠類型（滿減、立減、折扣類型可適當減少，比如第一期只用滿減），針對什么商品類別或是單個商品，針對區域店鋪或者單個店鋪。

（2）優惠券發放

1. 從優惠活動中選擇活動，設置優惠投放方案，如發放時間，有效期，針對門店，針對用戶（新用戶or老用戶），自動發放還是用戶手動領取
2. 設置投放方案后是否立即啟用，如果啟用，則在設置的投放時間向用戶投放
3. 不支持正在投放的優惠券臨時修改，只能停止作廢，后臺作廢之后，用戶端不管是否還在有效期內，均不能領取及使用
4. 正在使用的優惠券，優惠活動原始模板不能更改，如要改變，需單獨創建。

（3）領取使用

1. 如果是系統自動發放的優惠券，用戶不需要單獨進行領取，優惠券自動領取，在用戶端優惠券中心可以看到
2. 如果需要用戶領取的，用戶可在領券中心進行領取
3. 用戶在領取優惠券之后，升降柜的優惠券使用可讓用戶自己選擇，雙開門柜為拿貨之后自動結算，則自動選擇優惠券使用，以優惠最大的券為準。

（4）核銷結算

1. 用戶使用優惠券購買商品之后，如果用戶發生退款，則優惠券不退會，且不可再使用（即優惠券只能使用一次）
2. 如果訂單中包含多個商品，均有使用優惠券，如果退款退貨只退其中一部分，則優惠券也只退其中一部分，按比例進行攤薄
3. 進入清分結算的訂單，有使用優惠券時，則在清分中按實際支付進行清分，并標注使用優惠券
4. 優惠券不進入清分，優惠券只進行費用承擔，但使用該優惠券的訂單結算完成后，該筆優惠券的費用承擔狀態為完成。

備注：

1. 優惠券采用創建與發放分開的形式，創建為創建優惠活動，不配置具體的發送方案
2. 用戶領取優惠券后，在購買商品時，進行金額的抵扣（用戶級別不一，則抵扣金額和券的類別有差異）

系統異常處理流程：

主要描述跨系統、角色間的業務流轉方面的異常處理邏輯。還有其它的一些通用異常處理：

1. 獲取地理位置權限失敗
2. 發送通知權限獲取失敗
3. 網絡情況

優惠券流程示例：

1. 優惠券發放錯誤，停止活動，則已發放的優惠券用戶不能再使用，優惠券失效
2. 優惠券過期失效，不能再使用，并標記已過期失效，并給予提示
3. 退款訂單中已使用的優惠券，不再恢復到可使用狀態（即便未過期），直接作廢
4. 其它

3.7 產品界面級功能及交互需求說明

根據產品原型上的頁面結構，構建功能需求說明樹。

示例：

3.7.1 功能一（界面）

粘貼產品功能界面，并對產品功能界面的功能、交互進行描述

示例：

使用流程：

以任務流方式，描述用戶在完成該功能時的步驟、業務邏輯。

示例（登錄）：

頁面交互：

各頁面間的交互，互動鏈接關系，以一個功能所涉及的相關頁面為

示例

異常處理：

描述業務發起過程中的異常處理流程。

1. 手機號做位數及類型限制，位數只能11位，只能是數字。
2. 密碼由字母+數字構成，字母區分大小寫，密碼的組合方式為“大寫字母or小寫字母+數字”，如果用戶輸入字符與此規則不匹配，則進行提醒用戶按規范輸入
3. 如果用戶未輸入賬號密碼點擊登錄，手機賬號：提示“手機賬號未填寫”；密碼：提示“密碼未填寫”；賬號與密碼不匹配時，
4. 輸入的賬號未進行注冊，提交檢測在后臺無記錄，提示：用戶賬號不存在
5. 用戶輸入的賬號與密碼不匹配，則提示：用戶名或密碼輸入錯誤

3.8 安全需求

描述項目需要遵循的安全標準及需要進行安全驗證等。驗證包括手機短信、身份信息、銀行信息，信用信息（芝麻信用）所有這些均有第三方接口進行驗證，支付費用即可進行驗證。

3.9 數據監測分析

數據監測

采用數據埋點、數據采集等方法統計用戶行為數據。

第一種方式：自己開發——優點是保密性高，所有數據都在自己的平臺中，但是很費時間，要想做的好，對技術也有一定要求

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

數據分析

第一種方式也是完全自主開發，在早期的時候，數據量不大的時候，可以直接將數據導出進行Excel表的分析，

第二種方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在選擇第三方的時候要注意，是否滿足企業要求（當下及后期），是否可以進行私有化部署，后期擴展的靈活性，是否簡單易用，費用。

3.10 系統日志需求

對系統處理業務的操作記錄或者邏輯記錄在日志中，便于后期查找、追溯。

3.11 驗收標準

說明需求驗收上線的評價指標及參與驗收的人員，可以制作驗收單，產品是最終負責人。

3.12 其它產品需求

3.12.1 性能需求

明確產品的性能，知道產品性能上限，隨著業務的發展，清楚改善節點。在早期考慮綜合成本的情況并滿足業務需求的情況下，可以對性能做一定的妥協。

• 并發量：簡單的可以說，同一秒的登錄量，同時在線，訂單并發量最高可以允許多少。比如客服系統，允許同時對話200，也就是允許同時存在200對話通道。
• 圖片加載：圖片加載的時間，頁面跳轉切換的時間，在不同網速下，允許的時長（不同網絡情況下，信號有強弱，可能根本4G、5G信號，或者用戶的卡是3G）

3.12.2 兼容性、適配需求

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

機型——通過各種渠道（talkingdata，友盟）查目前的主流機型，市場占比，根據公司情況，選擇占比靠前的測試機型，或者采用第三方測試平臺（testin，testbird）

3.13 相關文檔

A、原型地址

XX平臺商戶后臺墨刀地址（密碼XXX）：

XX平臺系統后臺墨刀地址（密碼XXX）：

B、消息通知模板

C、其它

商標，軟著，域名、服務器、支付平臺、消息接口、其它需要準備各類平臺賬號及及截止時間節點，部分事項可以并行，部分事項有嚴格的先后順序，在進行計劃安排時，需要作出區分，盡可能縮短時間，不要出現絕大部分人等一個人的情況出現。

04 產品向各方需求文檔內容

4.1 給設計師文檔

思維導圖、流程圖、功能清單、原型圖（含交互）。

4.2 給研發文檔

思維導圖、功能清單、流程圖、原型圖、UI設計圖、PRD文檔、數據埋點文檔

4.3 給運營文檔

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

以上是PRD文檔相關內容，下一篇文章將是——版本命名、驗收規范、發版管理；

#相關閱讀#

產品管理流程及規范2——產品規劃及相關文檔

產品管理流程及規范3：產品原型設計

本文由 @markzou 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。