今天和大家聊一聊工作中最常見的產品需求文檔，雖然各平臺上講PRD的文章很多，但我還是想分享一下我寫PRD的心得。
方便閱讀，大家先了解一下文章結構：
一、PRD概述
1. 什麼是PRD?
PRD在百度百科中的官方解釋為：PRD為Product Requirement Document的簡稱，其中文翻譯為：產品需求文檔。該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔。
當然，這個定義針對的是一個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標用戶、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等。
我對PRD的正經理解為：在一個群體內一個相互達成共識並形成規範的描述需求的東西。它的形式可以是word文檔，可以是Axure原型，也可以是一段視頻等等，只要我們能把我們的需求清楚無歧義的向使用對象表達清楚即可。
我對PRD的歪解為：產品自我梳理的甲冑，與開發撕逼的武器。每一次產品經理寫PRD都是對產品進行再次梳理，以前很多沒想清楚的地方，寫著寫著就明瞭了；若不寫文檔讓開發做，做出來的產品效果不理想誰來負責呢，若這時候有產品文檔則有蹤可尋，產品就不用當背鍋俠啦。
2. PRD誰來寫？
PRD正常是產品經理來寫的，但有時候需求方（運營、市場等）也會直接出需求文檔。
3. PRD給誰看
PRD的主要使用對象有：開發、測試、項目經理、UI設計師、交互設計師、運營及其他業務人員。
開發根據PRD獲知整個產品的邏輯；測試根據PRD建用例；項目經理根據PRD拆分工作包，並分配開發人員；交互設計師可以通過PRD來設計交互細節。PRD是項目啟動之前，必須要通過評審確定的最重要文檔。
二、如何寫好PRD？
一份可讀性高的文檔遵循的基本原則為：文檔結構有分類，事無鉅細要詳盡，語義精準無歧義，文圖搭配更易讀。
1. 文檔結構有分類
一份PRD就是一個小產品，搭建一個有層次有分類的文檔結構可以幫助閱讀者快速瞭解文檔的思路及容易閱讀。
一般我寫APP產品的文檔時，根據模塊-子模塊-功能-子功能-頁面的結構來搭建產品結構。描述頁面需求時順序：從左到右，從上到下；先講正常狀態流程，再講異常狀態流程。
例如常見的產品模塊中有：流程圖、產品功能需求描述、用戶角色描述、產品邏輯說明等等。每一個模塊下面又可進行很多的分類，例如：產品邏輯說明可分為功能邏輯、交互邏輯、視覺邏輯、技術邏輯、業務邏輯；流程圖可分為業務流程圖、頁面流程圖、任務流程圖等等。
2. 事無鉅細要詳盡
詳盡意味著我們在文檔內要把產品裡可能發生的一切情況描述出來，包含頁面邏輯、交互邏輯、數據邏輯等等。
經常我們在寫文檔時，會出現這樣一個情況，我們認為很常見很簡單的邏輯，開發測試他們肯定都懂，那就不寫了吧，然後這個地方開發的時候就出問題了，為什麼常見簡單的邏輯能出現疑義呢？
例如：之前在做一個年份選擇功能時，我就簡單的寫了一個需求：年份從XX裡集成出來，根據時間排序。我以為開發做出來要麼升序，要麼降序，我都能接受。結果……
一千個讀者，就有一千個哈姆雷特。
我們寫文檔的時候是站在產品的角度來看這份文檔的，那麼站在技術或測試的角度來看呢？
由於產品的功能或方案都是我們產品設計的，我們很清楚功能邏輯的關聯，而技術、測試沒有參與到方案的產出中來，所以他們就不清楚方案中的一些定義。
例如：之前做一個廣場發佈圖書的功能時，添加圖書頁與另外一個功能中借閱的書頁極其相似，於是我就偷懶了，在寫添加圖書頁面的需求時，就簡單寫到頁面參照借閱的書頁，而這兩個頁面的開發分別是不同程序小哥寫的，於是寫添加圖書頁面的程序小哥又把我抓過去重新擼了一遍圖書排序、排序、及異常情況的需求，最終我還是把添加圖書頁的需求重新寫了一遍。
如何詳盡各種情況？
剛開始做產品寫文檔時，我經常也會漏寫很多的特殊情況，那時候被開發和測試拉到牆角懟得呀，提需求都只能蹲著提。後面研讀測試用例後，瞭解了測試用例中描述的各種情況，後面在寫的時候就採取測試思維，來檢查文檔中是否將產品中會遇到的問題都描述出來了。
3. 語義精準無歧義
語義精準包含兩個層面的內容。
一是產品文檔中避免出現概念模糊的詞彙，如：似乎、好像、大概、可能、應該等等詞彙，應該說一為一，不要給閱讀者留下遐想的空間。
二是避免多個詞彙定義同個東西。例如：常見的搜索欄，如果一開始就定義叫做搜索欄，那麼在後文中，不可再給它取其他的名字，如搜索框、搜索條等等。
4. 文圖搭配更易讀
一份PRD文檔內，肯定包含了大量文字描述，但是我們能用圖表的地方，儘量用圖表。一個圖或者一個表通過少量的元素能傳遞大量信息，圖表可將複雜的關聯性可視化呈現，幫助讀者快速理解內在邏輯。
例如註冊流程的介紹，畫一個簡易的流程圖比寫個200字的需求易懂。
文末再說兩句，寫PRD的目的在於降低團隊溝通成本，統一將團隊認知，推動產品順利上線，不要因為偷懶而不寫PRD文檔。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
