产品经理基本功之PRD
作者：@薄荷點點????來源：一個數據人的自留地
PRD (產品需求文檔), 英文全稱是：Product Requirement Document。PRD文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD或BRD中的內容進行指標化和技術化”，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。
產品經理工作中最重要的產出是獨立撰寫一份PRD，這是產品經理的基本功之一。
“PRD寫的好，不一定是好的產品經理，PRD寫的不好，一定不是好的產品經理。”
今天我們就來談談這個基本功的話題——怎么樣寫出一份高質量的PRD。
如果你看完一份PRD也有以下感受：
文檔通篇是各類名詞、頁面功能點跳轉、點擊之類的邏輯；
看完了文檔有一肚子的疑問：為什么要有這個功能，為什么要這么做產品設計；
第一遍頭暈眼花，必須得看第二遍、第三遍才能明白功能之間的關系。
這確實是一份不友好的PRD。
這種PRD產生，主要由于以下兩個問題：
1、產品經理以為沒寫出來的那些內容，研發都已經潛在知曉了、明白了，或者作者打算“PRD評審的時候我會說這些內容的”。
2、產品經理撰寫到PRD里面的，只是自己產品設計的結果，就是用例、功能、交互。
第一個問題——
“想不如說、說不如寫。想不明白肯定也寫不清楚。”
大家可以挑戰一下自己，把那些打算放在評審會說的話，都先寫在PRD里面。
第二個問題——
產品經理把PRD評審當做一次功能宣講，只關注“讓研發需要開發”的功能點（只說結論），忽略了其他也應該同步給項目團隊的其他核心內容以便達成共識，導致開發過程的衍生問題，每次多要事無巨細的去討論、爭論。
這兩個問題如何解呢？先從PRD的作用說起吧。
PRD的作用
作用一：PRD是項目工程人員圍繞其進行技術落地的設計圖紙。
研發根據PRD進行編程開發；
測試根據PRD寫測試用例；
交互設計師根據PRD設計交互稿；
運營人員可以根據PRD提前了解將上線產品的功能，進行推廣計劃；
從這個意義上說，我們應該給出設計細節，還應該給出設計初衷和設計原則。在開發過程中，技術人員面臨著各種細節，如果他們明白產品功能設計的由來，對于一些臨時出現的問題直接從PRD可以找到答案，這能夠幫助他們高效開發（判斷一些細節，避免憑自己的理解猜測產品原意來做決定）。
作用二：PRD是產品經理進行產品設計工作的總結。
PRD除了寫出產品設計結果（頁面是什么樣子的，按鈕觸發什么流程、流程圖是什么樣的），還需要寫產品設計思路（為什么是這樣的設計方案，功能之間是什么關系，對于用戶起什么作用等）。為未來接替你的產品經理可以根據PRD了解目前產品功能細節，為項目留下一份可閱讀意義的文檔。
我對身邊的同學做了一次小范圍的調研，他們告訴我：
什么是優秀的PRD（第1版）
這是各個崗位對一份PRD文檔的感性認識。從中我們可以得到幾個通用的感受：
1、研發：要求細節豐富，不要有遺漏，盡量全面；
2、測試：有必要的Case，所有需要開發的要點，都應該體現在PRD中，減少需求變更；
3、產品：希望文是好文，有骨干（整體框架）、有血肉（概念定義和細節）；
4、交互：希望能看到清晰的信息結構，及未來擴展性。
大家可以先思考如下問題：
這只是數據可視化需求/字段新增需求，需要有系統流程圖嗎？
我這個需求只是一個小迭代，也應該寫整體產品解決方案或思路嗎？
什么是用戶視角的場景化案例/用例，每一個功能的用例都應該詳細寫出來嗎？
帶著這幾個問題，我們再來看：
什么是優秀的PRD（第2版）
如果我們不再把需求文檔看成是產品經理“工作交付”文檔，而是從產品的角度來看PRD本身，PRD的用戶是誰？是產品開發流程的上下游，是項目的各個相關方。
“PRD是產品經理給項目成員講述的故事。好的PRD是能讓人聽一次就記住的好故事。”
寫文檔的過程本質上是做一個“建設”的過程，將對在大腦中對產品設計的各種零散構思進行加工后織成一張網，然后將腦海中網狀的結構輸出到線性展開的文章中。
就像是將Xmind導出的思維導圖，轉化成一篇文檔，不僅需要調整各個部分的順序、還需要加入很多說明細節，這些調整和填充——就是PRD的故事性發揮之地：如何向大家全面講清楚一個需求（從背景到細節）。
我們先來看看作為產品經理的你，是怎么向研發描述需求的日常。
你的開場白是什么？“小哥哥，我們有一個新的想法，想找你幫忙看看，大概占用10分鐘時間，可以么”
開始溝通后，立即介紹背景：“你知道我們之前上線過的甲功能吧”（先確認需求前置信息是否已經同步了）
“這個功能上線后呢，效果還不錯，業務想要進一步增加覆蓋的產品線，然后運營會做全國推廣”（快速說完背景）
“新增產品線，需要在前端界面里面展示，通過點擊一個產品列表展開產品線的內容，新增的產品線在前端顯示的數據字段，和現在線上產品基本是一樣的”（說產品目標）
“線上目前功能不支持多產品線，現在我們的流程是從前臺調用你們中臺，中臺還需要獲取AB這些外圍系統的數據，如果要支持多個產品線，從前臺到中臺都要改”（拋出整體解決方案：涉及哪些系統的修改）
“不過，因為新增的產品線，顯示內容基本一致，所以上下游各系統的改動點是前端調中臺的接口、中臺調用AB外圍系統的接口，都要帶上產品線id，但要注意一下，如果是新增產品【甲】，前臺頁面就不展示金額了，這個邏輯可以前臺做，也可以中臺做，需要技術評估放在哪做比較合適”（說需求細節）
“對于異常情況，目前我想到的異常有：如果A、B外圍系統數據沒更新，會導致新增產品在A或者B外圍系統查不到數據，這種情況中臺不返回值給前端，前端頁面這次就不顯示新增產品的內容”（講異常邏輯）
“我們這個需求還有點急，希望下個月就能全國推廣了，你看看你負責的中臺改動量大不大呢，咱們這部分月底能上嗎”（談排期）
一個這樣的需求描述，研發聽下來很容易就明白要做些什么。
這么講述需求具體好在哪里？
大家知道知乎寫作課的故事八步法嗎？
故事八步法是講怎么寫小說的，解決的是腦子里已經有了畫面但是寫不出文字，或者寫了開頭不知道如何繼續的問題。其實這個情況和我們寫文檔還挺像的，所以這次我們也用一下這個工具：
我們按照這個工具拆解一下剛才和研發小哥哥講述的產品需求：
我們發現和研發小哥哥的需求溝通，不僅覆蓋到了故事核心的幾個要素，還是按照故事發展的線性順序來組織需求描述的，所以聽的人覺得很通順、很好理解。
為什么大家很少會看覺得大部分文檔都沒這么好懂、易讀？
因為向研發面對面講述需求的時候，一切的語言組織都是圍繞著“讓研發聽懂要干啥、為啥干，然后給我排期”為目標的。
但大多數產品經理在寫PRD的時候，首先會拿出PRD模板（有的公司有規定的模板），逐個將細節內容填入模板的各個板塊，反而欠缺了那條故事性展開的脈絡。
大家拿到一個模板，首先要認識到，模板內容并不是要求全部都填好的，模板是公司按照最大公約數情況給大家的一個范例，所以我們也可以利用一個模板來講好“故事”。
我們來看一個案例：
這樣一看，PRD里面有一些核心模塊，是能夠起到很重要的作用的，大家在寫PRD的時候應該認真對待。
那些研發、測試都提到的“注意細節”、“有用例case”，就是故事主干之外的細節了。
一位英雄回家的故事，可以寫成《奧德賽》（荷馬史詩的下部），也可以只是一個大結局結尾的幾句話。差別在于，故事想講的內容（產品解決方案）到底是從英雄開始回家說起，還是以英雄開始回家結束。
現在我們再回過頭來看之前的那幾個思考題，我的答案是：
這只是數據可視化需求/字段新增需求，需要有系統流程圖嗎？
涉及到系統流程改動了嗎？如果是原有系統流程，可以不用放系統流程圖。我這個需求只是一個小迭代，也應該寫整體產品解決方案或思路嗎？
產品的功能點，有時候就是產品解決方案本身。所以小迭代也應該寫。什么是用戶視角的場景化案例，每一個功能的用例都應該詳細寫出來嗎？
涉及到牽涉系統改動的核心功能和異常處理邏輯的，應該寫場景化案例/用例，但是不復雜的輔助功能就不需要寫。判斷的標準是，如果一個用例需要系統的多個流程步驟才能走完，就應該寫，因為這種已經有一定的復雜程度了，需要用一個實際用例把需求內容都串起來，以便讓各方都100%理解無歧義。
就例如白雪公主的童話故事，最激動人心的是白雪公主吃下毒蘋果然后又被救活的情節，但是作者只寫白雪公主吃下毒蘋果后嫁給了王子大結局，這些核心的步驟都省略了，讓這個故事有爛尾之嫌。
總結
以上是生活随笔為你收集整理的产品经理基本功之PRD的全部內容，希望文章能夠幫你解決所遇到的問題。
