文檔能力是產(chǎn)品經(jīng)理必備的基本能力椭员，產(chǎn)品經(jīng)理通過文檔的方式把需求傳遞給項目的相關(guān)人員足画，使相關(guān)人員更好的理解需求浑彰。所以文檔的好壞直接影響到團隊成員對需求的理解程度拾积。
所以剛?cè)胄械漠a(chǎn)品新人都會優(yōu)先學(xué)習(xí)產(chǎn)品需求文檔（下面會用PRD代替）的撰寫和原型的繪制，自己當時也是一樣植影。當時看了很多產(chǎn)品需求文檔的案例裳擎，各種類型、格式的產(chǎn)品文檔都研究過思币。然后在主流的幾個文檔格式中選擇Axure原型來撰寫PRD鹿响，因為Axure做的原型需求文檔，與讀者之間有互動谷饿，體驗更加良好而不至于那么單調(diào)惶我。
產(chǎn)品需求文檔初成型
剛開始時，在網(wǎng)上的一些模板并結(jié)合實際項目來撰寫PRD的博投，并且PRD和原型圖是完全分開的绸贡，也就是說第一次撰寫的PRD只包含一些基本的和公共的信息，比如文檔的修訂歷史、產(chǎn)品說明听怕、版本介紹以及核心的流程圖捧挺。其他的細節(jié)信息則是通過在原型圖上進行簡要的標注。
后來經(jīng)歷過幾次的項目開發(fā)和迭代之后尿瞭，發(fā)現(xiàn)PRD與原型圖分開管理的方式制作起來十分繁瑣闽烙，并且一些小版本的更新很經(jīng)常會直接在原型圖上做更新而忘了更新PRD。而且開發(fā)人員声搁、設(shè)計師基本上只看原型圖黑竞，不看PRD，遇到需求問題就直接問PM疏旨，這樣就失去了產(chǎn)品需求文檔的意義了很魂。
后來就決定把原型圖與PRD進行統(tǒng)一，上面分散管理的問題也得到解決檐涝。并更換為更流行的側(cè)邊導(dǎo)航欄遏匆、更好的視覺設(shè)計，使讀者的閱讀體驗更好骤铃。此時的產(chǎn)品需求文檔已經(jīng)慢慢開始成型。
這個版本可以說是PRD的Beta版坷剧，雖然是Beta版本惰爬，但是基本功能能滿足我們的需求，所以當時以這個版本的PRD持續(xù)了一段時間惫企。
文檔的迭代優(yōu)化
以Beta版的PRD持續(xù)一段時間后撕瞧，經(jīng)歷了一些項目的沉淀，在項目的使用過程中狞尔，發(fā)現(xiàn)幾個有趣的現(xiàn)象：
- 開發(fā)人員基本上只關(guān)注功能的實現(xiàn)丛版，焦點在交互原型圖上
- 設(shè)計師基本上只關(guān)注頁面和效果，焦點在原型圖上
- 測試人員則是側(cè)重于功能細節(jié)與各種情況的處理方案
可以理解偏序，如果把PRD作為一個產(chǎn)品來看页畦，上面的涉及的人員都是PRD的核心用戶，只不過3種角色的工作性質(zhì)不一樣研儒，所以需求不同而已豫缨。顯而易見，Beta版的PRD只是把產(chǎn)品相關(guān)信息和原型圖進行簡單的結(jié)合是滿足不了上面的需求的端朵，所以開發(fā)過程中就出現(xiàn)了幾個嚴重的問題：
- 對原型圖好芭、功能的描述不夠周全，開發(fā)經(jīng)常找PM確認需求上的點
- 原型圖上沒有添加頁面跳轉(zhuǎn)信息冲呢，導(dǎo)致設(shè)計師設(shè)計起來有些吃力
- 沒有把核心功能的流程圖的流程粒度細化到每個操作舍败，增加PRD讀者的理解成本
- 一些分支流程、特殊情況沒有在文檔中說明清楚，導(dǎo)致測試人員經(jīng)常找PM確認流程細節(jié)問題邻薯，嚴重降低PM工作效率以及增加了團隊的溝通成本裙戏。
沒錯，自己挖的坑弛说，跪著也要填回去挽懦。明確知道問題所在后，就需要針對性解決木人。在此之前信柿，需要針對目標用戶進行“用戶調(diào)研”，確認一下開發(fā)人員醒第、設(shè)計師和測試人員這些“核心用戶”的意見和看法渔嚷。收集了他們的意見之后，去「起點學(xué)院」購買了一些課程學(xué)習(xí)了具體的文檔規(guī)范稠曼，然后閱讀一些與PRD相關(guān)的文章形病，進行分析總結(jié)，然后迭代出新版的產(chǎn)品需求文檔霞幅。
新版本PRD在實踐中運用之后漠吻，之前出現(xiàn)的問題得到了很好的解決，最明顯的是團隊成員找PM確認需求的次數(shù)大大降低了司恳，并且開發(fā)效率也得到了提高途乃。當然，PM也減少了在溝通上成本扔傅。
下面我會通過以下7個方面來對新版PRD進行詳細說明耍共。（文章末尾附有PRD模板Axure文件的下載地址。）
- 文檔命名
- 文檔結(jié)構(gòu)
- 產(chǎn)品概述
- 全局說明
- 流程圖
- 功能需求
- 非功能需求
文檔命名
產(chǎn)品需求文檔的命名猎塞，只要能告訴別人這個文檔的必要信息就可以了试读，比如對產(chǎn)品需求文檔而言，需要讓別人知道這個文檔是什么產(chǎn)品的產(chǎn)品需求文檔荠耽，處于什么階段钩骇，比如PRD_產(chǎn)品名稱_V1.0.0。不過為了更好的進行統(tǒng)一管理铝量，這里使用采用了下面的方式來對文件名進行命名伊履。
文檔命名規(guī)則：【PRD】+ 產(chǎn)品名稱 + 產(chǎn)品版本號
例如：【PRD】微信 V6.6.1
文檔結(jié)構(gòu)
PRD的內(nèi)部結(jié)構(gòu)，如下圖所示款违。
主要包含產(chǎn)品概述唐瀑、全局說明、流程圖插爹、功能需求與非功能需求這5大模塊哄辣，每個模塊下方有對應(yīng)的子模塊请梢，下面進行詳細的介紹。
產(chǎn)品概述
產(chǎn)品概述模塊是用于展示產(chǎn)品介紹力穗、開發(fā)規(guī)劃以及文檔修訂歷史等基本內(nèi)容毅弧。主要有4個部分：
- 修訂歷史
- 開發(fā)周期
- 產(chǎn)品版本說明
- 產(chǎn)品介紹
首先來看看修訂歷史。
修訂歷史
修訂歷史是展示PRD的修改記錄当窗，里面記錄著產(chǎn)品經(jīng)理對PRD的修訂的方式以及修訂的內(nèi)容够坐。一般會放在文檔的第一頁，方便團隊成員第一時間了解到需求是否有改動崖面。而修訂歷史一般會采用表格的形式展示元咙，包含文檔的版本號、修訂日期巫员、修訂方式庶香、修訂人以及修訂內(nèi)容。
開發(fā)周期
開發(fā)周期包含兩個模塊简识，分別是開發(fā)周期以及開發(fā)計劃赶掖。
從上圖可以看出，在開發(fā)周期表格中七扰，顯示項目的計劃開發(fā)時間奢赂，不同的平臺開發(fā)難度不同，所以這里也會加以區(qū)分颈走。在下方的則是開發(fā)計劃膳灶，在敏捷開發(fā)中，都會以一個時間區(qū)間作為迭代的里程碑疫鹊，小步快跑袖瞻，一步步完成迭代上線司致。比如說一個移動App拆吆，開發(fā)的第一階段首先要進行框架的搭建、啟動頁脂矫、登錄注冊等基本功能的開發(fā)枣耀，然后再按照計劃、優(yōu)先級開發(fā)后續(xù)的功能庭再。
產(chǎn)品版本說明
版本說明只是展示產(chǎn)品對應(yīng)版本所包含的核心功能捞奕。需要注意的是，這個版本是以上線版本為基準拄轻，與上面開發(fā)周期所說的版本需要區(qū)分開來颅围。
產(chǎn)品介紹
顯示產(chǎn)品的相關(guān)介紹，常見的字段有產(chǎn)品名稱恨搓、logo院促、slogen筏养、產(chǎn)品簡介、產(chǎn)品定位常拓、目標人群渐溶、使用場景以及產(chǎn)品目標等。有個別產(chǎn)品可能還需要顯示其他對應(yīng)的信息弄抬，具體以實際情況為準茎辐。
全局說明
全局說明則是對產(chǎn)品中公共部分的控件、文案掂恕、網(wǎng)路請求狀態(tài)顯示等進行統(tǒng)一的說明拖陆。全局說明這部分會因產(chǎn)品不同而變動較大，所以也需要根據(jù)實際情況而定竹海。
流程圖
流程圖在這個PRD中是比較重要的模塊慕蔚，其中的邏輯性較強，最能反應(yīng)出產(chǎn)品經(jīng)理的邏輯思維能力與流程圖的繪制能力斋配。
在文檔中孔飒，流程圖中包含信息結(jié)果圖、功能結(jié)果圖艰争、業(yè)務(wù)流程圖以及任務(wù)流程圖（也是功能流程圖）坏瞄。
其中信息結(jié)構(gòu)圖和功能結(jié)構(gòu)圖可以使用Xmind、MindManager甩卓、百度腦圖等工具進行繪制鸠匀；而業(yè)務(wù)流程圖、任務(wù)流程圖則可以使用Visio逾柿、OmniGraffle缀棍、ProcessOn等工具進行繪制，然后導(dǎo)入到PRD机错。如果業(yè)務(wù)涉及到多端爬范、多用戶角色的產(chǎn)品，可以使用泳道圖弱匪。流程圖的具體的繪制大家可以參考woshipm社區(qū)下的實例解析業(yè)務(wù)流程圖與產(chǎn)品流程圖
功能需求
功能需求模塊是整個PRD中最重要的部分青瀑，這個模塊是將需求轉(zhuǎn)換為功能的詳細說明。在這個模塊中可以對產(chǎn)品功能有個全面的了解萧诫。先看看功能需求下的三個子模塊：
功能列表
該頁面展示的是整個產(chǎn)品的所有功能斥难，一般采用列表的形式展示，通常包含字段有模塊帘饶、功能名稱哑诊、功能描述以及優(yōu)先級。在這里額外添加了一項階段安排及刻，通過顏色的刺激程度來區(qū)分功能的開發(fā)階段镀裤。
產(chǎn)品線路圖
產(chǎn)品線路圖與上述所說的功能結(jié)構(gòu)圖十分類似穷当，只不過功能結(jié)構(gòu)圖是以功能為單位，而線路圖則是以頁面為單位淹禾。產(chǎn)品線路圖展示了產(chǎn)品的所有頁面以及對應(yīng)連接關(guān)系馁菜。我們可以通過點擊線路圖中的矩形節(jié)點，跳轉(zhuǎn)到對應(yīng)的功能詳情铃岔。
功能詳情
這個是我們的開發(fā)人員汪疮、設(shè)計師、測試人員使用最多的一個模塊毁习，沒有之一智嚷。該模塊展示的是功能頁面的詳細信息，主要有功能頁面的描述纺且、流程說明以及異常情況處理盏道。
以啟動頁為例說明一下。主要包含4個部分载碌，分別是原型圖猜嘱、頁面簡介、界面描述和用戶用例嫁艇。其中界面描述是對原型圖中的元素進行詳細的解釋朗伶。用戶用例則是對用戶的使用流程以及備選流程、異常流程情況的說明步咪，不過并不是每個頁面都會有用戶用例這個部分论皆，一些簡單的展示界面、沒有用戶行為的頁面猾漫，就可以不做用戶用例点晴。
通過功能詳情的一些細節(jié)描述和用戶用例的思考，可以大大減少產(chǎn)品經(jīng)理對功能思考的遺漏點悯周。
非功能需求
不同產(chǎn)品有不同的非功能性需求粒督，一般有以下幾類非功能性需求。
- 性能需求
- 統(tǒng)計需求
- 營銷需求
- 法務(wù)需求
- 質(zhì)量需求
- 安全需求
- 運營需求
- 財務(wù)需求
上面的列舉的非功能需求就不一一說明了队橙，每個產(chǎn)品都不一樣坠陈，需要根據(jù)具體產(chǎn)品萨惑、具體情況而定捐康。
總結(jié)
其實PRD的撰寫與迭代，可以看做是一個產(chǎn)品的設(shè)計與迭代的過程庸蔼。所以我們在PRD迭代更新的過程中解总，要明確團隊的實際需求，找出痛點姐仅、分析問題花枫、得出解決方案刻盐、然后實施并驗證方案的正確性。以上產(chǎn)品需求文檔是經(jīng)過兩次迭代之后劳翰，然后結(jié)合團隊的流程總結(jié)出來的敦锌，雖然并不完美，但是很好的滿足當前團隊的需求佳簸，基本上符合當前敏捷開發(fā)團隊的使用乙墙，后續(xù)也會不斷改進優(yōu)化。不過每個團隊也會因情況不同而需求不一樣生均，所以也僅供參考听想。文章末尾是文檔抽離出來的模板，附有對應(yīng)下載地址马胧。
不過需要明確一點的是汉买，PRD只是一個幫助PM傳遞想法和需求的工具，一個輔助手段佩脊，并不是目的蛙粘，所以核心還是在需求上⊥茫或許到了團隊的后期组题，團隊成員能力都很強、都很默契抱冷，基本上可以通過口頭溝通完成信息傳遞時崔列，那么產(chǎn)品需求文檔也就不那么重要了。（嗯旺遮，這很理想…）
產(chǎn)品需求文檔模板_Axure文件地址
密碼：mhns
