PRD (產(chǎn)品需求文檔), 英文全稱是：Product Requirement Document。PRD文檔是產(chǎn)品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD或BRD中的內(nèi)容進行指標化和技術(shù)化”，這個文檔的質(zhì)量好壞直接影響到研發(fā)部門是否能夠明確產(chǎn)品的功能和性能。

產(chǎn)品經(jīng)理工作中最重要的產(chǎn)出是獨立撰寫一份PRD，這是產(chǎn)品經(jīng)理的基本功之一。

怎么理解PRD

產(chǎn)品需求文檔，即Product Requirement Document

是產(chǎn)品經(jīng)理能力基礎(chǔ)中的基礎(chǔ)

是從產(chǎn)品規(guī)劃到產(chǎn)品設(shè)計階段的里程碑式綜合產(chǎn)出物

“PRD寫的好，不一定是好的產(chǎn)品經(jīng)理，PRD寫的不好，一定不是好的產(chǎn)品經(jīng)理?！?/strong>

今天我們就來談?wù)勥@個基本功的話題——怎么樣寫出一份高質(zhì)量的PRD。

如果你看完一份PRD也有以下感受：

• 文檔通篇是各類名詞、頁面功能點跳轉(zhuǎn)、點擊之類的邏輯；
• 看完了文檔有一肚子的疑問：為什么要有這個功能，為什么要這么做產(chǎn)品設(shè)計；
• 第一遍頭暈眼花，必須得看第二遍、第三遍才能明白功能之間的關(guān)系。

這確實是一份不友好的PRD。

這種PRD產(chǎn)生，主要由于以下兩個問題：

1、產(chǎn)品經(jīng)理以為沒寫出來的那些內(nèi)容，研發(fā)都已經(jīng)潛在知曉了、明白了，或者作者打算“PRD評審的時候我會說這些內(nèi)容的”。

2、產(chǎn)品經(jīng)理撰寫到PRD里面的，只是自己產(chǎn)品設(shè)計的結(jié)果，就是用例、功能、交互。

第一個問題——

“想不如說、說不如寫。想不明白肯定也寫不清楚?！?/strong>

大家可以挑戰(zhàn)一下自己，把那些打算放在評審會說的話，都先寫在PRD里面。

第二個問題——

產(chǎn)品經(jīng)理把PRD評審當做一次功能宣講，只關(guān)注“讓研發(fā)需要開發(fā)”的功能點（只說結(jié)論），忽略了其他也應(yīng)該同步給項目團隊的其他核心內(nèi)容以便達成共識，導(dǎo)致開發(fā)過程的衍生問題，每次多要事無巨細的去討論、爭論。

這兩個問題如何解呢？先從PRD的作用說起吧。

PRD的作用

作用一：PRD是項目工程人員圍繞其進行技術(shù)落地的設(shè)計圖紙。

• 研發(fā)根據(jù)PRD進行編程開發(fā)；
• 測試根據(jù)PRD寫測試用例；
• 交互設(shè)計師根據(jù)PRD設(shè)計交互稿；
• 運營人員可以根據(jù)PRD提前了解將上線產(chǎn)品的功能，進行推廣計劃；

從這個意義上說，我們應(yīng)該給出設(shè)計細節(jié)，還應(yīng)該給出設(shè)計初衷和設(shè)計原則。在開發(fā)過程中，技術(shù)人員面臨著各種細節(jié)，如果他們明白產(chǎn)品功能設(shè)計的由來，對于一些臨時出現(xiàn)的問題直接從PRD可以找到答案，這能夠幫助他們高效開發(fā)（判斷一些細節(jié)，避免憑自己的理解猜測產(chǎn)品原意來做決定）。

作用二：PRD是產(chǎn)品經(jīng)理進行產(chǎn)品設(shè)計工作的總結(jié)。

PRD除了寫出產(chǎn)品設(shè)計結(jié)果（頁面是什么樣子的，按鈕觸發(fā)什么流程、流程圖是什么樣的），還需要寫產(chǎn)品設(shè)計思路（為什么是這樣的設(shè)計方案，功能之間是什么關(guān)系，對于用戶起什么作用等）。為未來接替你的產(chǎn)品經(jīng)理可以根據(jù)PRD了解目前產(chǎn)品功能細節(jié)，為項目留下一份可閱讀意義的文檔。

梳理PRD怎么寫，無法脫離于項目流程單獨思考，需要帶入流程

再來看這張圖

項目的流程大同小異，在做好需求評審前的各個環(huán)節(jié)之后，你自然會積累從抽象逐漸到具體的一系列文檔內(nèi)容。此時將它們進行整理，做匯總提煉，補充顆粒度更細的內(nèi)容即可

一順百順一損俱損

從項目的維度拆解PRD的組成后，可以發(fā)現(xiàn)，前面的每一個環(huán)節(jié)做的越完善，在撰寫PRD的時候越能降本增效

在撰寫PRD出現(xiàn)問題時，也可以追本溯源根據(jù)內(nèi)容部分找到對應(yīng)的環(huán)節(jié)，定位問題從而找到解決方案

所以PRD到底怎么寫，如果你把問題定位在“怎么寫PRD”這個顆粒度，你能找到的大部分內(nèi)容大致是一下3種

1. 模板+簡要的講解
2. 從各種角度切入，或重新解讀或填充某部分的細節(jié)
3. 長篇幅的系列文章

多看第三種，更有可能通過結(jié)論找到思考路徑

但是這些都是被動的做法，你只能去碰，找到能給你啟發(fā)適合你應(yīng)用的內(nèi)容的概率

主動的做法是，拆解→定位→聚焦

我對身邊的同學(xué)做了一次小范圍的調(diào)研，他們告訴我：

什么是優(yōu)秀的PRD（第1版）

這是各個崗位對一份PRD文檔的感性認識。從中我們可以得到幾個通用的感受：

1、研發(fā)：要求細節(jié)豐富，不要有遺漏，盡量全面；

2、測試：有必要的Case，所有需要開發(fā)的要點，都應(yīng)該體現(xiàn)在PRD中，減少需求變更；

3、產(chǎn)品：希望文是好文，有骨干（整體框架）、有血肉（概念定義和細節(jié)）；

4、交互：希望能看到清晰的信息結(jié)構(gòu)，及未來擴展性。

大家可以先思考如下問題：

• 這只是數(shù)據(jù)可視化需求/字段新增需求，需要有系統(tǒng)流程圖嗎？
• 我這個需求只是一個小迭代，也應(yīng)該寫整體產(chǎn)品解決方案或思路嗎？
• 什么是用戶視角的場景化案例/用例，每一個功能的用例都應(yīng)該詳細寫出來嗎？

帶著這幾個問題，我們再來看：

什么是優(yōu)秀的PRD（第2版）

如果我們不再把需求文檔看成是產(chǎn)品經(jīng)理“工作交付”文檔，而是從產(chǎn)品的角度來看PRD本身，PRD的用戶是誰？是產(chǎn)品開發(fā)流程的上下游，是項目的各個相關(guān)方。

“PRD是產(chǎn)品經(jīng)理給項目成員講述的故事。好的PRD是能讓人聽一次就記住的好故事。”

寫文檔的過程本質(zhì)上是做一個“建設(shè)”的過程，將對在大腦中對產(chǎn)品設(shè)計的各種零散構(gòu)思進行加工后織成一張網(wǎng)，然后將腦海中網(wǎng)狀的結(jié)構(gòu)輸出到線性展開的文章中。

就像是將Xmind導(dǎo)出的思維導(dǎo)圖，轉(zhuǎn)化成一篇文檔，不僅需要調(diào)整各個部分的順序、還需要加入很多說明細節(jié)，這些調(diào)整和填充——就是PRD的故事性發(fā)揮之地：如何向大家全面講清楚一個需求（從背景到細節(jié)）。

我們先來看看作為產(chǎn)品經(jīng)理的你，是怎么向研發(fā)描述需求的日常。

你的開場白是什么？“小哥哥，我們有一個新的想法，想找你幫忙看看，大概占用10分鐘時間，可以么”

開始溝通后，立即介紹背景：“你知道我們之前上線過的甲功能吧”（先確認需求前置信息是否已經(jīng)同步了）

“這個功能上線后呢，效果還不錯，業(yè)務(wù)想要進一步增加覆蓋的產(chǎn)品線，然后運營會做全國推廣”（快速說完背景）

“新增產(chǎn)品線，需要在前端界面里面展示，通過點擊一個產(chǎn)品列表展開產(chǎn)品線的內(nèi)容，新增的產(chǎn)品線在前端顯示的數(shù)據(jù)字段，和現(xiàn)在線上產(chǎn)品基本是一樣的”（說產(chǎn)品目標）

“線上目前功能不支持多產(chǎn)品線，現(xiàn)在我們的流程是從前臺調(diào)用你們中臺，中臺還需要獲取AB這些外圍系統(tǒng)的數(shù)據(jù)，如果要支持多個產(chǎn)品線，從前臺到中臺都要改”（拋出整體解決方案：涉及哪些系統(tǒng)的修改）

“不過，因為新增的產(chǎn)品線，顯示內(nèi)容基本一致，所以上下游各系統(tǒng)的改動點是前端調(diào)中臺的接口、中臺調(diào)用AB外圍系統(tǒng)的接口，都要帶上產(chǎn)品線id，但要注意一下，如果是新增產(chǎn)品【甲】，前臺頁面就不展示金額了，這個邏輯可以前臺做，也可以中臺做，需要技術(shù)評估放在哪做比較合適”（說需求細節(jié)）

“對于異常情況，目前我想到的異常有：如果A、B外圍系統(tǒng)數(shù)據(jù)沒更新，會導(dǎo)致新增產(chǎn)品在A或者B外圍系統(tǒng)查不到數(shù)據(jù)，這種情況中臺不返回值給前端，前端頁面這次就不顯示新增產(chǎn)品的內(nèi)容”（講異常邏輯）

“我們這個需求還有點急，希望下個月就能全國推廣了，你看看你負責(zé)的中臺改動量大不大呢，咱們這部分月底能上嗎”（談排期）

一個這樣的需求描述，研發(fā)聽下來很容易就明白要做些什么。

這么講述需求具體好在哪里？

大家知道知乎寫作課的故事八步法嗎？

故事八步法是講怎么寫小說的，解決的是腦子里已經(jīng)有了畫面但是寫不出文字，或者寫了開頭不知道如何繼續(xù)的問題。其實這個情況和我們寫文檔還挺像的，所以這次我們也用一下這個工具：

我們按照這個工具拆解一下剛才和研發(fā)小哥哥講述的產(chǎn)品需求：

我們發(fā)現(xiàn)和研發(fā)小哥哥的需求溝通，不僅覆蓋到了故事核心的幾個要素，還是按照故事發(fā)展的線性順序來組織需求描述的，所以聽的人覺得很通順、很好理解。

為什么大家很少會看覺得大部分文檔都沒這么好懂、易讀？

因為向研發(fā)面對面講述需求的時候，一切的語言組織都是圍繞著“讓研發(fā)聽懂要干啥、為啥干，然后給我排期”為目標的。

但大多數(shù)產(chǎn)品經(jīng)理在寫PRD的時候，首先會拿出PRD模板（有的公司有規(guī)定的模板），逐個將細節(jié)內(nèi)容填入模板的各個板塊，反而欠缺了那條故事性展開的脈絡(luò)。

大家拿到一個模板，首先要認識到，模板內(nèi)容并不是要求全部都填好的，模板是公司按照最大公約數(shù)情況給大家的一個范例，所以我們也可以利用一個模板來講好“故事”。

我們來看一個案例：

這樣一看，PRD里面有一些核心模塊，是能夠起到很重要的作用的，大家在寫PRD的時候應(yīng)該認真對待。

那些研發(fā)、測試都提到的“注意細節(jié)”、“有用例case”，就是故事主干之外的細節(jié)了。

一位英雄回家的故事，可以寫成《奧德賽》（荷馬史詩的下部），也可以只是一個大結(jié)局結(jié)尾的幾句話。差別在于，故事想講的內(nèi)容（產(chǎn)品解決方案）到底是從英雄開始回家說起，還是以英雄開始回家結(jié)束。

現(xiàn)在我們再回過頭來看之前的那幾個思考題，我的答案是：

• 這只是數(shù)據(jù)可視化需求/字段新增需求，需要有系統(tǒng)流程圖嗎？
  涉及到系統(tǒng)流程改動了嗎？如果是原有系統(tǒng)流程，可以不用放系統(tǒng)流程圖。
• 我這個需求只是一個小迭代，也應(yīng)該寫整體產(chǎn)品解決方案或思路嗎？
  產(chǎn)品的功能點，有時候就是產(chǎn)品解決方案本身。所以小迭代也應(yīng)該寫。
• 什么是用戶視角的場景化案例，每一個功能的用例都應(yīng)該詳細寫出來嗎？
  涉及到牽涉系統(tǒng)改動的核心功能和異常處理邏輯的，應(yīng)該寫場景化案例/用例，但是不復(fù)雜的輔助功能就不需要寫。判斷的標準是，如果一個用例需要系統(tǒng)的多個流程步驟才能走完，就應(yīng)該寫，因為這種已經(jīng)有一定的復(fù)雜程度了，需要用一個實際用例把需求內(nèi)容都串起來，以便讓各方都100%理解無歧義。

就例如白雪公主的童話故事，最激動人心的是白雪公主吃下毒蘋果然后又被救活的情節(jié)，但是作者只寫白雪公主吃下毒蘋果后嫁給了王子大結(jié)局，這些核心的步驟都省略了，讓這個故事有爛尾之嫌。

作者：薄荷點點