對產品經理來說，必備的一項技能就是寫出邏輯清晰可以實施的PRD。本文作者就從why，what，how三個層面對PRD文檔撰寫展開了分析，供大家參考學習。
上一篇文章已經詳細講解了產品原型的保真度區別，原型設計的注意要點，規範標準，本篇文章將針對PRD文檔撰寫的why，what，how三個層面進行分析。
產品需求文檔，即Product Requirement Documen，PRD的主要使用對象有：開發、測試、項目經理、設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；項目經理可以根據PRD拆分工作包，並分配開發人員；設計師可以通過PRD來設計交互細節。
PRD文檔是將產品項目由「概念化」階段推進到「圖紙化」，將需求落實到可開發的。PRD文檔在產品項目中是一個「承上啟下」的作用，「向上」是對MRD內容的繼承和發展，「向下」是要把MRD中的內容技術化，側重的是對產品產品功能和性能（即「產品需求」）的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。
進行了需求收集與分析，構建了系統架構，繪製了功能結構圖、信息結構圖、產品結構圖，2大流程圖（業務、頁面流程圖）以及所有頁面的原型稿、交互稿。完成這些部分之後，對以上部分進行有機的整合，撰寫PRD文檔。
記錄文檔創建，修改的情況，文檔的編寫狀態，編寫人
示例：
記錄每次修改的修改內容，更詳細的進行記錄每次修改的情況，對修改情況做概要性的描述，使查看人能夠清晰的感知修訂情況
示例：
根據PRD文檔的章節自動生成生成，如果有變化進行更新整個目錄的更新即可
示例：
3.4.1 背景介紹
簡要說明產品/項目需求產生的背景，要達到的目的和需要實現的功能
示例：
通過建立招商加盟平臺的商戶管理系統，商戶（招商公司）能夠在商戶後臺直接發布項目、文章，進行自有項目的推廣。商戶（招商公司）能夠在商戶後臺支付會員、廣告宣傳、站外文章發布等增值服務費用。可以接待來諮詢訪問的用戶，並進行交談，記錄用戶線索，形成用戶檔案。
商戶管理系統同時能為商戶提供數據分析功能，對在該商家的訪問、諮詢、成交用戶進行分析，對商戶發布文章的宣傳效果，廣告投放效果進行綜合分析，為商家的進一步業務開拓提供決策依據。
3.4.2 涉及範圍
描述本次需求，主要涉及到公司內部的哪些平臺，並簡要描述各平臺應該做哪些事情
示例：
3.4.3 閱讀對象
描述本文檔的的閱讀對象有哪些，一般包含：公司業務總負責人、各平級部門經理、產品經理、UI設計師、研發工程師、測試工程師等與本項目相關的所有人員。
3.4.4 名詞解釋
對項目或者行業的專業詞彙的解釋，對於較為獨特的行業，或者專有名詞的，複雜的系統，一定要進行名詞解釋。名詞解釋的目的：所有成員中達成認知的一致，防止一個事物多種命名的情況產生，提高信息的傳遞效率，消除歧義。
產品相關結構圖一般包含3種：功能結構圖、信息結構圖、產品結構圖
3.5.1 功能結構圖
定義： 功能結構圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖。
作用： 產品設計時，輔助思路梳理，避免功能概念模糊、缺失。
繪製功能結構時，儘量避免信息結構要素出現的可能性，形容一個功能點時建議多採用「動詞+名詞」的語言描述形式 。
示例：
3.5.2 信息結構圖
定義：指脫離產品的實際頁面，將產品的數據抽象出來，組合分類的圖表。
作用：幫助PM梳理複雜內容的信息組成，避免信息內容在展示過程中出現遺漏、混亂、重複；
作為開發工程師建立資料庫的參考依據；信息結構圖的繪製通常晚於功能結構圖，往往是在產品設計階段的概念化過程中，在產品功能框架已確定、功能結構已完善好的情況下才對產品信息結構進行分析設計。
示例：
3.5.3 產品結構圖
定義： 產品結構圖是綜合展示產品信息和功能邏輯的圖表 。可以理解為產品結構圖是對產品原型的簡化表達，產品結構圖就是通過信息架構設計，將功能和信息以一種合理自然的邏輯，把功能結構圖和信息結構圖中的內容放入產品中的每一個頁面的結果。
示例：
一般而言，直接採用產品結構圖，對於概要描述，根據情況使用功能結構圖，使用xmind製作產品功能結構圖，並對產品功能進行簡要描述。
3.5.4 產品功能概要
功能等級基本為三級+描述備註（模塊、功能、子功能或者其它叫法），根據功能結構圖而來，控制好級別，並進一步描述功能的內容和作用，對功能排列優先級，功能是否要進行分期開發，如果需要分期開發，則對應的開發周期需要註明，是否有另外的說明和備註，如果有則可以添加備註，儘量不要使用Excel中批註，很容易遺漏。
示例：
對於本次需求中最核心的業務，採用泳道+文字描述的方式，對核心業務的階段、步驟以及異常情況及判斷進行描述。
在畫業務流程之前，要深入了解核心業務，與相關業務人員進行深入的溝通，確認。確定泳道（即任務），確定產品有哪幾個階段，思考業務在各個階段的形態，如果業務流程涉及多個部門的，需要共同進行溝通探討，並可對部分流程進行優化。思考清楚後開始畫業務流程圖，在畫的過程中也在頭腦中進行梳理，儘可能的不遺漏任何的分支或異常情況。
可以採用的思考方法：
業務流程圖並不是一成不變的，在多次討論會後中可能會有調整和變動。但每次調整或變動都需要進行明確，保證流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，則子流程以及後續很多工作都會導致極大的變動性，也會影響整體項目的進度，特別是在研發已經介入的情況，如果流程還存在不清晰的地方，開發工作也會反覆。
3.6.1 核心業務流程
跨職能的泳道圖——泳道圖中需將業務數據流所涉及的所有業務平臺加入到泳道中，同時需區分正常流程和異常流程。
示例：
業務流程描述：
用文字描述上述流程圖中的所有流程，用以作為流程的補充說明，注意，流程中的每一步需以單獨的數字序號進行描述。
示例：
優惠券發放、使用、核銷流程
（1）優惠活動創建
（2）優惠券發放
（3）領取使用
（4）核銷結算
備註：
系統異常處理流程：
主要描述跨系統、角色間的業務流轉方面的異常處理邏輯。還有其它的一些通用異常處理：
優惠券流程示例：
根據產品原型上的頁面結構，構建功能需求說明樹。
示例：
3.7.1 功能一（界面）
粘貼產品功能界面，並對產品功能界面的功能、交互進行描述
示例：
使用流程：
以任務流方式，描述用戶在完成該功能時的步驟、業務邏輯。
示例（登錄）：
頁面交互：
各頁面間的交互，互動連結關係，以一個功能所涉及的相關頁面為
示例
異常處理：
描述業務發起過程中的異常處理流程。
描述項目需要遵循的安全標準及需要進行安全驗證等。驗證包括手機簡訊、身份信息、銀行信息，信用信息（芝麻信用）所有這些均有第三方接口進行驗證，支付費用即可進行驗證。
數據監測
採用數據埋點、數據採集等方法統計用戶行為數據。
第一種方式：自己開發——優點是保密性高，所有數據都在自己的平臺中，但是很費時間，要想做的好，對技術也有一定要求
第二種方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解決問題，另外growio，百度都有無埋點方式，就是不需要一個個數據點進行單獨的埋點，而是監測所有有數據傳輸，操作行為的點，接入sdk之後，可以自主選擇數據點進行分析。這種方式，不會存在遺漏，靈活度也非常高。
數據分析
第一種方式也是完全自主開發，在早期的時候，數據量不大的時候，可以直接將數據導出進行Excel表的分析，
第二種方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在選擇第三方的時候要注意，是否滿足企業要求（當下及後期），是否可以進行私有化部署，後期擴展的靈活性，是否簡單易用，費用。
對系統處理業務的操作記錄或者邏輯記錄在日誌中，便於後期查找、追溯。
說明需求驗收上線的評價指標及參與驗收的人員，可以製作驗收單，產品是最終負責人。
3.12.1 性能需求
明確產品的性能，知道產品性能上限，隨著業務的發展，清楚改善節點。在早期考慮綜合成本的情況並滿足業務需求的情況下，可以對性能做一定的妥協。
3.12.2 兼容性、適配需求
PC——兼容目前主流的瀏覽器，比如IE8、及Firefox3.5、safari、chrome等主流瀏覽器的主流版本，將相關版本進行羅列，同時考慮H5的跨設備適用性問題（比如官網在pc和手機的查看，看到過有些系統將功能複雜的後臺沒有做適配要在手機查看使用一團糟的情況，功能複雜的後臺基本是不太適合在手機上操作的）。
機型——通過各種渠道（talkingdata，友盟）查目前的主流機型，市場佔比，根據公司情況，選擇佔比靠前的測試機型，或者採用第三方測試平臺（testin，testbird）
A、原型地址
XX平臺商戶後臺墨刀地址（密碼XXX）：
XX平臺系統後臺墨刀地址（密碼XXX）：
B、消息通知模板
C、其它
商標，軟著，域名、伺服器、支付平臺、消息接口、其它需要準備各類平臺帳號及及截止時間節點，部分事項可以並行，部分事項有嚴格的先後順序，在進行計劃安排時，需要作出區分，儘可能縮短時間，不要出現絕大部分人等一個人的情況出現。
思維導圖、流程圖、功能清單、原型圖（含交互）。
思維導圖、功能清單、流程圖、原型圖、UI設計圖、PRD文檔、數據埋點文檔
思維導圖、流程圖、功能清單、PRD文檔、產品使用說明書，上線資料準備清單（上線前需要準備的比如需要錄入的商家信息）。
以上是PRD文檔相關內容，下一篇文章將是——版本命名、驗收規範、發版管理；
產品管理流程及規範2——產品規劃及相關文檔
產品管理流程及規範3：產品原型設計
本文由 @markzou 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。