上一篇文章我們講解了需求分析如何做。本文繼續分享需求分析之后，如何寫好PRD這個關鍵文檔。

上節講完怎么做需求分析，那做完需求分析就需要輸出產品需求文檔：PRD。

產品小白不迷路04：需求分析階段需要做什么？

那怎么才能寫好一份PRD呢？

一、什么是PRD？

PRD，全稱Product Requirement Document，即產品需求文檔，是產品經理在產品開發過程中編寫的一份詳細的產品需求說明書。它主要用于指導產品的設計、開發、測試等后續工作，確保產品開發團隊對產品的功能、性能、用戶體驗等方面有清晰的認識和一致的理解。

考古一下，寶潔在二十世紀二三十年代第一次提出了產品經理的概念，并有了產品經理的崗位，第一份PRD推測也誕生于寶潔公司的第一位產品經理手上。

再延伸一下，有PRD之前，應該先有MRD（Market Requirement Document），市場需求文檔，用于市場調研，發掘可發展的市場商機。然后是BRD（Business Requirement Document），商業需求文檔，類似商業白皮書，用于產品在投入研發之前，由企業高層作為決策評估的重要依據，評估整體的商業目標和價值。

二、PRD的作用是什么？

說到作用，那就要知道PRD一般來說是什么人會看，而這些人為什么會看，一般來說是這幾類角色會查看：

• 產品經理：查漏補缺
• 提需求的業務方：了解業務以及調整效果
• 設計師（UI/UE）：了解業務，進行界面設計
• 開發（技術、測試、架構師等）：功能開發說明

所以，PRD的主要作用是作為產品開發的說明書，它詳細描述了產品的各項需求，包括功能需求、界面設計、數據處理、操作流程等，以便開發團隊能夠按照既定的要求進行工作。

此外，PRD還可以作為項目管理的工具，幫助團隊跟蹤項目進度，及時調整開發計劃，確保產品按時交付。

三、PRD的內容

通常每家公司都會有自己的PRD模版來規范需求的輸出格式，但都會包含以下內容：

1、文檔命名：包括時間、迭代版本、需求名、版本號等，便于版本控制和追蹤。如果是外包對接，還可以加上公司名稱、機密等級說明。

例如：0203（上線時間/開始時間）迭代1-訂單流程優化需求說明文檔

2、修訂記錄：記錄文檔的修訂歷史，包括修訂章節、修訂原因、修訂日期、修改人等信息。

修訂記錄如果是內部自研，可以只寫創建文檔時間，過程中的修改只要業務、產品、技術達成一致，沒必要記錄。但如果是外包，則需要詳細記錄，以便后續驗收時追溯。

3、目錄：列出文檔的主要章節和子章節，方便查閱。這里只要根據編寫規范，Word或在線文檔均可自動生成目錄

4、概述：包括產品背景、場景、目標、Roadmap、風險等內容，概括產品的整體情況。

• 目的是讓看文檔的人知道產品需求的相關背景以及目的，后續產品功能的調整都需要圍繞這個目的為前提或者考慮，不要偏移需求的初衷。
• 這里還可以說明一些非業務需求，可以是對產品的性能、交互體驗的約定規范。這樣就不需要每個需求都寫很細致，提高文檔編寫的效率。

5、產品設計概述：描述目標客戶、需求描述、場景描述、優先級等，明確產品的服務對象和需求點。

• 需求命名：【需求類型】+需求簡述，可根據需求類型是新功能還是功能優化或界面優化建立標簽，可快速了解需求情況。
• 涉及功能模塊：實際運營和開發過程中，會按照功能模塊進行維護，所以標注出涉及的功能模塊，可快速定位相關業務和開發。
• 需求描述：描述需求，什么人，在什么地方，做什么，得到什么結果
• 優先級：多需求同時開發，需要明確需求的優先級
• 輸入/前置條件：相關的需求前置條件，例如：查看購物車需要先登錄、查看客戶信息需要有相應的角色權限等。
• 需求說明：詳細描述產品需求，需要清晰的一條一條列出來，考慮正向和逆向（無數據、異常等）的場景解決方案，描述可用流程圖、用例圖、狀態圖、字段說明等輔助說明。
• 涉及產品/端：如果是跨產品開發，標明是什么產品，什么端（PC、APP、小程序、H5等）
• 補充說明：一般是輔助的資料，例如：原型地址、設計稿地址、導入導出文件等
• 原型說明：文字描述總沒有圖直觀，且交互展示也需要原型中表達出來

四、PRD的撰寫原則

既然已經清楚了PRD的基本結構是怎樣的，那么具體應該怎么去撰寫呢，我覺得需要把握住幾個原則：

• 符合實際：每個團隊合作都需要磨合和配合，大家和跟進實際情況增減PRD中的信息，不要為了寫文檔而寫文檔
• 結構化清晰：合理安排文檔結構，使內容條理分明，易于理解和查找。
• 詳細準確：對每個需求點進行詳細描述，包括功能細節、操作步驟、預期效果等。
• 動態更新：隨著項目進展，及時更新PRD內容，確保信息的實時性和準確性。

五、總結

PRD的編寫應根據團隊的實際情況和需求進行調整，避免生搬硬套模板。