如何撰寫產品需求文檔（PRD文檔）

在撰寫產品需求文檔之前，首先要做好以下幾點準備工作：

1、  瞭解你的用戶、競爭對手、產品團隊的實力和需要的技術。你需要從用戶、競爭對手、分析師、產品團隊、銷售隊伍、市場、公司職員等收集他們能發現的問題和可能的解決辦法。

2、  確定產品的目的，任何一個好的產品都開始於一個需求。你必須清楚的瞭解這個需求，你的產品如何達到這個需求。產品需求需要確切的指出這個產品發佈的目標，同樣的這個目標也有優先之分。可用性工程師能測算出你的產品對目標用戶的可用性，也測算出可用性問題的嚴重程度，同樣你可以說明沒有重大的可用性問題。這裏的關鍵就是讓每個人都知道產品成功的時候是什麼樣，還有給產品團隊在設計和實施中遇到問題如何進行取捨的指導。

3、  確定用戶原型、用戶目標（用戶意願）和用戶任務（用戶爲達到目標使用產品而需要做的任務）。

4、  定義產品原則，需要開始把你的需求和用戶體驗定義成詳細的要求。同時你仍然會面臨着許多的決定和權衡，爲你的產品標準作出最佳的決定是非常重要的。它將在項目中，在面對衆多問題而作出決定的時候提供指南。

5、  產品原型和檢驗

6、  驗證和質疑，當你認爲你弄懂了你需要解決的問題，現在是時候開始驗證和質疑假設。

做好以上準備工作，就可以開始撰寫產品需求文檔（PRD）了，以下列出產品需求文檔包含的要點：

一、文件命名（編號）

很關鍵，因爲產品迭代過程會有不同的文件版本，一般命名規則“公司名+產品名+PRD+D1.0”（以第一版爲例），這樣命名有利用版本號的迭代，如果是小的產品需求變動可以直接命名爲“公   司名-產品名-PRD-D1.01”，如果涉及到功能需求增加可以命名爲“公司名-產品名-PRD-D1.1”，當出現產品第二版時，可以命名爲“公司名-產品名-PRD-D2.0”。

二、修訂控制頁

一般有這麼幾項：編號、文檔版本、修訂章節、修訂原因、修訂日期、修改人。編號只是爲了給個修改的順序，文檔版本顯示的當前修改的內容是在哪個版本中出現，修訂章節是具體到哪個章節哪個功能模塊的修改，修訂原因說明此功能修改的問題所在。修訂日期以修改當日的日期爲修訂日期，修改人顯示修改內容模塊的人，可能是當前用戶也可能是其它產品人員。

三、目錄

不建議自己去添加一個新的目錄，可以去其它的文檔中拷一個過來，不考慮目錄的內容，等寫完PRD可以再去更新。但建議用Mind manager來整理一下思路。

四、與相關部門討論PRD

產品需求文檔做爲一個承接作用的“載體”，會與技術、運營、財務等人員的溝通，而與這些人員溝通的主題都將會出現在子功能或在細節細化的基本上，需要與相關人員確定“溝通內容”， 寫在與其它部門討論PRD中。

五、概念

即總結，主要包括：名詞說明、產品概述及目標、產品roadmap、產品風險。

名詞說明：名稱、說明。名稱就是對文檔中會出現的比較新的名稱，說明則是對這些名稱進行解釋。

產品概述及目標：解釋說明該產品是幹什麼的，爲什麼需要這樣的產品。同時產品想要達到什麼樣的目標。產品概述及目標就是對產品核心功能講解，同時希望可以達到的期望。

產品roadmap：產品分期目標，階段描述，以及時間點的確定，產品是個不斷演進的過程，很多時間一期產品只完成了產品70%的功能，二期纔會繼續去完善剩下的30%，同時有可能會推翻了重新推出第二版。產品roadmap並不及着全部規劃好所有的階段目標，而是更多的通過維護來保持產品的更新和迭代。

產品風險：描述產品可能存在的風險，比如商務談判的風險，外部合作的風險，不當使用的風險等等。風險級別爲高中低。

六、使用者需求

一般只有需求描述，主要包括以下幾項：目標客戶、需求描述、場景描述、優先級。

目標客戶：即爲產品的最終用戶，確定產品的最終使用者。

需求描述：是對目標客戶的需求描述，表達用戶最需要的是什麼，找到用戶的最根本需求。

場景描述，產品在哪種情況下會被用戶使用，就是用戶場景模擬。

優先級：是指用戶對於當前產品功能需求的優先級，哪些是用戶最想要的功能優先級則排前。

七、可選方案

列出所有可以選擇的達到該產品目標的方案要點（主要思路），給各方案適當的評價，並推薦最優方案。你在做這個產品規劃時一定有很多的備選方案，別放棄這些方案，永遠沒有過時的idea，只有最適合時機的idea。所以可以寫出幾個可選方案，或許是你下期產品改版一個方向。

八、效益成本分析

一般的效益成本分析包括三個方面：效益預測、產品技術中心成本、非產品技術中心支持成本。

效益預測：是指提供在各種產品環境中的效益預測，並標明主要的變量及假設，最好能包含現在和過去的效益數據。如網站的PV值，軟件的使用數都是效益預測數據。

產品技術中心成本：是指設計及部署此產品的產品技術中心所需的資源需求，包括人力成本，軟硬件支出等。很大時候這份成本需要由項目經理來協助，需要有什麼樣的人才加入產品中需與人力協助。

非產品技術中心支持成本：產品不是隻有產品組完成的，同樣需要其它部門的配合與協助。比如：需要客服部投入多少的資源用於該產品的服務，需要運營部投入多少的資源運營該產品。

九、功能需求

需求一般是由四部分組成，功能總覽、功能詳情、整合需求、BETA測試需求。

功能總覽：一般包括二個部分，一個是流程圖，一個是功能表。流程圖是對產品的整體走向的流程的規劃，流程圖是用來對產品整體功能的梳理。所以在做產品前建議所有的產品經理先梳理一下產品流程。功能表是將流程圖文字化，同時將列出產品的功能點。

功能詳情：這是所有的產品功能的描述和規劃。包括以下內容：

簡要說明：告訴此功能主要幹什麼的。

業務規則：每上產品在使用時都有自己的規則，而產品的業務規則則是將產品的流程細化。個人建議將這個功能的業務規則，包括一些細節，如排版形式、日期顯示方式全定好，這樣方便其它人員的溝通和理解。

界面原型：產品經理在這時做的原型界面只是顯示的框架，別細化，這樣會給交互和UI造成錯覺。只需做一個簡單的界面即可，更多的時候只是個框架圖。

執行者：產品使用者。前置條件：具體的操作。

後置條件：操作後的展示。在UC（user case）中後置條件又是另一種情況，所以對於建議在PRD中的前置條件和後置條件結果合起來。

主流程：把主流放在最後是有道理的，結合上面所說的，做出主流程說明。將此功能的流程走向做個分點說明。

整合需求：利用公司現有的資源或外部資源（合作公司等）實現產品功能需求的整合。實現功能貫穿的同時，更多的如何在新產品上實現功能的拓展來輔助核心功能。

BETA測試需求：很多產品都有BETA版本放出，爲了就是收求意見和一些性能測試。這部份內容不是必須的，但現在很多產品已經開始先推出BETA版本再推出正式版，當然也可以通過升級來解決。所以BETA測試需求並不是一定需要的。如果有BETA測試需求，則需寫出BETA版測試的要求和期望達到的目標要求。

十、非功能性需求

一般包括以下幾個部分：產品營銷需求、規則變更需求、產品服務需求、法務需求、財務需求、幫助需求、安全性需求等。

十一、上、下線需求

上線時限需求：此產品預定上線日期？上線日期有無任何特殊依據或規定？

下線需求（活動類需求必須明確下線時間）：此產品預定下線日期？下線日期有無任何特殊依據或規定？

十二、運營計劃說明

產品的後續運營計劃。包括與運營部的協作運營。更多的是給產品經理如何讓更多的產品功能展示給用戶，產品經理是核心需求的把握者，參與到產品整體運營計劃顯得特別的重要。

以上僅爲PM提供一些參考，產品需求文檔描繪出公司將要創造的產品，影響着公司產品團隊的成果，公司的銷售額、市場、客戶滿意程度，它需要清楚簡明的表達出產品的目的、效果，功能，表現。產品開發團隊將使用這份文檔開發出產品並檢驗，所以PRD需要提供足夠的信息。一份優秀的產品需求文檔不一定會作出優秀的產品，但是無疑的沒有一份的好的產品需求文檔就更難作出好的產品！