產品需求文檔
出自 MBA智库百科(https://wiki.mbalib.com/)
產品需求文檔（Product Requirements Document,PRD）
目錄 |
產品需求文檔是將商業需求文檔（BRD）和市場需求文檔（MRD）用更加專業的語言進行描述。該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔。當然，這個定義針對的是一個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標用戶、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等，本文主要討論的是戰術部分。
PRD的主要使用對象有：開發、測試、項目經理、交互設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；項目經理可以根據PRD拆分工作包，並分配開發人員；交互設計師可以通過PRD來設計交互細節。PRD是項目啟動之前，必須要通過評審確定的最重要文檔。
產品需求文檔的要素[1]
1、文檔的命名和編號
文檔的編號和命名很關鍵，每個產品都是經過若幹個迭代才完成的，而每個迭代所完成的產品功能或者升級的需求都可能是不一樣的，因此需要定義清楚該文件屬於產品的哪個迭代，修改了幾個版本。文件命名的方法一般是通過版本號定義，比如簡單的方法是，XX產品V1.0PRD_V2,前面的V1.0是產品迭代的編號，後面的V2 PRD的版本號。稍微詳細點可以定義成，XX產品XXXX需求PRD_V2,即對本次迭代的需求任務做命名，這樣更便於閱讀和記憶。
2、文檔的版本歷史
包括，編號、文檔版本、章節、修改原因、日期、修改人。編號只是為了記錄修改的順序，文檔版本顯示的當前修改的內容屬於文檔的第幾個版本(或第幾次修改，一次修改一般為一個版本)，章節是具體到修改內容屬於的功能模塊，以便閱讀人及時找到修改後的內容，修改原因說明為什麼要修改該需求，讓閱讀者直觀的瞭解原因。日期是指需求文檔修改的時間，修改人是指需求內容的修改者。
3、目錄
不需要自己新建，文檔完成後直接更新模版中的目錄即可。目錄是用來瞭解文檔結構的
4、引言
這部分的內容有：產品概述及目標、產品roadmap、預期讀者、成功的定義標準和判斷、參考資料、名詞說明
產品概述：解釋說明該產品研發的背景以及核心功能。
產品roadmap：為產品規劃的藍圖，每個關鍵階段完成的核心任務。產品研發是個不斷迭代的過程，需要經過若幹個版本的迭代，，對一個功能點做了N個迭代後最終又回歸到了第一個迭代是很常見。產品經理需要做好心理準備。產品roadmap並不需要全部規劃好所有的階段目標，但是對產品未來發展趨勢的一種預估，要達到目標，需要更多的更新和迭代。清晰的呈現產品的roadmap可以幫助產品經理把握產品的全貌，更好的控制研發過程。
預期讀者：文檔的使用對象
成功的定義和判斷標準：旨在說明產品的目標
參考資料：PRD的參考資料
名詞說明：名稱、說明。名稱就是對文檔中會出現的比較新的名稱，說明則是對這些名稱進行解釋。
5、需求概述
需求概述通常包括需求概覽、用戶類與特征、運行環境、設計和實現上的限制、項目計劃、產品風險等等。
需求概覽：分兩部分，一是業務流程圖，對產品整個業務流程的發生過程做圖形化的展示，是對產品整體功能流程的闡釋。二是需求清單，對本次要開發的需求任務做分類，給出簡明扼要的需求描述並標註優先順序。
用戶類與特征：產品的最終用戶，確定產品的最終使用者，並對使用者的角色和操作行為做出說明。
運行環境：該產品上線後的使用環境，比如支持的瀏覽器及其版本，操作系統、資料庫的要求等等，測試人員在看到環境要求後會在測試時重點測試，而最終上線產品時需要把最佳的運營環境告知給用戶。設計和實現上的限制：比如控制項的開發環境、介面的調用方式等等。
項目計劃：對於prd中要開發的內容，給出關鍵里程碑，比如需求評審通過的時間、開發的完成時間、上線時間等等。
產品風險：描述產品可能存在的風險，比如性能瓶頸，沒有解決的問題，用戶不當使用的風險等等。
6.功能需求
功能需求一般是由功能詳情和主流程說明兩大部分。功能詳情是所有的產品功能的描述和規劃。功能詳情包括以下內容：
簡要說明：介紹此功能的用途，包括其來源或背景，能夠解決哪些問題。
場景描述，產品在哪種情況下會被用戶使用，就是用戶場景模擬。這也是產品經理講“好”故事的必備條件。
業務規則：每上產品在開發時都有相應的業務規則，將這些規則清晰的描述出來，讓開發、測試人員能夠直觀的明白該規則，且沒有產生歧義。業務規則必需是完整的、準確的、易懂的。業務規則的描述上如果涉及到頁面交互或者頁面的修改，建議給出頁面的草圖或者頁面截圖在圖上說明要修改的內容。另外也建議對頁面的輸入框、下拉框的內容格式、長度、控制項之間的關聯性做出說明，什麼時候可見，不可見，灰掉或點亮的條件在文檔中都給出說明。方便閱讀者理解業務規則。
界面原型：如前所述，涉及到頁面交互的部分，產品經理需要設計頁面原型。原型設計通常需要產品經理和UI設計師一起來完成。建議的做法是，產品經理可設計一個頁面框架，將該頁面要呈現的欄位及其特征以及頁面要使用的場景向交互設計師解釋清楚。之後交互和視覺設計師完成產品的原型設計。
使用者說明：對產品使用者做出說明，可融入簡要說明中。
前置條件：該需求實現依賴的前提條件。比如，上傳照片時，需要存有圖像文件。
後置條件：操作後引發的後續處理。
主流程：把主流放在最後是有道理的，結合上面所說的，做出主流程說明，對每個功能流程走向分點說明(這是非常重要的)。
看過很多的PRD，文檔中對既沒有前提條件，也沒有後置條件，只對主流程做了說明，但是在描述主流程時卻沒有描寫主流程中每個功能流程的各種走向，只有一個主走向，讓人感覺prd成了操作手冊。事實上，對分支的介紹是非常重要的，開發和測試中提出的各類問題均與對分支的定義不明有關。一個合格的PRD不僅要描述主流程，同時對分支流程所出現的各類問題都要做詳細闡述並給出解決辦法。PRD的特征一定是明確的、全面的闡述需求及各類異常情況的處理而不是等到開發和測試階段發現問題後再給以答案(雖然PRD不可能百分之百的覆蓋所有的可能，但是最大化的思考所有的業務問題是編製PRD時必須遵守的原則)。另外，在描寫功能需求時給出的辦法中不能出現“可能”、“或者”等詞，一定是明確的，唯一的描述。如果有別的方案，建議寫入“可選方案”，在產品構建的早期可選方案可以為功能實現提供更多的選擇，當方案確定後可在文檔中註明本次使用了哪種方案。
推薦一個方法：“用例”，在面向對象的軟體設計模型中，用例是一個被闡述的內容，用例是對功能使用場景的解釋。用例很條理的介紹了每個功能的前置、後置條件，主流程介紹，幫助開發、測試等角色快速的瞭解產品功能。
7、可選方案
列出所有可以選擇的達到該產品目標的方案要點(主要思路)，給各方案適當的評價，並推薦最優方案(在功能需求中描述的)。你在做這個產品規劃時一定有很多的備選方案，別放棄這些方案，永遠沒有過時的idea，只有最適合時機的idea。所以可以寫出幾個可選方案，或許是你下期產品改版一個方向。記住，多思考方案是永不為過的
8、效益成本分析
通過這一點上能看出產品經理必須是個全才，不僅要具備行業知識，還需要有財務知識。一個產品的成本衡量一般包括三個方面：效益預測、產品技術成本和其他成本支出。
效益預測是指所提供的功能在未來能產生的效益，可通過對比以往的產品或者競爭對手的產品來做預估，效益預測的指標，如每個功能點的潛在用戶數、使用頻率，吸引到的新的用戶特征及數量。產品技術成本是指研發設計以及上線後的運營需要的資源需求，包括人力，軟硬體(帶寬、伺服器、機房)支出。當有項目經理時可以由項目經理來協調這部分需求，如果沒有項目經理，產品經理得挑頭了，召集開發經理去找運維等部門落實此事。其他的成本還包括支持成本，比如上線後的運營資源投入、市場推廣投入以及客服服務投入等。
此處建議產品經理們都去學習一門課《非財務人員的財務管理》體驗下財務的過程管理，如果能親歷沙盤訓練，記錄財務明細賬目，核算資產負債、現金流量、利潤率的計算，對成本和利益的核算非常有幫助，而且財務上要求的一絲不苟、精益求精也是每個產品經理需要長期堅持和遵守的。
9、整合需求
產品整合能力是產品經理很重要的一個能力，業務合作通常是不可避免的，將隸屬於兩個不同來源的業務功能做整合也是常見需求，比如系統登陸使用公司的域用戶登陸，或者付款使用財付通、支付寶付款，解決好整合需求也是體現產品經理核心競爭力的一大重要表現。
10、BETA測試需求
很多產品在正式上線前都有BETA版本或者內測版本，或者叫灰度版本，目的是在測試產品的一些核心功能或者性能。這部份內容不是必須的，但如果需要，需要給出在此階段要實現的目標或測試、衡量標準。
11、非功能性需求
一般情況下非功能性需求包括以下幾個部分：產品營銷需求、運營需求、財務需求、法務需求、使用幫助、問題反饋等。這些信息構成了產品上線的完整內容，也很好的體現了產品經理的綜合素質。
12、運營計劃
產品上線後如何運營，目標受眾是什麼，建議的推廣策略、問題反饋途徑、風險監控、亮點宣傳等等，以及與運營人員的協作方式。作為產品的設計人員不是開發完產品就能畫句號的，讓產品用起來、用得好，有口碑更為重要，所以非常建議運營計劃的制定上有產品設計人員的參與。
再次，說下需求變更
需求不是一成不變的，在產品研發過程中需求變更是正常的，產品團隊成員需正確的看待需求變更，並要控制好變更。這裡的建議是在做需求分析時，儘可能把每個問題都考慮透徹，提前做好需求變更的預估及應對方案，必要的情況下和團隊成員提前溝通存在變更的內容。
在與團隊溝通變更時，需要以一種開放的心態，從團隊成員的角度、產品未來的發展趨勢、市場格局的變化正確的提出變更需求，始終保持產品方向的正確和團隊成員目標的一致。
文檔意義
該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對MRD內容的繼承和發展，“向下”是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。
文檔撰寫
在該文檔中，基點依然是MRD中的內容，只是把重心放在了“產品需求”上，而產品需求本身是在MRD中有所體現的，區別就是在於，PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明。
這部分是PD寫得最多的內容，也就是傳統意義上的需求分析，我們這裡主要指UC（use case）文檔。主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程/子流程/分支流程，等幾大塊），Visio做的功能點業務流程，界面的說明，demo等。Demo方面，可能用dreamweaver、ps甚至畫圖板簡單畫一下，有時候也會有UI/UE支持，出高保真的demo，開發將來可以直接用的那種。
文檔核心
該文檔中，側重的是對產品產品功能和性能（即“產品需求”）的說明，相對於MRD中的同樣內容，要更加詳細，併進行量化。
在一些國外的公司，是允許把MRD和PRD合併成一個文檔的，通常叫做“Marketing & Product Requirements Document”。
產品需求文檔的寫作方法[2]
註：該方法為互聯網產品經理唐傑所作
1、寫前準備(信息結構圖)：
在寫PRD文檔之前，我們需要先羅列出產品功能的信息內容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來規劃功能的輔助信息，同時也可以輔助服務端技術人員創建資料庫。因為這是第一步，所以我們不需要羅列的很詳細，在之後的步驟里，我們會逐步改進和完善信息內容。
例如一篇文章的信息內容主要有：文章標題、文章正文、文章作者、發佈時間、所屬分類。初始的功能需求只有這些信息內容，但是在之後的功能規劃中逐漸更加細緻的考慮時，可能會增加或者刪減，因此第一步我們不用刻意的追求信息的全面。
羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是思維導圖，因此我稱這一步為信息結構圖。
2、梳理需求(產品結構圖和用戶流程圖)：
當我們對產品的信息結構瞭解後，我們就需要規整腦海中的產品需求，讓想法更加結構化，因此這一步是梳理產品的需求。我們首先要羅列出產品的頻道及頁面(產品結構圖)，其次再基於產品結構圖梳理出頻道及頁面中的功能，並延伸構建出用戶的操作流程(用戶流程圖)。
以上兩步是為了讓我們在撰寫產品需求文檔之前能夠對產品有一個全面的瞭解，類似鳥瞰式的一目瞭然，也方便調整完善。
3、原型設計(手繪原型,灰模原型,交互原型)：
當我們逐漸清晰了產品的需求後，並梳理了產品的各個頻道及頁面，那麼這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。
首先我建議通過手繪的形式快速在草紙上繪製出產品的原型，推演和討論方案的可行性，當有一定的進展之後，我們再通過軟體工具進行更深入的設計。移動產品可以考慮灰模原型，網站產品可以考慮交互原型，對於這兩種原型方式，無論是移動產品還是網站產品都可以使用，具體取得於你的個人習慣和團隊要求。
對於產品經理來說，原型設計是為了幫助我們細緻的考慮方案，並論證方案的可行性，同時也是為了避免產品宣講時，抽象的語言描述導致聽眾理解困難和理解偏差。
4、撰寫文檔(PRD文檔)：
當我們通過以上三個大的步驟之後，我們就已經非常清晰產品的需求了，一般情況下，通過原型加描述的方式就已經完成了PRD文檔的目的(很多產品經理直接使用Axure製作PRD)。
當然也會有一些個人或團隊的要求不一樣，對PRD文檔有特定的規範標準，這類情況可能是需要存檔歸類。無論什麼樣的規範標準，PRD文檔的目的都是相近的，因此功能描述的方式也是相似的，所以在這裡我分享了三種撰寫PRD文檔的方式。
5、用例文檔(UML用例圖、流程圖)：
《產品需求文檔(PRD)的寫作方法》的補充文章，主要講解PRD文檔中的重要輔助文檔“用例文檔”。
表示不太懂。。。。。