文檔能力是產(chǎn)品經(jīng)理必備的基本能力。
文檔能力是產(chǎn)品經(jīng)理必備的基本能力，產(chǎn)品經(jīng)理通過文檔的方式把需求轉(zhuǎn)化為功能傳遞給項目的相關(guān)人員，使相關(guān)人員更好的理解功能需求。所以文檔的好壞直接影響到團(tuán)隊成員對需求的理解程度。
剛?cè)胄械漠a(chǎn)品新人都會優(yōu)先學(xué)習(xí)產(chǎn)品需求文檔（下面會用PRD代替）的撰寫和原型的繪制，自己當(dāng)時也是一樣。當(dāng)時看了很多產(chǎn)品需求文檔的案例，各種類型、格式的產(chǎn)品文檔都研究過。然后在主流的幾個文檔格式中選擇Axure原型來撰寫PRD，因為Axure做的原型需求文檔，與讀者之間有互動，體驗更加良好而不至于那么單調(diào)。
下面我會通過以下7個方面來對新版PRD進(jìn)行詳細(xì)說明。（文章末尾附有PRD模板Axure文件的下載地址。）
文檔命名
文檔結(jié)構(gòu)
產(chǎn)品概述
全局說明
流程圖
功能需求
非功能需求
文檔命名
文件的命名，只要能告訴別人這個文檔的所包含的必要信息就可以了。對PRD而言，需要讓別人知道這個文檔是什么產(chǎn)品的產(chǎn)品需求文檔，處于什么階段，比如PRD_產(chǎn)品名稱_V1.0.0。不過為了更好的進(jìn)行統(tǒng)一管理，這里使用采用了下面的方式來對文件名進(jìn)行命名。
文檔命名規(guī)則：【PRD】+ 產(chǎn)品名稱 + 產(chǎn)品版本號
例如：【PRD】微信 V6.6.1
文檔結(jié)構(gòu)
PRD的內(nèi)部結(jié)構(gòu)，如下圖所示。
主要包含產(chǎn)品概述、全局說明、流程圖、功能需求與非功能需求這5大模塊，每個模塊下方有對應(yīng)的子模塊，下面進(jìn)行詳細(xì)的介紹。
產(chǎn)品概述
產(chǎn)品概述模塊是用于展示產(chǎn)品介紹、開發(fā)規(guī)劃以及文檔修訂歷史等基本內(nèi)容。主要有4個部分：
修訂歷史
開發(fā)周期
產(chǎn)品版本說明
產(chǎn)品介紹
首先來看看修訂歷史。
修訂歷史
修訂歷史是展示PRD的修改記錄，里面記錄著產(chǎn)品經(jīng)理對PRD的修訂的方式以及修訂的內(nèi)容。一般會放在文檔的第一頁，方便團(tuán)隊成員第一時間了解到需求是否有改動。而修訂歷史一般會采用表格的形式展示，包含文檔的版本號、修訂日期、修訂方式、修訂人以及修訂內(nèi)容。
開發(fā)周期
開發(fā)周期包含兩個模塊，分別是開發(fā)周期以及開發(fā)計劃。
從上圖可以看出，在開發(fā)周期表格中，顯示項目的計劃開發(fā)時間。不同的平臺開發(fā)難度不同，所以這里也會加以區(qū)分。下方的則是開發(fā)計劃，在敏捷開發(fā)中，都會以一個時間區(qū)間作為迭代的里程碑，小步快跑，一步步完成迭代上線。比如說一個移動App，開發(fā)的第一階段首先要進(jìn)行框架的搭建、啟動頁、登錄注冊等基本功能的開發(fā)，然后再按照計劃、優(yōu)先級開發(fā)后續(xù)的功能。
產(chǎn)品版本說明
版本說明只是展示產(chǎn)品對應(yīng)版本所包含的核心功能。需要注意的是，這個版本是以上線版本為基準(zhǔn)，需要與上面開發(fā)周期所說的版本需要區(qū)分開來。
產(chǎn)品介紹
顯示產(chǎn)品的相關(guān)介紹，常見的字段有產(chǎn)品名稱、logo、slogen、產(chǎn)品簡介、產(chǎn)品定位、目標(biāo)人群、使用場景以及產(chǎn)品目標(biāo)等。有個別產(chǎn)品可能還需要顯示其他的信息，具體以實際情況為準(zhǔn)。
全局說明
全局說明則是對產(chǎn)品中公共部分的控件、文案、網(wǎng)路請求狀態(tài)顯示等進(jìn)行統(tǒng)一的說明。全局說明這部分會因產(chǎn)品不同而變動較大，所以也需要根據(jù)實際情況而定。
流程圖
流程圖在這個PRD中是比較重要的模塊，其中的邏輯性較強(qiáng)，最能反應(yīng)出產(chǎn)品經(jīng)理的邏輯思維能力與流程圖的繪制能力。
在文檔中，流程圖中包含信息結(jié)構(gòu)圖、功能結(jié)構(gòu)圖、業(yè)務(wù)流程圖以及任務(wù)流程圖（也就是功能流程圖）。
其中信息結(jié)構(gòu)圖和功能結(jié)構(gòu)圖可以使用Xmind、MindManager、百度腦圖等工具進(jìn)行繪制；而業(yè)務(wù)流程圖、任務(wù)流程圖則可以使用Visio、OmniGraffle、ProcessOn等工具進(jìn)行繪制，然后導(dǎo)入到PRD。如果業(yè)務(wù)涉及到多端、多用戶角色的產(chǎn)品，可以使用泳道圖。流程圖的具體的繪制大家可以參考woshipm社區(qū)下的《實例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖》
功能需求
功能需求模塊是整個PRD中最重要的部分，這個模塊是對功能的詳細(xì)說明。先看看功能需求下的三個子模塊：
功能列表
該頁面展示了整個產(chǎn)品的所有功能，一般采用列表的形式展示，通常包含字段有模塊、功能名稱、功能描述以及優(yōu)先級。在這里額外添加了一項階段安排，通過顏色的刺激程度來區(qū)分功能的開發(fā)階段。
產(chǎn)品線路圖
產(chǎn)品線路圖與上述所說的功能結(jié)構(gòu)圖十分類似，只不過功能結(jié)構(gòu)圖是以功能為單位，而線路圖則是以頁面為單位。產(chǎn)品線路圖展示了產(chǎn)品的所有頁面以及對應(yīng)連接關(guān)系。我們可以通過點(diǎn)擊線路圖中的矩形節(jié)點(diǎn)，跳轉(zhuǎn)到對應(yīng)的功能詳情。
功能詳情
這個是我們的開發(fā)人員、設(shè)計師、測試人員使用最多的一個模塊，沒有之一。該模塊展示的是功能頁面的詳細(xì)信息，主要有功能頁面的描述、流程說明以及異常情況處理。
以啟動頁為例說明一下。主要包含4個部分，分別是原型圖、頁面簡介、界面描述和用戶用例。其中界面描述是對原型圖中的元素進(jìn)行詳細(xì)的解釋。用戶用例則是對用戶的使用流程、備選流程以及異常流程情況的說明。不過并不是每個頁面都會有用戶用例這個部分，一些簡單的展示界面、沒有用戶行為的頁面，就可以不做用戶用例。
通過功能詳情的一些細(xì)節(jié)描述和用戶用例的思考，可以大大減少產(chǎn)品經(jīng)理對功能思考的遺漏點(diǎn)。
非功能需求
不同產(chǎn)品有不同的非功能性需求，一般有以下幾類非功能性需求。
性能需求
統(tǒng)計需求
營銷需求
法務(wù)需求
質(zhì)量需求
安全需求
運(yùn)營需求
財務(wù)需求
上面的列舉的非功能需求就不一一說明了，每個產(chǎn)品都不一樣，需要根據(jù)具體產(chǎn)品、具體情況而定。
總結(jié)
其實PRD的撰寫與迭代，可以看做是一個產(chǎn)品的設(shè)計與迭代的過程。所以我們在PRD迭代更新的過程中，要明確團(tuán)隊的實際需求，找出痛點(diǎn)、分析問題、得出解決方案、然后實施并驗證方案的正確性。
以上產(chǎn)品需求文檔是結(jié)合團(tuán)隊的流程總結(jié)出來的，雖然并不完美，但是很好的滿足當(dāng)前團(tuán)隊的需求，基本上符合當(dāng)前敏捷開發(fā)團(tuán)隊的使用，后續(xù)也會不斷改進(jìn)優(yōu)化。每個團(tuán)隊也會因情況不同而需求不一樣，所以也僅供參考。
不過需要明確一點(diǎn)的是，PRD只是一個幫助PM傳遞想法和需求的工具，一個輔助手段，并不是目的，所以核心還是在需求上。或許到了團(tuán)隊的后期，團(tuán)隊成員能力都很強(qiáng)、都很默契，基本上可以通過口頭溝通完成信息傳遞時，那么產(chǎn)品需求文檔也就不那么重要了。（嗯，比較理想…）
