起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品迭代縮影：PRD的撰寫與迭代
文檔能力是產品經理必備的基本能力。
文檔能力是產品經理必備的基本能力，產品經理通過文檔的方式把需求轉化為功能傳遞給項目的相關人員，使相關人員更好的理解功能需求。所以文檔的好壞直接影響到團隊成員對需求的理解程度。 剛入行的產品新人都會優先學習產品需求文檔（下面會用PRD代替）的撰寫和原型的繪制，自己當時也是一樣。當時看了很多產品需求文檔的案例，各種類型、格式的產品文檔都研究過。然后在主流的幾個文檔格式中選擇Axure原型來撰寫PRD，因為Axure做的原型需求文檔，與讀者之間有互動，體驗更加良好而不至于那么單調。 剛開始時，在網上的一些模板并結合實際項目來撰寫PRD的，并且PRD和原型圖是完全分開的，也就是說第一次撰寫的PRD只包含一些基本的和公共的信息，比如文檔的修訂歷史、產品說明、版本介紹以及核心的流程圖（如下圖）。其他的細節信息則是通過在原型圖上進行簡要的標注。 后來經歷過幾次的項目開發和迭代之后，發現PRD與原型圖分開管理的方式制作起來十分繁瑣，并且一些小版本的更新會直接在原型圖上更新而忘了更新PRD。而且開發人員、設計師基本上只看原型圖不看PRD，遇到需求問題就直接問PM，這樣就失去了產品需求文檔的意義了。 后來就決定把原型圖與PRD進行統一，上面分散管理的問題也得到解決。并更換為更流行的側邊導航欄、更好的視覺設計，使讀者的閱讀體驗更好。此時的產品需求文檔已經慢慢開始成型。 這個版本可以說是PRD的Beta版，雖然是Beta版本，但是基本功能能滿足我們的需求。 以Beta版的PRD持續一段時間，經歷了一些項目的沉淀，在項目的使用過程中發現幾個有趣的現象： 可以理解，如果把PRD作為一個產品來看，上面的涉及的人員都是PRD的核心用戶，只不過3種角色的工作性質不同，所以需求不同而已。顯而易見，Beta版的PRD只是把產品相關信息和原型圖進行簡單的結合，并不能滿足上面的需求，所以開發過程中就出現了幾個嚴重的問題： 沒錯，自己挖的坑，跪著也要填完。明確問題所在后，就需要針對性解決。在此之前，需要針對目標用戶進行“用戶調研”，確認一下開發人員、設計師和測試人員這些“核心用戶”的意見和看法。收集他們的意見之后，去「起點學院」購買了一些課程并學習具體的文檔規范，然后閱讀一些與PRD相關的文章，進行分析總結，然后迭代出新版的產品需求文檔。（首頁如下圖） 新版本PRD在實踐中運用之后，之前出現的問題得到了很好的解決，最明顯的是團隊成員找PM確認需求的次數大大降低了，并且開發效率也得到了提高。當然，PM也減少了在溝通上成本。 下面我會通過以下7個方面來對新版PRD進行詳細說明。（文章末尾附有PRD模板Axure文件的下載地址。） 文件的命名，只要能告訴別人這個文檔的所包含的必要信息就可以了。對PRD而言，需要讓別人知道這個文檔是什么產品的產品需求文檔，處于什么階段，比如PRD_產品名稱_V1.0.0。不過為了更好的進行統一管理，這里使用采用了下面的方式來對文件名進行命名。 文檔命名規則：【PRD】+ 產品名稱 + 產品版本號 例如：【PRD】微信 V6.6.1 PRD的內部結構，如下圖所示。 主要包含產品概述、全局說明、流程圖、功能需求與非功能需求這5大模塊，每個模塊下方有對應的子模塊，下面進行詳細的介紹。 產品概述模塊是用于展示產品介紹、開發規劃以及文檔修訂歷史等基本內容。主要有4個部分： 首先來看看修訂歷史。 修訂歷史是展示PRD的修改記錄，里面記錄著產品經理對PRD的修訂的方式以及修訂的內容。一般會放在文檔的第一頁，方便團隊成員第一時間了解到需求是否有改動。而修訂歷史一般會采用表格的形式展示，包含文檔的版本號、修訂日期、修訂方式、修訂人以及修訂內容。 開發周期包含兩個模塊，分別是開發周期以及開發計劃。 從上圖可以看出，在開發周期表格中，顯示項目的計劃開發時間。不同的平臺開發難度不同，所以這里也會加以區分。下方的則是開發計劃，在敏捷開發中，都會以一個時間區間作為迭代的里程碑，小步快跑，一步步完成迭代上線。比如說一個移動App，開發的第一階段首先要進行框架的搭建、啟動頁、登錄注冊等基本功能的開發，然后再按照計劃、優先級開發后續的功能。 版本說明只是展示產品對應版本所包含的核心功能。需要注意的是，這個版本是以上線版本為基準，需要與上面開發周期所說的版本需要區分開來。 顯示產品的相關介紹，常見的字段有產品名稱、logo、slogen、產品簡介、產品定位、目標人群、使用場景以及產品目標等。有個別產品可能還需要顯示其他的信息，具體以實際情況為準。 全局說明則是對產品中公共部分的控件、文案、網路請求狀態顯示等進行統一的說明。全局說明這部分會因產品不同而變動較大，所以也需要根據實際情況而定。 流程圖在這個PRD中是比較重要的模塊，其中的邏輯性較強，最能反應出產品經理的邏輯思維能力與流程圖的繪制能力。 在文檔中，流程圖中包含信息結果圖、功能結果圖、業務流程圖以及任務流程圖（也就是功能流程圖）。 其中信息結構圖和功能結構圖可以使用Xmind、MindManager、百度腦圖等工具進行繪制；而業務流程圖、任務流程圖則可以使用Visio、OmniGraffle、ProcessOn等工具進行繪制，然后導入到PRD。如果業務涉及到多端、多用戶角色的產品，可以使用泳道圖。流程圖的具體的繪制大家可以參考woshipm社區下的《實例解析業務流程圖與產品流程圖》 功能需求模塊是整個PRD中最重要的部分，這個模塊是對功能的詳細說明。先看看功能需求下的三個子模塊： 該頁面展示了整個產品的所有功能，一般采用列表的形式展示，通常包含字段有模塊、功能名稱、功能描述以及優先級。在這里額外添加了一項階段安排，通過顏色的刺激程度來區分功能的開發階段。 產品線路圖與上述所說的功能結構圖十分類似，只不過功能結構圖是以功能為單位，而線路圖則是以頁面為單位。產品線路圖展示了產品的所有頁面以及對應連接關系。我們可以通過點擊線路圖中的矩形節點，跳轉到對應的功能詳情。 這個是我們的開發人員、設計師、測試人員使用最多的一個模塊，沒有之一。該模塊展示的是功能頁面的詳細信息，主要有功能頁面的描述、流程說明以及異常情況處理。 以啟動頁為例說明一下。主要包含4個部分，分別是原型圖、頁面簡介、界面描述和用戶用例。其中界面描述是對原型圖中的元素進行詳細的解釋。用戶用例則是對用戶的使用流程、備選流程以及異常流程情況的說明。不過并不是每個頁面都會有用戶用例這個部分，一些簡單的展示界面、沒有用戶行為的頁面，就可以不做用戶用例。 通過功能詳情的一些細節描述和用戶用例的思考，可以大大減少產品經理對功能思考的遺漏點。 不同產品有不同的非功能性需求，一般有以下幾類非功能性需求。 上面的列舉的非功能需求就不一一說明了，每個產品都不一樣，需要根據具體產品、具體情況而定。 其實PRD的撰寫與迭代，可以看做是一個產品的設計與迭代的過程。所以我們在PRD迭代更新的過程中，要明確團隊的實際需求，找出痛點、分析問題、得出解決方案、然后實施并驗證方案的正確性。 以上產品需求文檔是經過兩次迭代之后，然后結合團隊的流程總結出來的，雖然并不完美，但是很好的滿足當前團隊的需求，基本上符合當前敏捷開發團隊的使用，后續也會不斷改進優化。每個團隊也會因情況不同而需求不一樣，所以也僅供參考。 不過需要明確一點的是，PRD只是一個幫助PM傳遞想法和需求的工具，一個輔助手段，并不是目的，所以核心還是在需求上。或許到了團隊的后期，團隊成員能力都很強、都很默契，基本上可以通過口頭溝通完成信息傳遞時，那么產品需求文檔也就不那么重要了。（嗯，比較理想…） 產品需求文檔模板_Axure文件地址：（https://pan.baidu.com/s/1eT9RUZg）密碼: mhns 本文由 @?Kimson 原創發布于人人都是產品經理。未經許可，禁止轉載。 題圖來自PEXELS，基于CC0協議產品需求文檔初成型
文檔的迭代優化
文檔命名
文檔結構
產品概述
修訂歷史
開發周期
產品版本說明
產品介紹
全局說明
流程圖
功能需求
功能列表
產品線路圖
功能詳情
非功能需求
總結
模版不見了，還可以怎么領取呀
您好，看了你的文章和原型，深有體會，現在我也在做需求文檔原型化，在閱讀您的文章時遇到一個疑問，就是在產品的不同迭代中，我是一個產品版本一個原型，還是將產品版本的多個版本集中在一個原型呢？求指教
這段問題的描述剛好就是我最近踩的坑，深有體會
挺好的，很清晰，給了一個很好的思路
版本迭代的原型，是一個版本一個axure文檔嗎
謝謝大佬分享
滿滿的干貨，謝謝分享。受教了
用Axure的什么版本比較好呢
滿滿的干活，非常實用的模板！
老鐵，文件下載下來，打開文件已損壞。
剛半路接手了一個項目，正愁怎么把文檔補上呢，感謝老鐵，學習了！
您好，地址失效了，能麻煩再分享一下嘛 謝謝
請教下，產品線路圖是用什么工具畫的？
用Axure畫的啊
謝謝，寫得不錯，很值得學習和借鑒。必須打賞
寫的很不錯，目前正在發愁怎么寫。鏈接好像失效了
不會呀 前兩天還可以下
寫的很好很充實，最近我在嘗試和你完全相反的方向，PRD的去原型化，希望完全利用流程圖、字段描述和邏輯描述將需求說清楚，發現這種方式對自己思考需求很有幫助，但是在評審和開發階段，還是效率低些，一方面開發測試面對整篇的文字不會多認真去看，另一方面，在交互文檔上同樣還要標注清楚。之后也會嘗試PRD的原型化
非常贊同你的看法。
是用什么軟件做的??？word？還是？寫的很好，學習了。
axure
axure寫那么多文字，而且還有列表。是不是有點麻煩了。
寫的不錯，謝謝分享
可以啊