做產品經常會寫PRD，但是如果沒有一套完整的寫作思路和框架，寫出的PRD質量就不會太好，導致遺漏重要信息，在項目過程中被開發、前端、測試吐槽。趁這個周末有空，來梳理下一下寫PRD的邏輯。

一、什么是PRD?

PRD為Product Requirement Document的簡稱，其中文翻譯為：產品需求文檔。該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔。當然，這個定義針對的是一個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標用戶、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等，本文主要討論的是戰術部分。

PRD的主要使用對象有：開發、測試、項目經理、交互設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；項目經理可以根據PRD拆分工作包，并分配開發人員；交互設計師可以通過PRD來設計交互細節。PRD是項目啟動之前，必須要通過評審確定的最重要文檔。

產品經理的PRD，就像建筑設計師的設計圖紙，是整個設計和思考的結晶；同時，也是思考過程呈現?！队脩趔w驗要素》作者在書中有一句很經典的話：“文檔不能解決問題，但是定義可以”，這也是PRD的另一個重要的作用：定義產品需求，在團隊內達成共識。

二、寫作的邏輯

寫PRD，其實就是一個產品的業務需求分析過程，最近在看一本書，叫《火球UML大戰需求分析》，里面提到了需求分析過程，作者的這個需求分析思路是基于傳統軟件/系統，但是我覺得這種思路是相通的，可以應用于所有產品。我根據這個思路，做了部分改良，形成了以下的邏輯：

1. 整理產品結構
2. 分析核心業務流程
3. 分析及整理用例
4. 分析及整理非功能性需求
5. 整理需求文檔并評審

整理產品結構

就像修建一座商場，在設計的時候，需要考慮整個商場的結構，商場包含美食區、服裝區、百貨區、休閑娛樂區等，然后每個區域又可以按商家或類型細分。產品也是這個道理，產品是由功能和內容組成，這些功能和內容，按照某種緯度，組成頻道/模塊，最終形成產品的整體結構。由于產品的結構一般比較大，這里僅以產品結構中的個人中心這個模塊為例：

產品結構一般通過MindManger梳理。需要注意的是，產品結構≠頁面結構，產品結構是邏輯上的，頁面結構是物理上的，至于具體的結構和方法，可以參看《用戶體驗要素》一書。

分析核心業務流程

每個產品，都會有幾個核心的業務，分析并梳理出幾個核心業務流程，可以幫助產品經理了解產品邏輯。筆者做的是B端產品，核心業務流程一般都會涉及到多個角色，而C端產品，核心流程的用戶則比較單一。涉及到多個角色的業務流程，可以使用泳道圖，單個角色可以使用普通的活動圖。另外，在分析業務流程的時候，還可以配合使用狀態圖和順序圖，具體使用什么工具，視情況而定，重點是梳理清楚邏輯。

分析及整理用例

這個步驟是更具體，也很重要的的一步，前面2個步驟確定了范圍和流程，這一步針對流程上的某個節點來具體描述。以會員中心→內容管理這個模塊為例，這個模塊下面包含的用例有：

1. 新增文章
2. 修改文章
3. 刪除文章
4. 查看文章列表
5. 查看文章詳情

現在，就可以按照上面這個列表，來一一的描述用例。一個完整的用例應該包含以下主要內容：

在描述需求時，有2種方式，一種是用例描述，另外一種是功能點描述。用例描述和功能點描述最大的區別在于，描述的角度不一樣，用例是從人和系統的旁觀者來描述，而功能點是從產品的角度來描述。通過用例描述需求，最好用文檔，并且有統一的用例模板，而功能描述只需要在Axure里，以注釋的方式描述即可。

其實，關于需求怎么描述，沒有完全正確的方式，只有最合適的方式，具體因人而異?！秵⑹句洝芬粫髡呔徒ㄗh描述產品需求只需要高保真原型+注釋就可以，完全不需要文檔，以下是書中的一些觀點：

產品說明（需求）文檔的主體應該是高保真原型，由它體現產品的功能需求、信息架構、用戶體驗、交互設計、視覺設計。高保證原型最大的優勢是可以用于測試。

與其花幾個星期撰寫冗長的Word文檔，既沒人讀，也無法測試，還不如和設計師一起創建原型。

詳細內容可以參看這本書的第十八章，「重新定義產品說明文檔」一節。

不管是用例描述還是功能描述，規則都是最重要的一部分，這里主要講一下如何描述能完整無誤的闡述需求并讓閱讀者看懂。規則的描述，主要是從3方面思考。

• 數據規則。主要指頁面從數據庫調取數據并展現的規則，比如查看文章列表這個用例，需要描述文章列表頁面展示哪些字段、每個字段的類型及長度、列表的排序規則刷新頻率等。
• 狀態邏輯。文章不同狀態之間切換的觸發點是什么，比如狀態為已發布的文章，要變為下架，可能的觸發條件有：發布時間已過期、手動操作下架等。
• 交互規則。界面上存在交互的元素，一一列舉并說明，比如鏈接、按鈕、滑動、下拉的具體交互規則及異常處理。另外，整個場景由于網絡問題、系統問題導致的異常也需要說明。

分析及整理非功能性需求

非功能需求涉及比較廣，比如產品的性能需求，訪問速度達到多少、最大能支持多少人同時訪問；比如設計需求，產品要設計成小清新風格還是成熟穩重的風格等；還比如統計需求，產品要統計哪些字段，形成哪些報表等。這個可以根據具體的需求來描述。

整理需求文檔并評審

當完成以上4個步驟以后，整個產品的邏輯已經很清楚了，再將產出物匯總，就可以整理出需求文檔。文檔出來后，需要和項目相關的負責人一起評審，評審確認通過，就可以進入產品的實施階段。實施一般是由項目經理負責，但是很多公司沒有配備該崗位，這就要求產品經理擁有項目管理的能力，來推動產品順利實施并上線。

三、PRD文檔的格式

目前市面上各種需求文檔，五花八門，千萬不要試圖找到一個100%完美的文檔模版，PRD文檔，只有最合適的，沒有最好的，每個人所在的公司背景都不一樣，大公司要求文檔規范，細節到位，小公司可能只需要記錄關鍵信息，剩余的靠口頭溝通，甚至都不需要文檔。還有些人，直接通過Axure描述產品需求。

PRD文檔，最重要的還是以上的整個思考和整理的過程，當以上步驟梳理清楚后，文檔只是水到渠成的產出。我的原則是，只要內容清楚，文檔格式沒那么重要。

四、寫在最后

產品經理需要做產品的戰術執行和戰略計劃工作，我認為這兩個工作是個遞進的關系，當你能把產品的戰術執行到位，真正的把一款產品從0到1做出來的時候，再去思考產品的創新、規劃……產品才容易落地，否則，永遠是紙上談兵。這也是為什么很多產品助力剛開始到公司都只接一些功能模塊的設計實施工作，而不是一來就做戰略方面的工作。

以上僅是個人的一些思考，謝謝！

參考書籍：

《用戶體驗要素》

《啟示錄》

《火球UML大戰需求分析》

本文由 @覓路客 原創發布于人人都是產品經理?，未經許可，禁止轉載。