「干货分享」50人+团队常用的一套PRD模板
寫在前面：個人公眾號：18歲fantasy。歡迎關注。
本模板是筆者所在團隊使用的一套模板，通過一段時間沉淀所得，主要閱讀對象為：研發，公司PMO，運維，運營團隊。側重研發。
筆者團隊簡介：一個項目或產品大概15人左右，多個項目和產品線并行。單個項目團隊主要成員有產品經理（也就是我），1產品助理，1美工，2測試，其他為研發，運維和運營都為職能部門借調。
此模板并非行業通用模板，可選擇性參考。謝謝。
文檔中使用到工具：word2017，axure8，viso2013,。
以下為具體內容，內容去掉了所有正文，添加了說明。文章末尾提供下載。
目錄結構
功能結構圖
文檔結構圖
整個結構由以下部分組成:
1、文檔介紹
主要描述文檔的術語定義，參與本需求確認的相關干系人及確認歷史。
干系人
?
2、產品概述
描述產品背景，產品業務目標，此部分主要面向領導層和pmo以及運營團隊。
3、需求分析
? ? ?1）用戶分析。分析系統面向的用戶及不同的使用場景（也就是告訴都誰來用這個系統）；
? ? ?2）角色分析。分析不同角色具備的系統功能）；
? ? ?3）業務指標。分析系統上線后要達到的業務指標，通常面向運營團隊；
? ? ?4）主要業務流程。描述系統的主要業務流程，用于干系人討論決策；
? ? ?5）需求池分析。分析目前需求整體情況，按需求來源，優先級進行統計闡述(詳細需求引導到需求管理軟件，如TAPD,禪道，我所在團隊目前用TAPD進行需求和進度管理，采用的原因主要是包含功能比較全面：如：需求，迭代，故事墻，wiki，文檔管理等）如下圖（與本文檔無關）：
需求管理軟件
?
6，功能規劃。根據優先級和公司資源規劃每個迭代的所需完成的功能及里程碑事件。
從預期目標上分析系統各迭代需包含的功能和計劃。
(一般將參會人引導到部門需求管理軟件)。文檔中通過腦圖畫出結構講解各個迭代的結構（迭代里面要分析規劃分析），如果軟件需求不多可在此用表格詳細列出需求列表。
4、需求設計
也可叫功能設計，這里正是面向研發，進行一下內容詳細闡述：
1、整體功能和優先級
描述功能設計結構、需求映射關系、優先級。
迭代優先級
2、功能結構圖
功能整體結構，一般用viso畫出。
3.菜單結構圖
列出菜單設計結構。一般用axure原型列出。可根據團隊結構，提供灰度原型或者高保真原型。
菜單設計
3、功能設計
這個章節具體描述各個功能的設計。包含：原型，原型標注、用戶場景及操作流程
功能設計
?
其中：
1）原型標注：這里面我們直接會給出原型的標注，數據說明等。有的大廠這一部分是單獨的標注工具管理，如：pxcook軟件。
2）用戶場景及使用流程：描述此功能的使用場景，用戶操作流程，一般包含和其他功能的交互。實例如下（保密期間去除了實際內容）：
流程圖
?
3、業務規則。這里面要給出業務規則(校驗規則)，如前置條件、輸入規則、超時規則、閾值要求等。
4、接口設計
其實這部分按照規范已經不在屬于PRD的范疇了。但是我們主要想用它來說明和第三方合作伙伴的接口規則。如：調用頻次說明，業務結算規則說明、調用方式說明等，但不包含協議具體內容。
接口設計
?
5、非功能需求
主要包含：
性能需求
1、用戶規模預測分析
分析上線后可能的用戶數和并發數，
在線數和并發量要求（這里列出要求的在線數和并發數支撐指標）。
2、吞吐量（TPS）
每秒鐘要處理的事務數，以及在不同級別的并發下平均響應時間規定。
穩定性需求
要求不宕機的時間，如7*24小、早3：00~完11點。
安全性需求
要求數據傳輸的加密機制。是否采用證書，是否統一認證等。
兼容性需求
分服務端和客戶端，如服務端的操作系統是windows，linux等，客戶端需要兼容的瀏覽器規定。App需要兼容的ios或者android的版本和尺寸。
維護和升級規定
規定系統升級時間、規定升級過程的規范性（如是否可讓用戶感覺到重新登錄等）。
6、項目管理
這里的項目管理不是指項目經理角色所面對的全周期項目管理。主要包含以下部分：
1、進度安排。主要描述從需求發起，到上線各個部門及干系人需要定時輸出的成果。用于從一開始就確定好項目協同的資源。
2、風險和應對措施分析。
本次系統上線或升級可能帶來的風險和應對策略，主要是面向用戶。包含：
風險描述：描述風險具體內容。
規避策略：描述建議通過什么手段規避風險，一般都是投入更多的資源等。
7、附件
主要包含參考的文獻，以及設計規范內容（一般規定UI規范也可單獨成文管理）。
~完~
文檔下載
關注公眾號，回復”p002“,下載完整文檔。
總結
以上是生活随笔為你收集整理的「干货分享」50人+团队常用的一套PRD模板的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 设计文档模板
- 下一篇： 产品经理必备 [Axure组件、PRD模