最近換了新工作，又重新開始用模版寫PRD嫌松，上一份工作中PRD是沒有模版的沪曙，流程圖和原型畫出來，業(yè)務規(guī)則寫上去萎羔，就交給設計研發(fā)和測試同學實施了液走，以便快速迭代，團隊小贾陷，不清楚馬上溝通就好缘眶，文檔工程師從來不看。新工作團隊大髓废，一個模塊做出來可能要跨很多個部門巷懈，模版式的PRD成了必不可少的溝通基礎』藕椋看著新公司的PRD模版顶燕，回想上一份工作的簡易PRD文檔，我開始思考冈爹，到底一份優(yōu)秀的PRD文檔應該是怎樣的呢涌攻？
做產品不到4年，這是呆過的第三個產品團隊频伤，見過的PRD文檔不多癣漆，只能根據(jù)經驗和平時跟其他朋友的溝通，來說說我認為的一份優(yōu)秀的PRD文檔應該包含哪些內容剂买？
在我看來惠爽，一份優(yōu)秀的PRD，應該像你的產品一樣瞬哼，有清晰的目標用戶（設計師婚肆、開發(fā)、測試）坐慰，有具體的使用場景（設計在進行交互较性、頁面用僧、視覺設計，研發(fā)在進行詳細設計赞咙、需求開發(fā)责循，測試在進行需求測試時使用），有明確的需求痛點（熟悉需求要做什么）攀操，產品的PRD文檔就是針對上述用戶在相應場景下的需求痛點給出的解決方案院仿，因此，一份優(yōu)秀的PRD文檔就是針對多角色的優(yōu)質解決方案速和。
因此歹垫，一份好的PRD文檔應至少包含以下模塊：
需求背景、需求描述颠放、角色說明排惨、流程圖、頁面及功能碰凶、與其他系統(tǒng)交互接口暮芭、效果預期、數(shù)據(jù)指標欲低、prd迭代記錄
1.需求背景
在早年開始做產品的時候谴麦，花在需求背景上的思考時間總是最少的，因為認為這部分對需求實施方來說并無太大作用伸头，簡單的幾句話匾效，看的人又能獲得什么呢？需求實施看到更多的是流程恤磷、功能面哼、頁面這些具體的內容，因此大部分精力都花在流程功能上了扫步。
直到這一年來魔策，對產品對需求的理解更往前了一些，接觸到的優(yōu)秀設計師和研發(fā)人員也多了河胎，每次需求評審前闯袒，都會有人問需求目的是啥，我才慢慢理解需求背景的作用游岳。
需求背景政敢，在我理解就是需要解釋清楚這么幾個事情，需求是如何被抽象出來要在產品中落地實現(xiàn)的胚迫，是基于什么樣的考慮要做這個需求喷户，做完以后又希望能有什么效果，達到什么目的访锻。
舉例來說褪尝，得到app中專欄訂閱的請朋友讀功能闹获，如果讓我來描述這個需求的需求背景，我可能會這么寫：
由于目前專欄訂閱的內容呈現(xiàn)以及消費內容的基礎功能已經相對完善河哑，下一階段重點之一是內容推廣避诽，讓更多的用戶消費訂閱內容并愿意為專欄付費，除了平臺推廣外璃谨，我們希望能通過用戶對優(yōu)質內容在社交媒體的自傳播拉動用戶增長沙庐，因此，希望在此版本中增加“請朋友讀”功能睬罗。
2.需求描述
在講清楚需求背景以后轨功，緊接著我們需要用總結性的幾句話旭斥，說明具體的需求描述容达。
PRD文檔的目標用戶在了解完需求背景后，大概率希望能看看這個需求到底要做什么垂券，有哪些大的規(guī)則方向花盐，會有哪些大的功能模塊。總之菇爪，就是用三五句話讓大家能對要做的需求有一個整體的認知算芯。
還是上面那個例子，如果讓我來寫需求描述凳宙，我可能會這么寫：
此次需求主要是在專欄每期內容詳情頁增加請朋友讀分享功能熙揍，用戶可通過此功能將專欄內容通過社交網絡分享給朋友，被分享者可在站外直接打開當期內容詳情頁消費內容氏涩，閱讀及收聽均可届囚，同時用戶可在站外直接購買專欄內容。
3.角色說明
需求的整體概述說清楚以后是尖，在進入詳細的需求分析階段之前意系，我們要定義清楚，此次需求涉及到的角色都有哪些饺汹，這可以幫助PRD文檔的閱讀者更好的理解需求蛔添。
在進行角色說明時，我通常會分為兩類兜辞，一類是真實的人群角色迎瞧，一類是涉及的系統(tǒng)。
真實的人群角色好理解逸吵，這次需求會有哪些人群參與夹攒，比如得到這個例子，主要的參與角色當然是分享者和被分享者胁塞，也就是已購買專欄的用戶和未購買專欄的用戶咏尝。
涉及到的系統(tǒng)压语，通常情況下，一個需求實現(xiàn)可能會涉及多個系統(tǒng)编检，尤其是大公司的產品被切割得很細胎食，并且用戶端的產品，通常還會跟公司外的其他產品交互允懂，比如微信厕怜、微博這種社交網絡，這些系統(tǒng)都應該在角色說明里體現(xiàn)蕾总。
4.流程圖
在介紹完上面三部分以后粥航，要開始進入詳細的需求分析了，從流程圖開始生百。流程圖是需求文檔中必不可少的一部分递雀，PRD的讀者，從流程圖開始對產品有了具體的認知蚀浆。
通過流程圖缀程，讀者可以知道此次需求的核心流程是什么，會有哪些角色參與市俊，角色與角色之間是如何交互的杨凑，信息是如何在不同角色間流轉的，核心的環(huán)節(jié)又要哪些摆昧。
在繪制流程圖時撩满，我通常會分兩種情況來考慮，如果流程相對簡單绅你，涉及的角色不超過2個伺帘，我可能會用單線的步驟流程圖來呈現(xiàn)，比如下圖：
如果流程相對負責勇吊，涉及的角色多曼追，各環(huán)節(jié)之間的交互復雜，多重判斷汉规，這個時候我會用泳道圖來繪制流程圖礼殊，習慣用visio來繪制，比如下圖：
5.頁面及功能
這一部分不用多說针史，是PRD的主體部分晶伦，詳細的描述此次需求包含哪些頁面，每個頁面的布局啄枕，具備哪些功能婚陪，每個功能的規(guī)則是怎樣的。
PRD的讀者通過這部分的閱讀频祝，可以說基本清楚此次需求到底是做什么的泌参，詳細的規(guī)則是怎樣的脆淹。
在這部分的編寫中，我會按照大的頁面來劃分沽一，每個頁面當作獨立的模塊來說明盖溺，在進行每個頁面的需求分析時，又會分為3部分：功能說明铣缠、頁面顯示烘嘱、業(yè)務規(guī)則。
功能說明：整體的概述這個頁面承擔的功能蝗蛙，包含哪些衍生的子頁面蝇庭，以及與哪些大頁面有交互；
頁面顯示：很好理解捡硅，說明大頁面以及子頁面是如何布局的哮内，包含哪些元素，精確到子頁面來說明病曾。比如有一個大頁面是信息錄入頁面牍蜂，但是這個大頁面根據(jù)不同的錄入狀態(tài)又會衍生出來許多子頁面漾根，這時候要精確到子頁面來進行頁面顯示的說明泰涂。
業(yè)務規(guī)則：跟頁面顯示對應，說明每個子頁面包含功能的業(yè)務規(guī)則辐怕。
6.與其他系統(tǒng)交互接口
根據(jù)前面所說逼蒙，相對復雜一些的需求，可能都會涉及到與其他系統(tǒng)的交互寄疏，有的是公司內部的其他產品是牢，有的是外部的產品，這時候陕截，就需要在需求文檔中說明驳棱，會與之交互的系統(tǒng)，并且附上定義清楚的接口文檔农曲。
研發(fā)人員和測試人員社搅，通過這部分，能清晰的知道會涉及到哪些系統(tǒng)的交互乳规，哪些信息需要在多個系統(tǒng)間流轉形葬，是以什么方式流轉的，需不需要加密處理等等暮的。
7.效果預期
做任何一個需求笙以，我們都有明確的目的，有了目的還不夠冻辩，我們應當根據(jù)產品的現(xiàn)狀猖腕，對此次需求上線后的效果有一個預期拆祈，效果預期主要通過數(shù)據(jù)層面來體現(xiàn)。
有了效果預期倘感，PDR的讀者就知道在需求上線后缘屹，會對產品帶來多大的變化和影響，在需求實施的時候侠仇，也能更全面的考慮各種情況轻姿。
8.數(shù)據(jù)指標
這部分跟上述效果預期相關聯(lián)，有效果預期以后逻炊，需要有相應的指標來評判效果互亮，因此，需要在PRD中將詳細的數(shù)據(jù)指標列出來余素，以便研發(fā)對數(shù)據(jù)指標的提取進行埋點豹休，以及后續(xù)數(shù)據(jù)提取。
這部分和效果預期常常容易被忽略桨吊，等到需求上線了威根，才發(fā)現(xiàn)需要的數(shù)據(jù)沒有，導致需求效果難以評估视乐，后續(xù)的迭代也沒有數(shù)據(jù)支撐洛搀。
9.PRD迭代記錄
這部分也是容易被忽略的一部分，尤其是核心的產品需求佑淀，在初版需求文檔出來以后留美，沒有后續(xù)的迭代記錄，會導致產品迭代多個版本以后伸刃，不知道早期某些功能是如何考慮谎砾，又是如何一步步演變成今天這個樣子。
PRD從第一版誕生以后捧颅，經過多次需求評審景图，設計評審，詳細設計評審碉哑、用例評審挚币，其中有許多細節(jié)，甚至頁面布局谭梗、功能點都會有變化忘晤，當時可能都是通過郵件、會議紀要來說明激捏，如果不整理到需求文檔中设塔，時間長了，或者是人員變化，可能就沒有人知道這部分需求最終的實現(xiàn)方案了闰蛔。
因此痕钢，PRD迭代記錄也是非常重要的一部分，記錄下每一次討論后需求的變化點序六，幫助各方使用者及時了解需求變化任连，以及對最終的實現(xiàn)方案做記錄，方便后續(xù)查閱例诀。
最后說一下随抠，我理解的PRD的形式，不一定是要寫在word文檔里繁涂，可以在原型圖里來呈現(xiàn)拱她；也不一定要是上述部分全部都有，不同的產品階段扔罪，不同體量的產品包含的內容項可能都會有差異秉沼，只要能說清楚需求要做什么，怎么做矿酵，做完怎么評估效果唬复，就是一份好的PRD。
最后全肮，希望大家都能寫出優(yōu)秀的PRD敞咧，不讓我們的設計師、研發(fā)倔矾、測試妄均，從理解需求階段就折了柱锹！
2017.9.29 帝都
-END-
Miss陳
互聯(lián)網產品經理哪自，喜歡讀書，旅行禁熏；
理財壤巷，成長管理學習中；
有趣的人終將相遇瞧毙！
