文檔能力是產品經理必備的基本能力。
文檔能力是產品經理必備的基本能力， 產品經理通過文檔的方式把需求轉化為功能傳遞給專案的相關人員，
剛入行的產品新人都會優先學習產品需求文檔（下面會用PRD代替）的撰寫和原型的繪製， 自己當時也是一樣。 當時看了很多產品需求文檔的案例， 各種類型、格式的產品文檔都研究過。 然後在主流的幾個文檔格式中選擇Axure原型來撰寫PRD， 因為Axure做的原型需求文檔， 與讀者之間有互動， 體驗更加良好而不至於那麼單調。
產品需求文檔初成型剛開始時， 在網上的一些範本並結合實際專案來撰寫PRD的， 並且PRD和原型圖是完全分開的， 也就是說第一次撰寫的PRD只包含一些基本的和公共的資訊， 比如文檔的修訂歷史、產品說明、版本介紹以及核心的流程圖（如下圖）。
後來經歷過幾次的專案開發和反覆運算之後， 發現PRD與原型圖分開管理的方式製作起來十分繁瑣， 並且一些小版本的更新會直接在原型圖上更新而忘了更新PRD。
後來就決定把原型圖與PRD進行統一， 上面分散管理的問題也得到解決。 並更換為更流行的側邊巡覽列、更好的視覺設計， 使讀者的閱讀體驗更好。 此時的產品需求文檔已經慢慢開始成型。
這個版本可以說是PRD的Beta版， 雖然是Beta版本， 但是基本功能能滿足我們的需求。
文檔的反覆運算優化以Beta版的PRD持續一段時間， 經歷了一些項目的沉澱， 在項目的使用過程中發現幾個有趣的現象：
開發人員基本上只關注功能的實現， 焦點在交互原型圖上設計師基本上只關注頁面和效果， 焦點在原型圖上測試人員則是側重於功能細節與各種情況的處理方案可以理解， 如果把PRD作為一個產品來看， 上面的涉及的人員都是PRD的核心用戶， 只不過3種角色的工作性質不同， 所以需求不同而已。 顯而易見， Beta版的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協議
新版本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協議