prd（product requirement document，產(chǎn)品需求文檔），顧名思義是闡述產(chǎn)品需求的一種文檔，其核心是將需求描述清楚。
通過(guò)prd可以看出一個(gè)產(chǎn)品經(jīng)理對(duì)產(chǎn)品理解的邏輯思維，產(chǎn)品經(jīng)理在相關(guān)領(lǐng)域的認(rèn)知和專(zhuān)業(yè)的深度以及對(duì)產(chǎn)品全局的認(rèn)識(shí)。如何才能寫(xiě)出好的prd，讓產(chǎn)品研發(fā)團(tuán)隊(duì)成員，開(kāi)發(fā)、測(cè)試、運(yùn)營(yíng)同學(xué)了解產(chǎn)品需求，讓其他人能從該文檔中看到產(chǎn)品的價(jià)值和意義，估計(jì)很多人都思考過(guò)，如何讓prd不被其他人挑戰(zhàn)，如何獲得他們的認(rèn)可估計(jì)是產(chǎn)品經(jīng)理經(jīng)?？紤]的問(wèn)題。也有人可能認(rèn)為prd只要中心思想不變，闡明需求就已經(jīng)足夠，交給下游的同學(xué)他們理解了就完事了，但是這個(gè)文檔是否被叫好，是否有用，是否有價(jià)值可能從沒(méi)考慮過(guò)。
在此將從prd的用戶側(cè)分析好的prd應(yīng)該具備的要素或必要條件。
首先，先了解清楚prd的閱讀對(duì)象，使用者。
prd的模版中一般有如下信息：
prd預(yù)期的讀者包括：產(chǎn)品、開(kāi)發(fā)、測(cè)試人員及相應(yīng)的負(fù)責(zé)人和用戶方代表。產(chǎn)品、開(kāi)發(fā)、測(cè)試人員會(huì)從中了解到本次需求的背景和詳細(xì)要求，以及每個(gè)需求點(diǎn)未來(lái)的優(yōu)化方向或?qū)τ脩舻膬r(jià)值。而用戶方代表則可以通過(guò)該文檔了解prd中所描述內(nèi)容是否是自己期望中的需求，是否符合以及是否都覆蓋到了自己的預(yù)期。因此prd也是產(chǎn)品經(jīng)理同相關(guān)角色確認(rèn)開(kāi)發(fā)任務(wù)的重要依據(jù)。當(dāng)所有角色認(rèn)可了prd中的內(nèi)容后，這份prd將作為后續(xù)開(kāi)發(fā)、測(cè)試、需求驗(yàn)證的依據(jù)。
其次，一個(gè)完整的prd還應(yīng)該具備的要素有
1、文檔的命名和編號(hào)
文檔的編號(hào)和命名很關(guān)鍵，每個(gè)產(chǎn)品都是經(jīng)過(guò)若干個(gè)迭代才完成的，而每個(gè)迭代所完成的產(chǎn)品功能或者升級(jí)的需求都可能是不一樣的，因此需要定義清楚該文件屬于產(chǎn)品的哪個(gè)迭代，修改了幾個(gè)版本。文件命名的方法一般是通過(guò)版本號(hào)定義，比如簡(jiǎn)單的方法是，xx產(chǎn)品v1.0prd_v2,前面的v1.0是產(chǎn)品迭代的編號(hào)，后面的v2 prd的版本號(hào)。稍微詳細(xì)點(diǎn)可以定義成，xx產(chǎn)品xxxx需求prd_v2,即對(duì)本次迭代的需求任務(wù)做命名，這樣更便于閱讀和記憶。
2、文檔的版本歷史
包括，編號(hào)、文檔版本、章節(jié)、修改原因、日期、修改人。編號(hào)只是為了記錄修改的順序，文檔版本顯示的當(dāng)前修改的內(nèi)容屬于文檔的第幾個(gè)版本（或第幾次修改，一次修改一般為一個(gè)版本），章節(jié)是具體到修改內(nèi)容屬于的功能模塊，以便閱讀人及時(shí)找到修改后的內(nèi)容，修改原因說(shuō)明為什么要修改該需求，讓閱讀者直觀的了解原因。日期是指需求文檔修改的時(shí)間，修改人是指需求內(nèi)容的修改者。
3、目錄
不需要自己新建，文檔完成后直接更新模版中的目錄即可。目錄是用來(lái)了解文檔結(jié)構(gòu)的
4、引言
這部分的內(nèi)容有：產(chǎn)品概述及目標(biāo)、產(chǎn)品roadmap、預(yù)期讀者、成功的定義標(biāo)準(zhǔn)和判斷、參考資料、名詞說(shuō)明
產(chǎn)品概述：解釋說(shuō)明該產(chǎn)品研發(fā)的背景以及核心功能。
產(chǎn)品roadmap：為產(chǎn)品規(guī)劃的藍(lán)圖，每個(gè)關(guān)鍵階段完成的核心任務(wù)。產(chǎn)品研發(fā)是個(gè)不斷迭代的過(guò)程，需要經(jīng)過(guò)若干個(gè)版本的迭代，，對(duì)一個(gè)功能點(diǎn)做了n個(gè)迭代后最終又回歸到了第一個(gè)迭代是很常見(jiàn)。產(chǎn)品經(jīng)理需要做好心理準(zhǔn)備。產(chǎn)品roadmap并不需要全部規(guī)劃好所有的階段目標(biāo)，但是對(duì)產(chǎn)品未來(lái)發(fā)展趨勢(shì)的一種預(yù)估，要達(dá)到目標(biāo)，需要更多的更新和迭代。清晰的呈現(xiàn)產(chǎn)品的roadmap可以幫助產(chǎn)品經(jīng)理把握產(chǎn)品的全貌，更好的控制研發(fā)過(guò)程。
預(yù)期讀者：文檔的使用對(duì)象
成功的定義和判斷標(biāo)準(zhǔn)：旨在說(shuō)明產(chǎn)品的目標(biāo)
參考資料：prd的參考資料
名詞說(shuō)明：名稱(chēng)、說(shuō)明。名稱(chēng)就是對(duì)文檔中會(huì)出現(xiàn)的比較新的名稱(chēng)，說(shuō)明則是對(duì)這些名稱(chēng)進(jìn)行解釋。
5、需求概述
需求概述通常包括需求概覽、用戶類(lèi)與特征、運(yùn)行環(huán)境、設(shè)計(jì)和實(shí)現(xiàn)上的限制、項(xiàng)目計(jì)劃、產(chǎn)品風(fēng)險(xiǎn)等等
需求概覽：分兩部分，一是業(yè)務(wù)流程圖，對(duì)產(chǎn)品整個(gè)業(yè)務(wù)流程的發(fā)生過(guò)程做圖形化的展示，是對(duì)產(chǎn)品整體功能流程的闡釋。二是需求清單，對(duì)本次要開(kāi)發(fā)的需求任務(wù)做分類(lèi)，給出簡(jiǎn)明扼要的需求描述并標(biāo)注優(yōu)先級(jí)。
用戶類(lèi)與特征：產(chǎn)品的最終用戶，確定產(chǎn)品的最終使用者，并對(duì)使用者的角色和操作行為做出說(shuō)明。
運(yùn)行環(huán)境：該產(chǎn)品上線后的使用環(huán)境，比如支持的瀏覽器及其版本，操作系統(tǒng)、數(shù)據(jù)庫(kù)的要求等等，測(cè)試人員在看到環(huán)境要求后會(huì)在測(cè)試時(shí)重點(diǎn)測(cè)試，而最終上線產(chǎn)品時(shí)需要把最佳的運(yùn)營(yíng)環(huán)境告知給用戶。
設(shè)計(jì)和實(shí)現(xiàn)上的限制：比如控件的開(kāi)發(fā)環(huán)境、接口的調(diào)用方式等等
項(xiàng)目計(jì)劃：對(duì)于prd中要開(kāi)發(fā)的內(nèi)容，給出關(guān)鍵里程碑，比如需求評(píng)審?fù)ㄟ^(guò)的時(shí)間、開(kāi)發(fā)的完成時(shí)間、上線時(shí)間等等
產(chǎn)品風(fēng)險(xiǎn)：描述產(chǎn)品可能存在的風(fēng)險(xiǎn)，比如性能瓶頸，沒(méi)有解決的問(wèn)題，用戶不當(dāng)使用的風(fēng)險(xiǎn)等等。
6.功能需求
功能需求一般是由功能詳情和主流程說(shuō)明兩大部分。功能詳情是所有的產(chǎn)品功能的描述和規(guī)劃。功能詳情包括以下內(nèi)容：
簡(jiǎn)要說(shuō)明：介紹此功能的用途，包括其來(lái)源或背景，能夠解決哪些問(wèn)題。
場(chǎng)景描述，產(chǎn)品在哪種情況下會(huì)被用戶使用，就是用戶場(chǎng)景模擬。這也是產(chǎn)品經(jīng)理講“好”故事的必備條件。
業(yè)務(wù)規(guī)則：每上產(chǎn)品在開(kāi)發(fā)時(shí)都有相應(yīng)的業(yè)務(wù)規(guī)則，將這些規(guī)則清晰的描述出來(lái)，讓開(kāi)發(fā)、測(cè)試人員能夠直觀的明白該規(guī)則，且沒(méi)有產(chǎn)生歧義。業(yè)務(wù)規(guī)則必需是完整的、準(zhǔn)確的、易懂的。業(yè)務(wù)規(guī)則的描述上如果涉及到頁(yè)面交互或者頁(yè)面的修改，建議給出頁(yè)面的草圖或者頁(yè)面截圖在圖上說(shuō)明要修改的內(nèi)容。另外也建議對(duì)頁(yè)面的輸入框、下拉框的內(nèi)容格式、長(zhǎng)度、控件之間的關(guān)聯(lián)性做出說(shuō)明，什么時(shí)候可見(jiàn)，不可見(jiàn)，灰掉或點(diǎn)亮的條件在文檔中都給出說(shuō)明。方便閱讀者理解業(yè)務(wù)規(guī)則。
界面原型：如前所述，涉及到頁(yè)面交互的部分，產(chǎn)品經(jīng)理需要設(shè)計(jì)頁(yè)面原型。原型設(shè)計(jì)通常需要產(chǎn)品經(jīng)理和ui設(shè)計(jì)師一起來(lái)完成。建議的做法是，產(chǎn)品經(jīng)理可設(shè)計(jì)一個(gè)頁(yè)面框架，將該頁(yè)面要呈現(xiàn)的字段及其特征以及頁(yè)面要使用的場(chǎng)景向交互設(shè)計(jì)師解釋清楚。之后交互和視覺(jué)設(shè)計(jì)師完成產(chǎn)品的原型設(shè)計(jì)。
使用者說(shuō)明：對(duì)產(chǎn)品使用者做出說(shuō)明，可融入簡(jiǎn)要說(shuō)明中。
前置條件：該需求實(shí)現(xiàn)依賴的前提條件。比如，上傳照片時(shí)，需要存有圖像文件。 后置條件：操作后引發(fā)的后續(xù)處理。
主流程：把主流放在最后是有道理的，結(jié)合上面所說(shuō)的，做出主流程說(shuō)明，對(duì)每個(gè)功能流程走向分點(diǎn)說(shuō)明（這是非常重要的）。
看過(guò)很多的prd，文檔中對(duì)既沒(méi)有前提條件，也沒(méi)有后置條件，只對(duì)主流程做了說(shuō)明，但是在描述主流程時(shí)卻沒(méi)有描寫(xiě)主流程中每個(gè)功能流程的各種走向，只有一個(gè)主走向，讓人感覺(jué)prd成了操作手冊(cè)。事實(shí)上，對(duì)分支的介紹是非常重要的，開(kāi)發(fā)和測(cè)試中提出的各類(lèi)問(wèn)題均與對(duì)分支的定義不明有關(guān)。一個(gè)合格的prd不僅要描述主流程，同時(shí)對(duì)分支流程所出現(xiàn)的各類(lèi)問(wèn)題都要做詳細(xì)闡述并給出解決辦法。prd的特征一定是明確的、全面的闡述需求及各類(lèi)異常情況的處理而不是等到開(kāi)發(fā)和測(cè)試階段發(fā)現(xiàn)問(wèn)題后再給以答案（雖然prd不可能百分之百的覆蓋所有的可能，但是最大化的思考所有的業(yè)務(wù)問(wèn)題是編制prd時(shí)必須遵守的原則）。另外，在描寫(xiě)功能需求時(shí)給出的辦法中不能出現(xiàn)“可能”、“或者”等詞，一定是明確的，唯一的描述。如果有別的方案，建議寫(xiě)入“可選方案”，在產(chǎn)品構(gòu)建的早期可選方案可以為功能實(shí)現(xiàn)提供更多的選擇，當(dāng)方案確定后可在文檔中注明本次使用了哪種方案。
推薦一個(gè)方法：“用例”，在面向?qū)ο蟮能浖O(shè)計(jì)模型中，用例是一個(gè)被闡述的內(nèi)容，用例是對(duì)功能使用場(chǎng)景的解釋。用例很條理的介紹了每個(gè)功能的前置、后置條件，主流程介紹，幫助開(kāi)發(fā)、測(cè)試等角色快速的了解產(chǎn)品功能。
7、可選方案
列出所有可以選擇的達(dá)到該產(chǎn)品目標(biāo)的方案要點(diǎn)（主要思路），給各方案適當(dāng)?shù)脑u(píng)價(jià)，并推薦最優(yōu)方案（在功能需求中描述的）。你在做這個(gè)產(chǎn)品規(guī)劃時(shí)一定有很多的備選方案，別放棄這些方案，永遠(yuǎn)沒(méi)有過(guò)時(shí)的idea，只有最適合時(shí)機(jī)的idea。所以可以寫(xiě)出幾個(gè)可選方案，或許是你下期產(chǎn)品改版一個(gè)方向。記住，多思考方案是永不為過(guò)的
8、效益成本分析
通過(guò)這一點(diǎn)上能看出產(chǎn)品經(jīng)理必須是個(gè)全才，不僅要具備行業(yè)知識(shí)，還需要有財(cái)務(wù)知識(shí)。一個(gè)產(chǎn)品的成本衡量一般包括三個(gè)方面：效益預(yù)測(cè)、產(chǎn)品技術(shù)成本和其他成本支出。
效益預(yù)測(cè)是指所提供的功能在未來(lái)能產(chǎn)生的效益，可通過(guò)對(duì)比以往的產(chǎn)品或者競(jìng)爭(zhēng)對(duì)手的產(chǎn)品來(lái)做預(yù)估，效益預(yù)測(cè)的指標(biāo)，如每個(gè)功能點(diǎn)的潛在用戶數(shù)、使用頻率，吸引到的新的用戶特征及數(shù)量。產(chǎn)品技術(shù)成本是指研發(fā)設(shè)計(jì)以及上線后的運(yùn)營(yíng)需要的資源需求，包括人力，軟硬件（帶寬、服務(wù)器、機(jī)房）支出。當(dāng)有項(xiàng)目經(jīng)理時(shí)可以由項(xiàng)目經(jīng)理來(lái)協(xié)調(diào)這部分需求，如果沒(méi)有項(xiàng)目經(jīng)理，產(chǎn)品經(jīng)理得挑頭了，召集開(kāi)發(fā)經(jīng)理去找運(yùn)維等部門(mén)落實(shí)此事。其他的成本還包括支持成本，比如上線后的運(yùn)營(yíng)資源投入、市場(chǎng)推廣投入以及客服服務(wù)投入等。
此處建議產(chǎn)品經(jīng)理們都去學(xué)習(xí)一門(mén)課《非財(cái)務(wù)人員的財(cái)務(wù)管理》體驗(yàn)下財(cái)務(wù)的過(guò)程管理，如果能親歷沙盤(pán)訓(xùn)練，記錄財(cái)務(wù)明細(xì)賬目，核算資產(chǎn)負(fù)債、現(xiàn)金流量、利潤(rùn)率的計(jì)算，對(duì)成本和利益的核算非常有幫助，而且財(cái)務(wù)上要求的一絲不茍、精益求精也是每個(gè)產(chǎn)品經(jīng)理需要長(zhǎng)期堅(jiān)持和遵守的。
9、整合需求
產(chǎn)品整合能力是產(chǎn)品經(jīng)理很重要的一個(gè)能力，業(yè)務(wù)合作通常是不可避免的，將隸屬于兩個(gè)不同來(lái)源的業(yè)務(wù)功能做整合也是常見(jiàn)需求，比如系統(tǒng)登陸使用公司的域用戶登陸，或者付款使用財(cái)付通、支付寶付款，解決好整合需求也是體現(xiàn)產(chǎn)品經(jīng)理核心競(jìng)爭(zhēng)力的一大重要表現(xiàn)。
10、beta測(cè)試需求
很多產(chǎn)品在正式上線前都有beta版本或者內(nèi)測(cè)版本，或者叫灰度版本，目的是在測(cè)試產(chǎn)品的一