一份詳細的產品需求文檔撰寫指南，結合實例，分析細緻。
在產品經理的日常工作中，經常需要藉助各類文檔來和技術、設計等團隊成員打交道。從需求收集到功能落地，一份合格的產品文檔能夠減少很多溝通成本，避免返工，幫助產品經理更好地推動項目進程。因此，寫好產品文檔是決定工作效率與質量的關鍵因素之一。
毋庸置疑，產品文檔的撰寫是產品經理的必備基礎技能；雖說是基本功，但是能寫出一份清晰簡潔的文檔，卻非易事。想要寫好產品文檔，首先要進行反覆的深入的思考，寫文檔不是目的，目的是將產品的思維和邏輯通過文檔的形式表達出來。因此我們可以說，要想寫好一份產品文檔，就要進行一次有序而全面的思考。
一、 產品文檔分類與差異
一般我們說的產品文檔更多指的是PRD，其他常用的產品文檔有BRD和MRD。那麼這幾個名字相似的文檔究竟有何差別，又分別會用在什麼場景下呢？爲了進行初步的瞭解，以下爲常見文檔的差異對比：
二、 PRD簡述
PRD是產品文檔中出現頻率最高的一種。一般在需求收集完成，產品經理完成需求相關的業務邏輯、流程梳理後，開始撰寫PRD；通過PRD將需求相關的業務流程、數據流向、頁面交互等信息清晰地展現出來，作爲技術開發評審需求和進行功能開發的依據。根據不同的產品類型，PRD包含內容和側重點各不相同。但是核心在於，完整表達產品經理對於該產品的功能的邏輯、頁面以及所有需求的有效表述，有效表述的標準是，技術人員能理解並藉助PRD完成開發。
PRD對於產品經理而言最大的作用是沉澱信息，同時也是在產品迭代過程中的需求記錄；對於技術而言是開發的依據，是一份“書面化”的任務工單。一般PRD都是word文檔形式居多，但是也可以用AXURE等工具來展現。
既然PRD是產品經理與技術之間溝通的橋樑，那麼這座橋樑就應該是雙方共同搭建。技術將自己的理解與開發習慣同步至產品經理，產品經理根據技術的理解、習慣形成針對性的PRD，減少溝通成本，增強PRD 的可讀性與價值。
三、 PRD內容詳解
對於入門的產品新手而言，“模仿是最好的學習方式之一”。需求文檔雖說沒有標準化的模板，但是在表述清晰簡潔的基礎上，一般可將需求文檔的結構分解下：
文檔信息一般包含文檔與撰寫人的相關信息，包含但不僅限於文檔名稱、文檔版本、撰寫人信息（手機、郵箱、部門等）、文檔修改記錄等信息。文檔名稱與版本可幫助產品經理更好地管理和使用文檔，撰寫人信息可供文檔閱讀者有問題時及時反饋至撰寫人，文檔修改記錄尤其重要，一方面可幫助技術人員快速分辨出最新版本文檔的修改點，減少無效閱讀時間；另一方面可幫助產品經理在版本迭代過程中進行文檔管理。
需求總覽一般可用需求表格形式展現，內容包含但不限於需求分類、需求簡單說明、優先級、技術對於需求的分解、排期等。需求列表不但可以對整個文檔的需求做一個完整的統計與整理，在需求範圍未確認前，還可作爲需求初評的依據。若是單個需求如活動需求，可將活動流程作爲需求總覽進行展現。
具體的需求說明需要根據需求的類型進行定製化的說明，一般可能包含頁面說明、交互說明、數據來源說明等方面。頁面說明主要闡述頁面包含的元素和模塊，以及各模塊分別滿足的需求。交互一方面要說清頁面的業務流程與邏輯，另一方面要結合設計圖與交互稿對頁面的反饋、焦點等交互邏輯進行說明。數據來源主要說明該功能的接口邏輯，數據流程以及後臺相對應的編輯功能等。
四、PRD的迭代
每個產品經理都應該有自己的PRD管理庫。一方面是針對同一個產品在不斷的迭代過程中的各項功能、頁面的優化、升級情況有一個全面的統計和沉澱；另一方面，當一個產品經理同時負責多個產品或者多個模塊時，PRD管理庫能夠幫助產品經理更好更快地形成自己的文檔撰寫風格，發展處一套屬於自己的PRD撰寫方法論。
五、PRD實例說明
經過以上對PRD 的介紹說明，我們已經能對PRD有一個初步的瞭解和認知。那麼在何種場景下我們會用到PRD？PRD在現實的產品工作中應該如何撰寫？讓我們以某抽獎活動的需求爲例，來討論下實戰中的PRD。
那麼，產品經理在何時進入PRD撰寫階段是比較合適的呢？以某活動需求爲例，一般產品經理會接到來自營銷部門的活動需求，根據需求產品經理提出大致的產品方案，產品方案可以是簡單的文字描述、草圖說明等，可以讓營銷、技術理解大致的活動流程和功能即可。產品經理帶着產品初步方案召集需求方和技術團隊進行需求初審，確認需求的可行性後，就可以進入需求文檔的撰寫階段了。文檔的撰寫過程讓我們根據上文提到的PRD結構，一一展開詳細的說明。
1、首先是關於文檔的信息。
我們將文檔名稱、文檔版本、撰寫人的信息、文檔的修改記錄以表格的形式，做簡單的說明，如下所示：
2、接下來是關於需求總覽，即需求列表。
需求列表一般包含需求編號、需求分類、需求簡單說明、需求優先級、任務分解、評估工期、備註等信息中的幾項；一般版本中會涉及到多個需求時候，需要以需求列表的形式進行整理，以便技術能一目瞭然地看到版本的需求信息；當只涉及到一個核心需求如活動需求時候，只需做簡單的分類、需求分解、評估工期即可，可簡單整理如下：
需求列表需要產品經理針對性地進行調整，會因版本的內容、功能的複雜程度、涉及的模塊等有所不同。
3、然後就是針對具體的需求進行說明。
在進行具體某個需求的描述之前，對整體的需求進行概括性地總結，可以結合產品結構圖、業務流程圖、操作流程圖等進行描述。
4、對需求進行整體說明後，我們將對具體功能進行詳細說明。
這部分是技術、設計、測試等使用最多的一個部分。該部分展示的是功能頁面的詳細信息，主要有頁面的描述、交互流程說明以及數據來源（後臺接口需求）。
首先是頁面描述，根據頁面的功能、展現的元素進行說明，舉例說明，我們可對做以下頁面說明：
頁面包含的元素：頁面主要包含轉盤區、中獎名單、活動規則和我的獎品入口等；轉盤中獎品檔最多爲6種，既支持實物獎品也支持虛擬獎品（電影套票和話費）顯示獎品圖片名稱，後臺可添加；
功能基本邏輯：開始狀態指針朝12點方向；用戶選中“抽獎”並確認，先後進行登錄判斷、是否有權參與活動、次數判斷和中獎結果判斷；若用戶未登錄，則彈出登錄頁面，用戶完成登錄之後回到抽獎頁面；若用戶已登錄，則轉盤開始轉動；如果抽中某個獎品，則在“我的獎品”中顯示相應獎品名稱；轉盤停止後，根據指針所指的獎品出現中獎或者未中獎提示窗口。
其次是交互說明，對頁面的焦點，頁面交互邏輯進行說明：
交互說明：頁面的默認焦點在轉盤的『抽獎』。點擊『抽獎』按鈕結果共有5種狀態：1）進入登錄流程2）無權參與活動提示3）次數用完提示4)中獎結果彈窗5)未中獎彈窗；提示框中的提示文本後臺可編輯，與4種抽獎狀態一一對應，每種狀態對應不同的提示語；默認中獎提示：“恭喜你，人品爆發，抽中“xxx”（xxx爲獎品名稱）……！“，顯示 “知道了”按鈕和“立即領取”（與“我的獎品”中的領取邏輯相同）；默認未中獎提示：“很遺憾您本次沒有中獎”，顯示『知道了』按鈕。
最後是數據來源（後臺接口）邏輯說明：
接口說明：抽獎大轉盤作爲一種營銷工具，在用戶滿足運營後臺設置的條件的場景下可顯示；抽獎活動名稱：活動名稱顯示在背景圖片上，後臺以背景圖片的形式更改活動名稱；大轉盤：六個獎品可以通過後臺上傳圖片的形式更換，中獎機率可編輯，點擊『抽獎』轉盤轉動；參與人數：即時更新，同步接口數據；我的獎品：展示用戶在此活動期間獲得的最新的獎品，可選中確認查看獎品列表；中獎名單：名單滾動顯示，實時同步接口數據；活動規則：後臺可編輯。
至此，PRD 的主要內容都已經完成，但是基於不同的需求，可能會存在一些附加需求。如某些功能會有數據需求，活動需求會有活動後臺的需求等，需要產品經理根據實際的需求進行補充。正如我們前文說到的，PRD其實並沒有一個標準化的模板，需要每一個產品經理在實戰的過程中與技術進行磨合，對自己的PRD進行不斷迭代、優化，最終形成自己的文檔風格。
完成PRD之後，產品經理需要將文檔同步至包括技術、設計、測試等團隊所有成員，進行需求評審會議，產品經理通過宣講，讓技術結合文檔更深入地、更形象具體得了解需求，做出合理可靠的評估。