PRD（Product Requirement Document，產品需求文件）模板
PRD（Product Requirement Document，產品需求文件），
這對於任何一個產品經理來說都不會陌生的一個文件，
一個PRD是衡量一個產品經理整體思維的標準，
一個PRD可以看出一個產品經理在某個領域的專業性，
同時也可以反應出一個產品經理的整體產品思維。
產品經理的整體思維體現在：
1、提煉核心需求
2、思考滿足核心需求的方式
3、評估方式優劣選定方案
4、思考功能概要
5、思考支撐功能和關聯功能
6、細化設計功能
7、子功能（功能間迭代）
PRD其實就是將以上的思維整體走向寫出來，
同時將產品的思想提煉出來，用文字表示給開發者，給UI、給視覺、給老闆……
PRD給的是一種思想，將產品的整體思想和核心需求灌輸給產品的相關人員，
都說PRD是個承上啟下的功能，因為上接MRD，下對MRD進行技術性的描述。
網上已經有太多網際網路公司的PRD文件，
淘寶、百度、騰訊等這類大型網際網路公司都有自己的PRD規範，
適合企業的需要的PRD才是真正PRD。
以淘寶的PRD為例，講解一下PRD的主要內容。
1、 檔案命名（編號）
檔案的編號很關鍵，因為產品迭代過程會有不同的檔案版本，
一般命名規則“公司名+產品名+PRD+D1.0”（以第一版為例），
這樣命名有利用版本號的迭代，
如果是小的產品需求變動可以直接命名為“公司名-產品名-PRD-D1.01”，
如果涉及到功能需求增加可以命名為“公司名-產品名-PRD- D1.1”，
當出現產品第二版時，可以命名為“公司名-產品名-PRD-D2.0”。
2、 修訂控制頁
一般有這麼幾項：
編號、文件版本、修訂章節、修訂原因、修訂日期、修改人。
編號：只是為了給個修改的順序，
文件版本：顯示的當前修改的內容是在哪個版本中出現，
修訂章節：是具體到哪個章節哪個功能模組的修改，
修訂原因：說明此功能修改的問題所在。
修訂日期：以修改當日的日期為修訂日期，
修改人：顯示修改內容模組的人，可能是當前使用者也可能是其它產品人員。
3、 目錄
不建議自己去新增一個新的目錄，你可以去其它的文件中拷一個過來，
不考慮目錄的內容，等寫完PRD可以再去更新。
但建議用Mind manager來整理一下思路。
4、 請與以下部門討論PRD
PRD做為一個承接產品的“載體”，會與技術、運營、財務等人員的溝通，
而與這些人員溝通的主題都將會出現在子功能或在細節細化的基本上，
需要與相關人員確定“溝通內容”，這對於產品整體流程將是很重要的。
同時對於產品核心功能的提取也是一個重要環節。
產品經理很重要的一個職能就是溝通。
例與客服中心：客服服務部，
討論的內容：預測客服成本、工作量；討論客服如何支援；
協助評估詐欺/資料竄改風險：欺詐/資料竄改風險、不正使用風險。
這就是要寫在與其它部門討論PRD中的。
一個產品經理需要考慮如何與其它部門之間的溝通合作，
文件很大一部分的功能是提醒你要做的工作，同時不斷補充將要面臨的工作。
5、 概述
概述就是總結，它包括的點有：
名詞說明、
產品概述及目標、
產品roadmap、
產品風險。
名詞說明：名稱、說明。
名稱就是對文件中會出現的比較新的名稱，說明則是對這些名稱進行解釋。
產品概述及目標：解釋說明該產品是幹什麼的，為什麼需要這樣的產品。
同時產品想要達到什麼樣的目標。產品概述及目標就是對產品核心功能講解，
同時希望可以達到的期望。
產品roadmap：產品分期目標，階段描述，以及時間點的確定，
產品是個不斷演進的過程，很多時間一期產品只完成了產品70%的功能，
二期才會繼續去完 善剩下的30%，同時有可能會推翻了重新推出第二版。
產品roadmap並不及著全部規劃好所有的階段目標，
而是更多的通過維護來保持產品的更新和迭代。
產品風險：描述產品可能存在的風險，比如商務談判的風險，外部合作的風險，
不當使用的風險等等。風險級別為高中低。
6、 使用者需求
使用者需求一般只是需求描述。
需求描述有以下幾項內容：
目標客戶、需求描述、場景描述、優先順序。
目標客戶：即為產品的終端使用者，確定產品的最終使用者。
需求描述：是對目標客戶的需求描述，表達使用者最需要的是什麼，找到使用者的最根本需求。
場景描述：產品在哪種情況下會被使用者使用，就是使用者場景模擬。
優先順序：是指使用者對於當前產品功能需求的優先順序，哪些是使用者最想要的功能優先順序則排前。
7、 可選方案
列出所有可以選擇的達到該產品目標的方案要點（主要思路），
給各方案適當的評價，並推薦最優方案。
你在做這個產品規劃時一定有很多的備選方案，別放棄這些方案，
永遠沒有過時的idea，只有最適合時機的idea。
所以可以寫出幾個可選方案，或許是你下期產品改版一個方向。
8、效益成本分析
產品經理是個全才，在這點上得到了體驗。
產品經理得知道財務知識。很大一部分是產品的環境搭建成本和支援人員的成本。
一般的效益成本分析包括三個方面：
效益預測、
產品技術中心成本、
非產品技術中心支援成本。
效益預測：是指提供在各種產品環境中的效益預測，並標明主要的變數及假設，
最好能包含現在和過去的效益資料。
如網站的PV值，軟體的使用數都是效益預測資料。
產品技術中心成本：是指設計及部署此產品的產品技術中心所需的資源需求，
包括人力成本，軟硬體支出等。
很大時候這份成本需要由專案經理來協助，
需要有什麼樣的人才加入產品中需與人力協助。
非產品技術中心支援成本：產品不是隻有產品組完成的，同樣需要其它部門的配合與協助。
比如：需要客服部投入多少的資源用於該產品的服務，
需要運營部投入多少的資源運營該產品。
8、 功能需求
功能需求一般是由四部分組成，
功能總覽、功能詳情、整合需求、BETA測試需求。
8.1 功能總覽：
一般包括二個部分，
一個是流程圖，
一個是功能表。
流程圖：是對產品的整體走向的流程的規劃，流程圖是用來對產品整體功能的梳理。
所以在做產品前建議所有的產品經理先梳理一下產品流程。
功能表：是將流程圖文字化，同時將列出產品的功能點。
8.2 功能詳情
這是所有的產品功能的描述和規劃。
包括以下內容：
簡要說明：告訴此功能主要幹什麼的。
業務規則：每上產品在使用時都有自己的規則，
而產品的業務規則則是將產品的流程細化。
個人建議將這個功能的業務規則，包括一些細節，如排版形式、
日期顯示方式全定好，這樣方便其它人員的溝通和理解。
介面原型：產品經理在這時做的原型介面只是顯示的框架，
別細化，這樣會給互動和UI造成錯覺。
只需做一個簡單的介面即可，更多的時候只是個框架圖。
執行者：產品使用者。
前置條件：具體的操作。
後置條件：操作後的展示。在UC（user case）中後置條件又是另一種情況，
所以對於建議在PRD中的前置條件和後置條件結果合起來。
主流程：把主流放在最後是有道理的，結合上面所說的，做出主流程說明。
將此功能的流程走向做個分點說明。
8.3 整合需求
產品經理很重要的一個能力就是體現在產品整合能力上，
利用公司現有的資源或外部資源（合作公司等）實現產品功能需求的整合。
實現功能貫穿的同時，更多的如何在新產品上實現功能的拓展來輔助核心功能。
8.4 BETA測試需求
很多產品都有BETA版本放出，為了就是收求意見和一些效能測試。
這部份內容不是必須的，但現在很多產品已經開始先推出BETA版本再推出正式版，
當然也可以通過升級來解決。
所以BETA測試需求並不是一定需要的。
如果有BETA測試需求，則需寫出BETA版測試的要求和期望達到的目標要求。
9、 非功能性需求
都說產品經理是全才，在這點上得到徹底的體現。
很多產品經理在這點上忽視了，但很多方面是用到的，只是在產品過程中弱化了。
一般情況下非功能性需求包括以下幾個部分：
產品營銷需求、
規則變更需求、
產品服務需求、
法務需求、
財務需求、
幫助需求、
安全性需求等。
與其說是全方位的掌握技能，還不如說是溝通，
如何與不同的部門人員之間的溝通，讓更多的人協助產品的正常使用與上線。
10、上、下線需求
上線時限需求：此產品預定上線日期？上線日期有無任何特殊依據或規定？
下線需求（活動類需求必須明確下線時間）：此產品預定下線日期？下線日期有無任何特殊依據或規定？
11、運營計劃
說明產品的後續運營計劃。
包括與運營部的協作運營。
更多的是給產品經理如何讓更多的產品功能展示給使用者，產品經理是核心需求的把握者，
參與到產品整體運營計劃顯得特別的重要。
……
寫PRD並不是產品經理的全部工作，但卻是不可少的一部分，
很大程度上反應了產品經理的思維和產品核心功能把握上，
同時對產品經理溝通、協調、規劃等都得到了一定的驗證，
但每個產品經理的第一職能是會寫一份讓其它人員看得懂的PRD。
模板如下:
公司名-產品名-PRD-版本號
|
日 期 |
制定人 |
稽核人 |
批准人 |
|
2017-02-07 |
xx公司 版權所有
版本記錄
|
版本 |
作者/日期 |
變化內容描述 |
稽核人/日期 |
批准人/日期 |
|
D1.0 |
2017-02-07 |
建立 |
1. 概述
1.1. 名詞說明
|
名稱 |
說明 |
1.2 產品概述及目標
1.3 產品roadmap
1.4 產品風險
|
風險 |
風險級別 |
描述 |
改善策略 |
1.5 問題
2. 使用者需求
2.1 需求描述
|
目標客戶 |
需求描述 |
場景描述 |
優先順序 |
|
1 |
3. 可選方案
|
方案介紹 |
優點 |
缺點 |
4. 效益成本分析
4.1 效益預測
4.2 產品技術中心成本
4.3 非產品技術中心的支援成本
5. 功能需求
5.1 功能總覽
5.1.1 流程圖
5.1.2 功能表
5.2 功能詳情
5.2.1 簡要說明
5.2.2 業務規則
5.2.3 介面原型
5.2.4 執行者
5.2.5 前置條件
5.2.6 後置條件
5.2.7 主流程
5.3 整合需求
5.4 BETA測試需求
6 非功能需求
6.1 產品營銷需求
6.2 規則變更需求
6.3 產品服務需求
6.4 法務需求
6.5 財務需求
6.6 幫助需求
6.7 安全性需求
7 上下線需求
7.1 上線時限需求
7.2 下線需求
8 運營計劃