編輯導語：PRD文檔撰寫恐怕是產品經理必備技能之一。那麼，產品小白在入手撰寫PRD文檔時可能會有哪些混淆之處？如何撰寫才可以做到完整且便於梳理呢？本篇文章裏，作者就列出了撰寫PRD文檔的幾點注意事項，相信會對初入行的你有所幫助。
都説產品經理有3大文檔：BRD、MRD、PRD。日常工作中很多產品早已由領導層定好了方向，所以BRD和MRD的編寫機會較少，更常用的是在產品細化階段所用到的PRD。
PRD在項目中起什麼作用？什麼才是好的PRD？PRD要如何編寫？本文將依次回答相應問題，如有錯漏還請指教。
一、PRD作用：要你有什麼用？PRD是將產品需求和對應需求解決方案一起呈現的文檔。文檔面向項目相關的多方角色，在項目推進中承擔了重要作用，比如：
- 產品：根據PRD進行方案宣講，並作為最終檢驗產品實現程度的依據；
- 設計：根據PRD的原型作為UI設計參考；
- 開發：根據PRD的系統規則等內容作為研發依據；
- 測試：根據PRD的規則來編寫用例及測試。
根據需求的覆蓋情況也會有其他角色參與，如運營、商務、財務等。不管面向誰，最終目的都是為了讓團隊成員能夠理解業務，在產品研發過程中得到更好地執行。
二、PRD要求：想要我怎樣？為了PRD更好地發揮作用，編寫文檔時需要清晰、完整且容易閲讀的方式將複雜抽象的解決方案呈現出來。怎麼才能達到這樣的效果呢？文檔起碼需要符合以下要求：
- 場景完整：需要考慮需求相關的各業務場景，尤其是特殊場景的應對機制。避免場景缺失造成方案漏洞。
- 框架清晰：提供系統架構、業務模型、功能結構、系統流程等系列框架，幫助成員從全局層面瞭解系統概況。
- 邏輯自洽：系統操作涵蓋業務的正向和逆向流程、主流程和分支流程，形成系統操作閉環且不衝突。
- 規則簡明：對系統全局説明、功能模塊、非功能需求等各項規則進行描述，編寫需通俗且完整。
- 設計友好：系統頁面的佈局、導航、交互、文案等交互動作，設計需要符合尼爾森可用性原則。
結合具體情況，PRD編寫時也會存在其他要求。比如非功能性要求（數據指標需求、運營需求……），也要做到對要求的定義明確無異議。
三、PRD編寫：注意你的尺度！知道了PRD的要求，編寫時可以向要求靠攏。但是要求只能作為指導思想，卻沒有告訴我們具體怎麼編寫，你可能還有這些疑問。
1. PRD要用什麼形式呈現？PRD常見形式有2種——word和原型。2種形式各有優劣，比如word版的目錄讓人更容易總覽全局；原型版在功能需求描述時表現更靈活。
採用那種方式要先看公司制度，如有相應規範直接執行即可（規範也可以調整），如果公司沒有要求，則產品經理經過和團隊溝通，採用大家認可的、更方便表達和閲讀的方式即可。
2. PRD要寫到什麼顆粒度？寫過PRD的同學應該都有過這個疑問。尤其是對規則的描述，寫粗了怕有遺漏，寫細了怕沒人看。除了描述上精簡用詞，還能從規則提煉和原型設計上進行把控。
- 規則提煉：對約定俗成的規則、可複用的規則的通過“全局説明”進行描述。如手勢操作、輸入框定義及限制等。
- 原型設計：輸出的原型不要有高保真原型，耗時且影響UI發揮；不要有複雜交互，不利於快速識別，可在備註中説明；不要過度設計……
對過往項目的PRD常用組成部分進行總結，從通用、概要、詳細等部分來拆解，僅供參考。每份PRD的具體組成需要項目結合實際情況進行增刪。
- 通用部分：名稱、目錄、更新記錄；
- 概要部分：項目背景、預期收益、方案概述、項目範圍、項目風險；
- 詳細部分：產品框架、全局説明、原型頁面、功能需求、非功能需求 。
終於到了編寫環節！PRD製作是產品經理的基礎工作之一，能夠直觀反映產品經理的底層專業能力是否紮實。現在知道了PRD的組成，接下來以原型版為例具體説説各部分如何編寫。
1. 通用部分1）文檔名稱
文檔名稱是為了能區分不同產品和版本。常規命名方式是產品名稱+版本號。這裏“版本號”的命名每個公司都不一樣，可以用V1.0或日期作為版本號。能識別並快速區分即可。
如：XX車輛租賃管理系統V1.0；XX車輛租賃管理系統-210504。
2）文檔目錄
一般word形式的PRD會配有文檔目錄，讓閲讀者更直觀的瞭解全局。使用原型版本也可以做到類似的效果，可以單獨用頁面定義為“目錄”，將word版本的內容放進去，也可以通過對原型頁面的規則命名達到此效果。如下圖（部分頁面做了隱藏）。
3）更新記錄
每次PRD的更新一定要進行記錄，幫助閲讀者瞭解每次更新的內容。更新記錄一般以表格形式呈現，主要字段包含：更新時間、變更屬性（新增、刪除、修改）、更新內容、更新人員。
1）項目背景
背景描述是為了讓閲讀者瞭解項目或需求的來源和具體情景。
背景包含了業務概況、業務流程、當前問題、整體解決思路等相關內容。相應內容在用户調研和編寫整體解決方案時都會涉及，可直接使用。編寫方法詳見《B端產品設計：整體方案長這樣？》。
2）預期收益
產品研發是公司商業行為的延伸，一定會有商業目標（預期收益）。定製化產品是為了實現客户對項目的目標期望（從乙方角度，客户驗收通過即可），自研產品的預期收益則不能簡單粗暴的直接用業務收益來定。
對於B端自研產品的預期收益制定需要符合SMRAT原則，可以考量功能使用率、客户滿意度等。
3）方案概述
方案概述是為了讓閲讀者從全局層面瞭解方案設計的思路，不至於直接陷入細節中。
什麼是方案概述呢？基於整體解決思路進行拓展，針對痛點問題描述產品的核心功能模塊、技術實現方案、運營支持方案等內容。
4）項目範圍
系統不可能解決所有問題，所以會有邊界。
項目範圍是指產品所涉及的業務範圍、所關聯的系統等。
項目實施前需要及時和項目相關方（干係人）確定項目的範圍、實施時間、消耗資源（成本），避免關鍵信息溝通不暢導致的項目風險。
5）項目風險
風險是任何事項都不能忽視的問題。提前預設風險項及解決方案，從而降低失控概率。項目中存在哪些風險項呢？
- 流程：沒有明確的規範流程；進度更新不及時；任務彙報佔用資源過多（人員、時間）……
- 計劃：重要事項遺漏；用時評估不合理；任務分配不合理；計劃沒有預留緩衝時間……
- 人員：人員不足；新人員的適應成本；任務和人員技能的不匹配……
- 溝通：信息傳遞機制不到位導致溝通效率低（傳遞方式、觸發傳遞條件、指定對接人）……
- 需求：需求變更；變更導致的工作調整（項目計劃、設計、開發、測試）……
- 技術：開發環境不穩定；技術難點評估不足；開發和測試用時評估不準；三方系統對接進度延期……
- 其他：服務器沒到位；市場及政策問題……
1）產品框架
產品框架是系列組成圖表組成，為了閲讀者更深刻的理解產品在組成和結構。包含以下：
- 系統架構圖：通過不同層級開展現系統的功能模塊，表達功能層面的概況。
- 功能結構圖：系統結構的拆解，是一級菜單>二級菜單>具體頁面>操作項的細化。再細化到字段，就成了信息架構圖。
- 操作流程圖：用户使用系統時如何通過系列操作完成對應任務的過程。
- 狀態機圖：描述各關鍵節點的狀態如何觸發和流轉。如訂單狀態的變化。
以下是過往項目的示例，部分內容做了簡化。如下圖。
圖：系統架構圖
圖：功能結構圖
圖：系統操作流程圖
圖：狀態機圖
2）全局説明
針對全局通用的術語、縮略語、交互、系統規則、異常情況等相關內容，可以在全局説明中統一説明。避免在文檔中反覆出現，導致文檔臃腫，造成閲讀困難。
比如：輸入框定義、類型、數字限制等，分頁規則，各類型彈窗交互説明等。
異常情況則包含了斷網、誤操作、數據丟失等情況，需要描述對應情況下如何處理，也可以寫在具體功能需求描述中。
3）原型頁面
原型是對最終產品各頁面上內容的呈現，闡述了用户與產品之間交互過程。通過產品架構可以得出需要設計的頁面和頁面元素。關於原型工具選擇、配色選擇、頁面類型、交互注意事項等內容詳見上一篇《B端產品設計：拆個“詳細設計”給你看》。
原型頁面通常和規則一起進行呈現，頁面旁邊是規則備註。
4）功能需求
針對每個頁面、彈窗進行詳細的功能描述，將功能邏輯、字段規則等信息描述清楚。同時儘量採用分段的陳述式描述，避免大段論述型描述。更詳細的內容新開文章介紹。
圖：原型頁面+規則備註
5）非功能需求
除了功能需求的描述，千萬不要忘了非功能性需求。非功能性需求有很多種，也會涉及多個相關方，要結合具體項目具體需要進行設計。常規比如性能需求、運營需求、數據統計需求等。
- 性能需求：性能需求需要考慮用户體驗和資源投入成本，比如響應時間、最大併發量、兼容性需求……
- 運營計劃：產品配套的運營推廣計劃，設計運營方，產品設計時需要確認並記錄。
- 數據統計：可根據產品需求進行數據埋點要求設計，進行埋點監控，如按鈕、頁面、事件等。可以自己埋點，可以使用市場成熟的數據採集軟件。
以上。
本文由 @耳目不染 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議