先說明下，我也是一枚產(chǎn)品小白登夫，希望在此寫下自己在產(chǎn)品方面的學(xué)習(xí)歷程绅络，如果有與大家交流，那更是甚好谷暮！

prd（Product-Requirement-Document，產(chǎn)品需求文檔）：字面意思要明確表達(dá)產(chǎn)品需求盛垦，使得可以從產(chǎn)品需求中獲取各自的點(diǎn)湿弦，有效推進(jìn)工作。（ps:這個說的有些大腾夯，絲毫沒有切身的感受颊埃，但產(chǎn)品需求文檔會有很多技術(shù)、數(shù)據(jù)的gg看蝶俱，明確表達(dá)因?yàn)閄XX的用戶需求班利，產(chǎn)生XXX的產(chǎn)品設(shè)計，產(chǎn)品設(shè)計的細(xì)節(jié)如下XXX）榨呆。

以下是copy：http://www.woshipm.com/pd/624.html 以及自己的一些理解

講解一下PRD的主要內(nèi)容罗标。

1、文件命名（編號）

文件的編號很關(guān)鍵积蜻，因?yàn)楫a(chǎn)品迭代過程會有不同的文件版本闯割，一般命名規(guī)則“公司名+產(chǎn)品名+PRD+D1.0”（以第一版為例），這樣命名有利用版本號的迭代竿拆，如果是小的產(chǎn)品需求變動可以直接命名為“公司名-產(chǎn)品名-PRD-D1.01”纽谒，如果涉及到功能需求增加可以命名為“公司名-產(chǎn)品名-PRD-D1.1”，當(dāng)出現(xiàn)產(chǎn)品第二版時如输，可以命名為“公司名-產(chǎn)品名-PRD-D2.0”鼓黔。

我認(rèn)為這點(diǎn)可以不過重考慮：因?yàn)楣镜漠a(chǎn)品prd肯定已經(jīng)有了長期的命名規(guī)則，遵守即是不见。

2澳化、修訂控制頁

一般有這么幾項(xiàng)：編號、文檔版本稳吮、修訂章節(jié)缎谷、修訂原因、修訂日期灶似、修改人列林。編號只是為了給個修改的順序瑞你，文檔版本顯示的當(dāng)前修改的內(nèi)容是在哪個版本中出現(xiàn)，修訂章節(jié)是具體到哪個章節(jié)哪個功能模塊的修改希痴，修訂原因說明此功能修改的問題所在者甲。修訂日期以修改當(dāng)日的日期為修訂日期，修改人顯示修改內(nèi)容模塊的人砌创，可能是當(dāng)前用戶也可能是其它產(chǎn)品人員虏缸。

這個模塊比較重要，會同步每一次的修改信息嫩实，修改點(diǎn)刽辙，以便開發(fā)或者參照prd的同學(xué)明細(xì)及時同步修改信息。

3甲献、目錄

不建議自己去添加一個新的目錄宰缤，你可以去其它的文檔中拷一個過來，不考慮目錄的內(nèi)容晃洒，等寫完P(guān)RD可以再去更新撵溃。但建議用Mind manager來整理一下思路。

4锥累、請與以下部門討論P(yáng)RD

PRD做為一個承接作用的“載體”，會與技術(shù)集歇、運(yùn)營桶略、財務(wù)等人員的溝通，而與這些人員溝通的主題都將會出現(xiàn)在子功能或在細(xì)節(jié)細(xì)化的基本上诲宇，需要與相關(guān)人員確定“溝通內(nèi)容”际歼，這對于產(chǎn)品整體流程將是很重要的。同時對于產(chǎn)品核心功能的提取也是一個重要環(huán)節(jié)姑蓝。產(chǎn)品經(jīng)理很重要的一個職能就是溝通鹅心。例與客服中心：客服服務(wù)部，討論的內(nèi)容：預(yù)測客服成本纺荧、工作量旭愧；討論客服如何支持；協(xié)助評估詐欺/數(shù)據(jù)竄改風(fēng)險：欺詐/數(shù)據(jù)竄改風(fēng)險宙暇、不正使用風(fēng)險输枯。這就是要寫在與其它部門討論P(yáng)RD中的。一個產(chǎn)品經(jīng)理需要考慮如何與其它部門之間的溝通合作占贫，文檔很大一部分的功能是提醒你要做的工作桃熄，同時不斷補(bǔ)充將要面臨的工作。

5型奥、概述

概念就是總結(jié)瞳收，它包括的點(diǎn)有：名詞說明碉京、產(chǎn)品概述及目標(biāo)、產(chǎn)品roadmap螟深、產(chǎn)品風(fēng)險谐宙。

名詞說明：名稱、說明血崭。名稱就是對文檔中會出現(xiàn)的比較新的名稱卧惜，說明則是對這些名稱進(jìn)行解釋。

產(chǎn)品概述及目標(biāo)：解釋說明該產(chǎn)品是干什么的夹纫，為什么需要這樣的產(chǎn)品咽瓷。同時產(chǎn)品想要達(dá)到什么樣的目標(biāo)。產(chǎn)品概述及目標(biāo)就是對產(chǎn)品核心功能講解舰讹，同時希望可以達(dá)到的期望茅姜。

產(chǎn)品roadmap：產(chǎn)品分期目標(biāo)，階段描述月匣，以及時間點(diǎn)的確定钻洒，產(chǎn)品是個不斷演進(jìn)的過程，很多時間一期產(chǎn)品只完成了產(chǎn)品70%的功能锄开，二期才會繼續(xù)去完善剩下的30%素标，同時有可能會推翻了重新推出第二版。產(chǎn)品roadmap并不及著全部規(guī)劃好所有的階段目標(biāo)萍悴，而是更多的通過維護(hù)來保持產(chǎn)品的更新和迭代头遭。

產(chǎn)品風(fēng)險：描述產(chǎn)品可能存在的風(fēng)險，比如商務(wù)談判的風(fēng)險癣诱，外部合作的風(fēng)險计维，不當(dāng)使用的風(fēng)險等等。風(fēng)險級別為高中低撕予。

6鲫惶、使用者需求

使用者需求一般只有個需求描述。需求描述有以下幾項(xiàng)內(nèi)容：目標(biāo)客戶实抡、需求描述欠母、場景描述、優(yōu)先級吆寨。

目標(biāo)客戶即為產(chǎn)品的最終用戶艺蝴，確定產(chǎn)品的最終使用者。

需求描述是對目標(biāo)客戶的需求描述鸟废，表達(dá)用戶最需要的是什么猜敢，找到用戶的最根本需求。

場景描述，產(chǎn)品在哪種情況下會被用戶使用缩擂，就是用戶場景模擬鼠冕。

優(yōu)先級是指用戶對于當(dāng)前產(chǎn)品功能需求的優(yōu)先級，哪些是用戶最想要的功能優(yōu)先級則排前胯盯。

7懈费、可選方案

列出所有可以選擇的達(dá)到該產(chǎn)品目標(biāo)的方案要點(diǎn)（主要思路），給各方案適當(dāng)?shù)脑u價博脑，并推薦最優(yōu)方案憎乙。你在做這個產(chǎn)品規(guī)劃時一定有很多的備選方案，別放棄這些方案叉趣，永遠(yuǎn)沒有過時的idea泞边，只有最適合時機(jī)的idea。所以可以寫出幾個可選方案疗杉，或許是你下期產(chǎn)品改版一個方向阵谚。

8、效益成本分析

產(chǎn)品經(jīng)理是個全才烟具，在這點(diǎn)上得到了體驗(yàn)梢什。產(chǎn)品經(jīng)理得知道財務(wù)知識。很大一部分是產(chǎn)品的環(huán)境搭建成本和支持人員的成本朝聋。一般的效益成本分析包括三個方面：效益預(yù)測嗡午、產(chǎn)品技術(shù)中心成本、非產(chǎn)品技術(shù)中心支持成本冀痕。

效益預(yù)測是指提供在各種產(chǎn)品環(huán)境中的效益預(yù)測荔睹，并標(biāo)明主要的變量及假設(shè)，最好能包含現(xiàn)在和過去的效益數(shù)據(jù)金度。如網(wǎng)站的PV值，軟件的使用數(shù)都是效益預(yù)測數(shù)據(jù)严沥。

產(chǎn)品技術(shù)中心成本是指設(shè)計及部署此產(chǎn)品的產(chǎn)品技術(shù)中心所需的資源需求猜极，包括人力成本，軟硬件支出等消玄。很大時候這份成本需要由項(xiàng)目經(jīng)理來協(xié)助跟伏，需要有什么樣的人才加入產(chǎn)品中需與人力協(xié)助。

非產(chǎn)品技術(shù)中心支持成本翩瓜，產(chǎn)品不是只有產(chǎn)品組完成的受扳，同樣需要其它部門的配合與協(xié)助。比如：需要客服部投入多少的資源用于該產(chǎn)品的服務(wù)兔跌，需要運(yùn)營部投入多少的資源運(yùn)營該產(chǎn)品勘高。

9、功能需求

功能需求一般是由四部分組成，功能總覽华望、功能詳情蕊蝗、整合需求、BETA測試需求赖舟。

功能總覽一般包括二個部分蓬戚，一個是流程圖，一個是功能表宾抓。流程圖是對產(chǎn)品的整體走向的流程的規(guī)劃子漩，流程圖是用來對產(chǎn)品整體功能的梳理。所以在做產(chǎn)品前建議所有的產(chǎn)品經(jīng)理先梳理一下產(chǎn)品流程石洗。功能表是將流程圖文字化幢泼，同時將列出產(chǎn)品的功能點(diǎn)。

功能詳情劲腿，這是所有的產(chǎn)品功能的描述和規(guī)劃旭绒。包括以下內(nèi)容：

簡要說明：告訴此功能主要干什么的。

業(yè)務(wù)規(guī)則：每上產(chǎn)品在使用時都有自己的規(guī)則焦人，而產(chǎn)品的業(yè)務(wù)規(guī)則則是將產(chǎn)品的流程細(xì)化挥吵。個人建議將這個功能的業(yè)務(wù)規(guī)則，包括一些細(xì)節(jié)花椭，如排版形式忽匈、日期顯示方式全定好，這樣方便其它人員的溝通和理解矿辽。

界面原型：產(chǎn)品經(jīng)理在這時做的原型界面只是顯示的框架丹允，別細(xì)化，這樣會給交互和UI造成錯覺袋倔。只需做一個簡單的界面即可雕蔽，更多的時候只是個框架圖。

執(zhí)行者：產(chǎn)品使用者宾娜。

前置條件：具體的操作批狐。

后置條件：操作后的展示。在UC（user case）中后置條件又是另一種情況前塔，所以對于建議在PRD中的前置條件和后置條件結(jié)果合起來嚣艇。

主流程：把主流放在最后是有道理的，結(jié)合上面所說的华弓，做出主流程說明食零。將此功能的流程走向做個分點(diǎn)說明。

10寂屏、整合需求

產(chǎn)品經(jīng)理很重要的一個能力就是體現(xiàn)在產(chǎn)品整合能力上贰谣，利用公司現(xiàn)有的資源或外部資源（合作公司等）實(shí)現(xiàn)產(chǎn)品功能需求的整合娜搂。實(shí)現(xiàn)功能貫穿的同時，更多的如何在新產(chǎn)品上實(shí)現(xiàn)功能的拓展來輔助核心功能冈爹。

11涌攻、BETA測試需求

很多產(chǎn)品都有BETA版本放出，為了就是收求意見和一些性能測試频伤。這部份內(nèi)容不是必須的恳谎，但現(xiàn)在很多產(chǎn)品已經(jīng)開始先推出BETA版本再推出正式版，

當(dāng)然也可以通過升級來解決憋肖。所以BETA測試需求并不是一定需要的因痛。如果有BETA測試需求，則需寫出BETA版測試的要求和期望達(dá)到的目標(biāo)要求岸更。

12鸵膏、非功能性需求

都說產(chǎn)品經(jīng)理是全才，在這點(diǎn)上得到徹底的體現(xiàn)怎炊。很多產(chǎn)品經(jīng)理在這點(diǎn)上忽視了谭企，但很多方面是用到的，只是在產(chǎn)品過程中弱化了评肆。

一般情況下非功能性需求包括以下幾個部分：產(chǎn)品營銷需求债查、規(guī)則變更需求、產(chǎn)品服務(wù)需求瓜挽、法務(wù)需求盹廷、財務(wù)需求、幫助需求久橙、安全性需求等俄占。與其說是全方位的掌握技能，還不如說是溝通淆衷，如何與不同的部門人員之間的溝通缸榄，讓更多的人協(xié)助產(chǎn)品的正常使用與上線。

13祝拯、上甚带、下線需求

上線時限需求：此產(chǎn)品預(yù)定上線日期？上線日期有無任何特殊依據(jù)或規(guī)定鹿驼？

下線需求（活動類需求必須明確下線時間）：此產(chǎn)品預(yù)定下線日期欲低？下線日期有無任何特殊依據(jù)或規(guī)定辕宏？

14畜晰、運(yùn)營計劃

說明產(chǎn)品的后續(xù)運(yùn)營計劃。包括與運(yùn)營部的協(xié)作運(yùn)營瑞筐。更多的是給產(chǎn)品經(jīng)理如何讓更多的產(chǎn)品功能展示給用戶凄鼻，產(chǎn)品經(jīng)理是核心需求的把握者，參與到產(chǎn)品整體運(yùn)營計劃顯得特別的重要。

……

寫PRD并不是產(chǎn)品經(jīng)理的全部工作块蚌，但卻是不可少的一部分闰非，很大程度上反應(yīng)了產(chǎn)品經(jīng)理的思維和產(chǎn)品核心功能把握上，同時對產(chǎn)品經(jīng)理溝通峭范、協(xié)調(diào)财松、規(guī)劃等都得到了一定的驗(yàn)證，但每個產(chǎn)品經(jīng)理的第一職能是會寫一份讓其它人員看得懂的PRD纱控。