今天和大家聊一聊工作中最常見的產(chǎn)品需求文檔，雖然各平臺(tái)上講PRD的文章很多，但我還是想分享一下我寫PRD的心得。

方便閱讀，大家先了解一下文章結(jié)構(gòu)：

一、PRD概述

1. 什么是PRD?

PRD在百度百科中的官方解釋為：PRD為Product Requirement Document的簡稱，其中文翻譯為：產(chǎn)品需求文檔。該文檔是產(chǎn)品項(xiàng)目由“概念化”階段進(jìn)入到“圖紙化”階段的最主要的一個(gè)文檔。

當(dāng)然，這個(gè)定義針對(duì)的是一個(gè)全新的產(chǎn)品。廣義上來講，產(chǎn)品需求的描述，應(yīng)該包含有產(chǎn)品的戰(zhàn)略和戰(zhàn)術(shù)，戰(zhàn)略是指：產(chǎn)品定位、目標(biāo)市場、目標(biāo)用戶、競爭對(duì)手等。戰(zhàn)術(shù)是指產(chǎn)品的結(jié)構(gòu)、核心業(yè)務(wù)流程、具體用例描述、功能&內(nèi)容描述等。

我對(duì)PRD的正經(jīng)理解為：在一個(gè)群體內(nèi)一個(gè)相互達(dá)成共識(shí)并形成規(guī)范的描述需求的東西。它的形式可以是word文檔，可以是Axure原型，也可以是一段視頻等等，只要我們能把我們的需求清楚無歧義的向使用對(duì)象表達(dá)清楚即可。

我對(duì)PRD的歪解為：產(chǎn)品自我梳理的甲胄，與開發(fā)撕逼的武器。每一次產(chǎn)品經(jīng)理寫PRD都是對(duì)產(chǎn)品進(jìn)行再次梳理，以前很多沒想清楚的地方，寫著寫著就明了了；若不寫文檔讓開發(fā)做，做出來的產(chǎn)品效果不理想誰來負(fù)責(zé)呢，若這時(shí)候有產(chǎn)品文檔則有蹤可尋，產(chǎn)品就不用當(dāng)背鍋俠啦。

2. PRD誰來寫？

PRD正常是產(chǎn)品經(jīng)理來寫的，但有時(shí)候需求方（運(yùn)營、市場等）也會(huì)直接出需求文檔。

3. PRD給誰看

PRD的主要使用對(duì)象有：開發(fā)、測試、項(xiàng)目經(jīng)理、UI設(shè)計(jì)師、交互設(shè)計(jì)師、運(yùn)營及其他業(yè)務(wù)人員。

開發(fā)根據(jù)PRD獲知整個(gè)產(chǎn)品的邏輯；測試根據(jù)PRD建用例；項(xiàng)目經(jīng)理根據(jù)PRD拆分工作包，并分配開發(fā)人員；交互設(shè)計(jì)師可以通過PRD來設(shè)計(jì)交互細(xì)節(jié)。PRD是項(xiàng)目啟動(dòng)之前，必須要通過評(píng)審確定的最重要文檔。

二、如何寫好PRD？

一份可讀性高的文檔遵循的基本原則為：文檔結(jié)構(gòu)有分類，事無巨細(xì)要詳盡，語義精準(zhǔn)無歧義，文圖搭配更易讀。

1. 文檔結(jié)構(gòu)有分類

一份PRD就是一個(gè)小產(chǎn)品，搭建一個(gè)有層次有分類的文檔結(jié)構(gòu)可以幫助閱讀者快速了解文檔的思路及容易閱讀。

一般我寫APP產(chǎn)品的文檔時(shí)，根據(jù)模塊-子模塊-功能-子功能-頁面的結(jié)構(gòu)來搭建產(chǎn)品結(jié)構(gòu)。描述頁面需求時(shí)順序：從左到右，從上到下；先講正常狀態(tài)流程，再講異常狀態(tài)流程。

例如常見的產(chǎn)品模塊中有：流程圖、產(chǎn)品功能需求描述、用戶角色描述、產(chǎn)品邏輯說明等等。每一個(gè)模塊下面又可進(jìn)行很多的分類，例如：產(chǎn)品邏輯說明可分為功能邏輯、交互邏輯、視覺邏輯、技術(shù)邏輯、業(yè)務(wù)邏輯；流程圖可分為業(yè)務(wù)流程圖、頁面流程圖、任務(wù)流程圖等等。

2. 事無巨細(xì)要詳盡

詳盡意味著我們在文檔內(nèi)要把產(chǎn)品里可能發(fā)生的一切情況描述出來，包含頁面邏輯、交互邏輯、數(shù)據(jù)邏輯等等。

經(jīng)常我們在寫文檔時(shí)，會(huì)出現(xiàn)這樣一個(gè)情況，我們認(rèn)為很常見很簡單的邏輯，開發(fā)測試他們肯定都懂，那就不寫了吧，然后這個(gè)地方開發(fā)的時(shí)候就出問題了，為什么常見簡單的邏輯能出現(xiàn)疑義呢？

例如：之前在做一個(gè)年份選擇功能時(shí)，我就簡單的寫了一個(gè)需求：年份從XX里集成出來，根據(jù)時(shí)間排序。我以為開發(fā)做出來要么升序，要么降序，我都能接受。結(jié)果……

一千個(gè)讀者，就有一千個(gè)哈姆雷特。

我們寫文檔的時(shí)候是站在產(chǎn)品的角度來看這份文檔的，那么站在技術(shù)或測試的角度來看呢？

由于產(chǎn)品的功能或方案都是我們產(chǎn)品設(shè)計(jì)的，我們很清楚功能邏輯的關(guān)聯(lián)，而技術(shù)、測試沒有參與到方案的產(chǎn)出中來，所以他們就不清楚方案中的一些定義。

例如：之前做一個(gè)廣場發(fā)布圖書的功能時(shí)，添加圖書頁與另外一個(gè)功能中借閱的書頁極其相似，于是我就偷懶了，在寫添加圖書頁面的需求時(shí)，就簡單寫到頁面參照借閱的書頁，而這兩個(gè)頁面的開發(fā)分別是不同程序小哥寫的，于是寫添加圖書頁面的程序小哥又把我抓過去重新擼了一遍圖書排序、排序、及異常情況的需求，最終我還是把添加圖書頁的需求重新寫了一遍。

如何詳盡各種情況？

剛開始做產(chǎn)品寫文檔時(shí)，我經(jīng)常也會(huì)漏寫很多的特殊情況，那時(shí)候被開發(fā)和測試?yán)綁菓坏醚?，提需求都只能蹲著提。后面研讀測試用例后，了解了測試用例中描述的各種情況，后面在寫的時(shí)候就采取測試思維，來檢查文檔中是否將產(chǎn)品中會(huì)遇到的問題都描述出來了。

3. 語義精準(zhǔn)無歧義

語義精準(zhǔn)包含兩個(gè)層面的內(nèi)容。

一是產(chǎn)品文檔中避免出現(xiàn)概念模糊的詞匯，如：似乎、好像、大概、可能、應(yīng)該等等詞匯，應(yīng)該說一為一，不要給閱讀者留下遐想的空間。

二是避免多個(gè)詞匯定義同個(gè)東西。例如：常見的搜索欄，如果一開始就定義叫做搜索欄，那么在后文中，不可再給它取其他的名字，如搜索框、搜索條等等。

4. 文圖搭配更易讀

一份PRD文檔內(nèi)，肯定包含了大量文字描述，但是我們能用圖表的地方，盡量用圖表。一個(gè)圖或者一個(gè)表通過少量的元素能傳遞大量信息，圖表可將復(fù)雜的關(guān)聯(lián)性可視化呈現(xiàn)，幫助讀者快速理解內(nèi)在邏輯。

例如注冊流程的介紹，畫一個(gè)簡易的流程圖比寫個(gè)200字的需求易懂。

文末再說兩句，寫PRD的目的在于降低團(tuán)隊(duì)溝通成本，統(tǒng)一將團(tuán)隊(duì)認(rèn)知，推動(dòng)產(chǎn)品順利上線，不要因?yàn)橥祽卸粚慞RD文檔。

作者：阿言，個(gè)人微信PM-chef；公眾號(hào)：PM-Ayan

本文由 @阿言 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。