編輯導語：PRD文檔撰寫恐怕是產品經理必備技能之一。那么，產品小白在入手撰寫PRD文檔時可能會有哪些混淆之處？如何撰寫才可以做到完整且便于梳理呢？本篇文章里，作者就列出了撰寫PRD文檔的幾點注意事項，相信會對初入行的你有所幫助。

都說產品經理有3大文檔：BRD、MRD、PRD。日常工作中很多產品早已由領導層定好了方向，所以BRD和MRD的編寫機會較少，更常用的是在產品細化階段所用到的PRD。

PRD在項目中起什么作用？什么才是好的PRD？PRD要如何編寫？本文將依次回答相應問題，如有錯漏還請指教。

一、PRD作用：要你有什么用？

PRD是將產品需求和對應需求解決方案一起呈現的文檔。文檔面向項目相關的多方角色，在項目推進中承擔了重要作用，比如：

1. 產品：根據PRD進行方案宣講，并作為最終檢驗產品實現程度的依據；
2. 設計：根據PRD的原型作為UI設計參考；
3. 開發：根據PRD的系統規則等內容作為研發依據；
4. 測試：根據PRD的規則來編寫用例及測試。

根據需求的覆蓋情況也會有其他角色參與，如運營、商務、財務等。不管面向誰，最終目的都是為了讓團隊成員能夠理解業務，在產品研發過程中得到更好地執行。

二、PRD要求：想要我怎樣？

為了PRD更好地發揮作用，編寫文檔時需要清晰、完整且容易閱讀的方式將復雜抽象的解決方案呈現出來。怎么才能達到這樣的效果呢？文檔起碼需要符合以下要求：

• 場景完整：需要考慮需求相關的各業務場景，尤其是特殊場景的應對機制。避免場景缺失造成方案漏洞。
• 框架清晰：提供系統架構、業務模型、功能結構、系統流程等系列框架，幫助成員從全局層面了解系統概況。
• 邏輯自洽：系統操作涵蓋業務的正向和逆向流程、主流程和分支流程，形成系統操作閉環且不沖突。
• 規則簡明：對系統全局說明、功能模塊、非功能需求等各項規則進行描述，編寫需通俗且完整。
• 設計友好：系統頁面的布局、導航、交互、文案等交互動作，設計需要符合尼爾森可用性原則。

結合具體情況，PRD編寫時也會存在其他要求。比如非功能性要求（數據指標需求、運營需求……），也要做到對要求的定義明確無異議。

三、PRD編寫：注意你的尺度！

知道了PRD的要求，編寫時可以向要求靠攏。但是要求只能作為指導思想，卻沒有告訴我們具體怎么編寫，你可能還有這些疑問。

1. PRD要用什么形式呈現？

PRD常見形式有2種——word和原型。2種形式各有優劣，比如word版的目錄讓人更容易總覽全局；原型版在功能需求描述時表現更靈活。

采用那種方式要先看公司制度，如有相應規范直接執行即可（規范也可以調整），如果公司沒有要求，則產品經理經過和團隊溝通，采用大家認可的、更方便表達和閱讀的方式即可。

2. PRD要寫到什么顆粒度？

寫過PRD的同學應該都有過這個疑問。尤其是對規則的描述，寫粗了怕有遺漏，寫細了怕沒人看。除了描述上精簡用詞，還能從規則提煉和原型設計上進行把控。

1. 規則提煉：對約定俗成的規則、可復用的規則的通過“全局說明”進行描述。如手勢操作、輸入框定義及限制等。
2. 原型設計：輸出的原型不要有高保真原型，耗時且影響UI發揮；不要有復雜交互，不利于快速識別，可在備注中說明；不要過度設計……

3. PRD由哪些部分組成？

對過往項目的PRD常用組成部分進行總結，從通用、概要、詳細等部分來拆解，僅供參考。每份PRD的具體組成需要項目結合實際情況進行增刪。

• 通用部分：名稱、目錄、更新記錄；
• 概要部分：項目背景、預期收益、方案概述、項目范圍、項目風險；
• 詳細部分：產品框架、全局說明、原型頁面、功能需求、非功能需求 。

四、PRD組成：請問你完整嗎？

終于到了編寫環節！PRD制作是產品經理的基礎工作之一，能夠直觀反映產品經理的底層專業能力是否扎實?，F在知道了PRD的組成，接下來以原型版為例具體說說各部分如何編寫。

1. 通用部分

1）文檔名稱

文檔名稱是為了能區分不同產品和版本。常規命名方式是產品名稱+版本號。這里“版本號”的命名每個公司都不一樣，可以用V1.0或日期作為版本號。能識別并快速區分即可。

如：XX車輛租賃管理系統V1.0；XX車輛租賃管理系統-210504。

2）文檔目錄

一般word形式的PRD會配有文檔目錄，讓閱讀者更直觀的了解全局。使用原型版本也可以做到類似的效果，可以單獨用頁面定義為“目錄”，將word版本的內容放進去，也可以通過對原型頁面的規則命名達到此效果。如下圖（部分頁面做了隱藏）。

3）更新記錄

每次PRD的更新一定要進行記錄，幫助閱讀者了解每次更新的內容。更新記錄一般以表格形式呈現，主要字段包含：更新時間、變更屬性（新增、刪除、修改）、更新內容、更新人員。

2. 概要部分

1）項目背景

背景描述是為了讓閱讀者了解項目或需求的來源和具體情景。

背景包含了業務概況、業務流程、當前問題、整體解決思路等相關內容。相應內容在用戶調研和編寫整體解決方案時都會涉及，可直接使用。編寫方法詳見《B端產品設計：整體方案長這樣？》。

2）預期收益

產品研發是公司商業行為的延伸，一定會有商業目標（預期收益）。定制化產品是為了實現客戶對項目的目標期望（從乙方角度，客戶驗收通過即可），自研產品的預期收益則不能簡單粗暴的直接用業務收益來定。

對于B端自研產品的預期收益制定需要符合SMRAT原則，可以考量功能使用率、客戶滿意度等。

3）方案概述

方案概述是為了讓閱讀者從全局層面了解方案設計的思路，不至于直接陷入細節中。

什么是方案概述呢？基于整體解決思路進行拓展，針對痛點問題描述產品的核心功能模塊、技術實現方案、運營支持方案等內容。

4）項目范圍

系統不可能解決所有問題，所以會有邊界。

項目范圍是指產品所涉及的業務范圍、所關聯的系統等。

項目實施前需要及時和項目相關方（干系人）確定項目的范圍、實施時間、消耗資源（成本），避免關鍵信息溝通不暢導致的項目風險。

5）項目風險

風險是任何事項都不能忽視的問題。提前預設風險項及解決方案，從而降低失控概率。項目中存在哪些風險項呢？

• 流程：沒有明確的規范流程；進度更新不及時；任務匯報占用資源過多（人員、時間）……
• 計劃：重要事項遺漏；用時評估不合理；任務分配不合理；計劃沒有預留緩沖時間……
• 人員：人員不足；新人員的適應成本；任務和人員技能的不匹配……
• 溝通：信息傳遞機制不到位導致溝通效率低（傳遞方式、觸發傳遞條件、指定對接人）……
• 需求：需求變更；變更導致的工作調整（項目計劃、設計、開發、測試）……
• 技術：開發環境不穩定；技術難點評估不足；開發和測試用時評估不準；三方系統對接進度延期……
• 其他：服務器沒到位；市場及政策問題……

3. 詳細部分

1）產品框架

產品框架是系列組成圖表組成，為了閱讀者更深刻的理解產品在組成和結構。包含以下：

• 系統架構圖：通過不同層級開展現系統的功能模塊，表達功能層面的概況。
• 功能結構圖：系統結構的拆解，是一級菜單>二級菜單>具體頁面>操作項的細化。再細化到字段，就成了信息架構圖。
• 操作流程圖：用戶使用系統時如何通過系列操作完成對應任務的過程。
• 狀態機圖：描述各關鍵節點的狀態如何觸發和流轉。如訂單狀態的變化。

以下是過往項目的示例，部分內容做了簡化。如下圖。

圖：系統架構圖

圖：功能結構圖

圖：系統操作流程圖

圖：狀態機圖

2）全局說明

針對全局通用的術語、縮略語、交互、系統規則、異常情況等相關內容，可以在全局說明中統一說明。避免在文檔中反復出現，導致文檔臃腫，造成閱讀困難。

比如：輸入框定義、類型、數字限制等，分頁規則，各類型彈窗交互說明等。

異常情況則包含了斷網、誤操作、數據丟失等情況，需要描述對應情況下如何處理，也可以寫在具體功能需求描述中。

3）原型頁面

原型是對最終產品各頁面上內容的呈現，闡述了用戶與產品之間交互過程。通過產品架構可以得出需要設計的頁面和頁面元素。關于原型工具選擇、配色選擇、頁面類型、交互注意事項等內容詳見上一篇《B端產品設計：拆個“詳細設計”給你看》。

原型頁面通常和規則一起進行呈現，頁面旁邊是規則備注。

4）功能需求

針對每個頁面、彈窗進行詳細的功能描述，將功能邏輯、字段規則等信息描述清楚。同時盡量采用分段的陳述式描述，避免大段論述型描述。更詳細的內容新開文章介紹。

圖：原型頁面+規則備注

5）非功能需求

除了功能需求的描述，千萬不要忘了非功能性需求。非功能性需求有很多種，也會涉及多個相關方，要結合具體項目具體需要進行設計。常規比如性能需求、運營需求、數據統計需求等。

• 性能需求：性能需求需要考慮用戶體驗和資源投入成本，比如響應時間、最大并發量、兼容性需求……
• 運營計劃：產品配套的運營推廣計劃，設計運營方，產品設計時需要確認并記錄。
• 數據統計：可根據產品需求進行數據埋點要求設計，進行埋點監控，如按鈕、頁面、事件等?？梢宰约郝顸c，可以使用市場成熟的數據采集軟件。

以上。

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議