如何寫出好的產品需求文檔（PRD）？

      PRD(Product Requirement Document，產品需求文檔)，顧名思義是闡述產品需求的一種文檔，其核心是將需求描述清楚。

　　經過PRD能夠看出一個產品經理對產品理解的邏輯思惟，產品經理在相關領域的認知和專業的深度以及對產品全局的認識。如何才能寫出好的PRD，讓產品研發團隊成員，開發、測試、運營同窗瞭解產品需求，讓其餘人能從該文檔中看到產品的價值和意義，估計不少人都思考過，如何讓PRD不被其餘人挑戰，如何得到他們的承認估計是產品經理常常考慮的問題。也有人可能認爲PRD只要中心思想不變，闡明需求就已經足夠，交給下游的同窗他們理解了就完事了，可是這個文檔是否被叫好，是否有用，是否有價值可能從沒考慮過。

　　在此將從PRD的用戶側分析好的PRD應該具有的要素或必要條件。

　　首先，先了解清楚PRD的閱讀對象，使用者。

　　PRD的模版中通常有以下信息：

　　PRD預期的讀者包括：產品、開發、測試人員及相應的負責人和用戶方表明。產品、開發、測試人員會從中瞭解到本次需求的背景和詳細要求，以及每一個需求點將來的優化方向或對用戶的價值。而用戶方表明則能夠經過該文檔瞭解PRD中所描述內容是不是本身指望中的需求，是否符合以及是否都覆蓋到了本身的預期。所以PRD也是產品經理同相關角色確認開發任務的重要依據。當全部角色承認了PRD中的內容後，這份PRD將做爲後續開發、測試、需求驗證的依據。

　　其次，一個完整的PRD還應該具有的要素有

　　一、文檔的命名和編號

　　文檔的編號和命名很關鍵，每一個產品都是通過若干個迭代才完成的，而每一個迭代所完成的產品功能或者升級的需求均可能是不同的，所以須要定義清楚該文件屬於產品的哪一個迭代，修改了幾個版本。文件命名的方法通常是經過版本號定義，好比簡單的方法是，XX產品V1.0PRD_V2,前面的V1.0是產品迭代的編號，後面的V2 PRD的版本號。稍微詳細點能夠定義成，XX產品XXXX需求PRD_V2,即對本次迭代的需求任務作命名，這樣更便於閱讀和記憶。

　　二、文檔的版本歷史

　　包括，編號、文檔版本、章節、修改緣由、日期、修改人。編號只是爲了記錄修改的順序，文檔版本顯示的當前修改的內容屬於文檔的第幾個版本(或第幾回修改，一次修改通常爲一個版本)，章節是具體到修改內容屬於的功能模塊，以便閱讀人及時找到修改後的內容，修改緣由說明爲何要修改該需求，讓閱讀者直觀的瞭解緣由。日期是指需求文檔修改的時間，修改人是指需求內容的修改者。

　　三、目錄

　　不須要本身新建，文檔完成後直接更新模版中的目錄便可。目錄是用來了解文檔結構的

　　四、引言

　　這部分的內容有：產品概述及目標、產品roadmap、預期讀者、成功的定義標準和判斷、參考資料、名詞說明

　　產品概述：解釋說明該產品研發的背景以及核心功能。

　　產品roadmap：爲產品規劃的藍圖，每一個關鍵階段完成的核心任務。產品研發是個不斷迭代的過程，須要通過若干個版本的迭代，，對一個功能點作了N個迭代後最終又迴歸到了第一個迭代是很常見。產品經理須要作好心理準備。產品roadmap並不須要所有規劃好全部的階段目標，可是對產品將來發展趨勢的一種預估，要達到目標，須要更多的更新和迭代。清晰的呈現產品的roadmap能夠幫助產品經理把握產品的全貌，更好的控制研發過程。

　　預期讀者：文檔的使用對象

　　成功的定義和判斷標準：旨在說明產品的目標

　　參考資料：PRD的參考資料

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

　　五、需求概述

　　需求概述一般包括需求概覽、用戶類與特徵、運行環境、設計和實現上的限制、項目計劃、產品風險等等

　　需求概覽：分兩部分，一是業務流程圖，對產品整個業務流程的發生過程作圖形化的展現，是對產品總體功能流程的闡釋。二是需求清單，對本次要開發的需求任務作分類，給出簡明扼要的需求描述並標註優先級。

　　用戶類與特徵：產品的最終用戶，肯定產品的最終使用者，並對使用者的角色和操做行爲作出說明。

　　運行環境：該產品上線後的使用環境，好比支持的瀏覽器及其版本，操做系統、數據庫的要求等等，測試人員在看到環境要求後會在測試時重點測試，而最終上線產品時須要把最佳的運營環境告知給用戶。

　　設計和實現上的限制：好比控件的開發環境、接口的調用方式等等

　　項目計劃：對於prd中要開發的內容，給出關鍵里程碑，好比需求評審經過的時間、開發的完成時間、上線時間等等

　　產品風險：描述產品可能存在的風險，好比性能瓶頸，沒有解決的問題，用戶不當使用的風險等等。

　　6.功能需求

　　功能需求通常是由功能詳情和主流程說明兩大部分。功能詳情是全部的產品功能的描述和規劃。功能詳情包括如下內容：

　　簡要說明：介紹此功能的用途，包括其來源或背景，可以解決哪些問題。

　　場景描述，產品在哪一種狀況下會被用戶使用，就是用戶場景模擬。這也是產品經理講「好」故事的必備條件。

　　業務規則：每上產品在開發時都有相應的業務規則，將這些規則清晰的描述出來，讓開發、測試人員可以直觀的明白該規則，且沒有產生歧義。業務規則必需是完整的、準確的、易懂的。業務規則的描述上若是涉及到頁面交互或者頁面的修改，建議給出頁面的草圖或者頁面截圖在圖上說明要修改的內容。另外也建議對頁面的輸入框、下拉框的內容格式、長度、控件之間的關聯性作出說明，何時可見，不可見，灰掉或點亮的條件在文檔中都給出說明。方便閱讀者理解業務規則。

　　界面原型：如前所述，涉及到頁面交互的部分，產品經理須要設計頁面原型。原型設計一般須要產品經理和UI設計師一塊兒來完成。建議的作法是，產品經理可設計一個頁面框架，將該頁面要呈現的字段及其特徵以及頁面要使用的場景向交互設計師解釋清楚。以後交互和視覺設計師完成產品的原型設計。

　　使用者說明：對產品使用者作出說明，可融入簡要說明中。

　　前置條件：該需求實現依賴的前提條件。好比，上傳照片時，須要存有圖像文件。

　　後置條件：操做後引起的後續處理。

　　主流程：把主流放在最後是有道理的，結合上面所說的，作出主流程說明，對每一個功能流程走向分點說明(這是很是重要的)。

　　看過不少的PRD，文檔中對既沒有前提條件，也沒有後置條件，只對主流程作了說明，可是在描述主流程時卻沒有描寫主流程中每一個功能流程的各類走向，只有一個主走向，讓人感受prd成了操做手冊。事實上，對分支的介紹是很是重要的，開發和測試中提出的各種問題均與對分支的定義不明有關。一個合格的PRD不只要描述主流程，同時對分支流程所出現的各種問題都要作詳細闡述並給出解決辦法。PRD的特徵必定是明確的、全面的闡述需求及各種異常狀況的處理而不是等到開發和測試階段發現問題後再給以答案(雖然PRD不可能百分之百的覆蓋全部的可能，可是最大化的思考全部的業務問題是編制PRD時必須遵照的原則)。另外，在描寫功能需求時給出的辦法中不能出現「可能」、「或者」等詞，必定是明確的，惟一的描述。若是有別的方案，建議寫入「可選方案」，在產品構建的早期可選方案能夠爲功能實現提供更多的選擇，當方案肯定後可在文檔中註明本次使用了哪一種方案。

　　推薦一個方法：「用例」，在面向對象的軟件設計模型中，用例是一個被闡述的內容，用例是對功能使用場景的解釋。用例很條理的介紹了每一個功能的前置、後置條件，主流程介紹，幫助開發、測試等角色快速的瞭解產品功能。

　　七、可選方案

　　列出全部能夠選擇的達到該產品目標的方案要點(主要思路)，給各方案適當的評價，並推薦最優方案(在功能需求中描述的)。你在作這個產品規劃時必定有不少的備選方案，別放棄這些方案，永遠沒有過期的idea，只有最適合時機的idea。因此能夠寫出幾個可選方案，或許是你下期產品改版一個方向。記住，多思考方案是永不爲過的

　　八、效益成本分析

　　經過這一點上能看出產品經理必須是個全才，不只要具有行業知識，還須要有財務知識。一個產品的成本衡量通常包括三個方面：效益預測、產品技術成本和其餘成本支出。

　　效益預測是指所提供的功能在將來能產生的效益，可經過對比以往的產品或者競爭對手的產品來作預估，效益預測的指標，如每一個功能點的潛在用戶數、使用頻率，吸引到的新的用戶特徵及數量。產品技術成本是指研發設計以及上線後的運營須要的資源需求，包括人力，軟硬件(帶寬、服務器、機房)支出。當有項目經理時能夠由項目經理來協調這部分需求，若是沒有項目經理，產品經理得挑頭了，召集開發經理去找運維等部門落實此事。其餘的成本還包括支持成本，好比上線後的運營資源投入、市場推廣投入以及客服服務投入等。

　　此處建議產品經理們都去學習一門課《非財務人員的財務管理》體驗下財務的過程管理，若是能親歷沙盤訓練，記錄財務明細帳目，覈算資產負債、現金流量、利潤率的計算，對成本和利益的核算很是有幫助，並且財務上要求的一絲不苟、精益求精也是每一個產品經理須要長期堅持和遵照的。

　　九、整合需求

　　產品整合能力是產品經理很重要的一個能力，業務合做一般是不可避免的，將隸屬於兩個不一樣來源的業務功能作整合也是常見需求，好比系統登錄使用公司的域用戶登錄，或者付款使用財付通、支付寶付款，解決好整合需求也是體現產品經理核心競爭力的一大重要表現。

　　十、BETA測試需求

　　不少產品在正式上線前都有BETA版本或者內測版本，或者叫灰度版本，目的是在測試產品的一些核心功能或者性能。這部分內容不是必須的，但若是須要，須要給出在此階段要實現的目標或測試、衡量標準。

　　十一、非功能性需求

　　通常狀況下非功能性需求包括如下幾個部分：產品營銷需求、運營需求、財務需求、法務需求、使用幫助、問題反饋等。這些信息構成了產品上線的完整內容，也很好的體現了產品經理的綜合素質。

　　十二、運營計劃

　　產品上線後如何運營，目標受衆是什麼，建議的推廣策略、問題反饋途徑、風險監控、亮點宣傳等等，以及與運營人員的協做方式。做爲產品的設計人員不是開發完產品就能畫句號的，讓產品用起來、用得好，有口碑更爲重要，因此很是建議運營計劃的制定上有產品設計人員的參與。

　　再次，說下需求變動

　　需求不是一成不變的，在產品研發過程當中需求變動是正常的，產品團隊成員需正確的看待需求變動，並要控制好變動。這裏的建議是在作需求分析時，儘量把每一個問題都考慮透徹，提早作好需求變動的預估及應對方案，必要的狀況下和團隊成員提早溝通存在變動的內容。

　　在與團隊溝通變動時，須要以一種開放的心態，從團隊成員的角度、產品將來的發展趨勢、市場格局的變化正確的提出變動需求，始終保持產品方向的正確和團隊成員目標的一致。

　　總結

　　PRD的能力映射出的是一個產品經理的產品能力，這種能力分基礎和高級兩類，毋庸置疑，PRD應該是一種基礎能力，產品經理必備的一種技能，PRD的能力反映的就是產品經理對用戶需求的理解能力，這種能力實際上是創建在對行業的專業知識(表如今對業務的理解力)基礎上，再加之良好的溝通能力，一個優秀的產品經理寫出的PRD必然是準確度高，開發出來的產品擴展性好，同時受用戶歡迎。所以產品經理在平常必須深刻學習行業知識，瞭解用戶的操做規則，多與用戶溝通，多傾聽問題，從而發現問題，解決問題，隨着對行業和用戶的理解及把控的逐步深入，PRD闡述的內容將愈來愈全面，愈來愈有深度，這份PRD將成爲其餘人的學習資料，會產生深遠的影響。都說產品經理引領着產品的發展方向，是產品的「爸爸」或「媽媽」，衷心的但願每一個產品經理都能作個稱職的父母親。

　　做者：Cherry，2007年進入騰訊公司，一直從事互聯網廣告產品管理工做，目前在SNG/效果廣告平臺部從事效果廣告的產品運營工做。