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

上節(jié)講完怎么做需求分析，那做完需求分析就需要輸出產(chǎn)品需求文檔：PRD。

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

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

一、什么是PRD？

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

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

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

二、PRD的作用是什么？

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

• 產(chǎn)品經(jīng)理：查漏補缺
• 提需求的業(yè)務方：了解業(yè)務以及調(diào)整效果
• 設計師（UI/UE）：了解業(yè)務，進行界面設計
• 開發(fā)（技術(shù)、測試、架構(gòu)師等）：功能開發(fā)說明

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

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

三、PRD的內(nèi)容

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

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

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

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

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

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

4、概述：包括產(chǎn)品背景、場景、目標、Roadmap、風險等內(nèi)容，概括產(chǎn)品的整體情況。

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

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

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

四、PRD的撰寫原則

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

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

五、總結(jié)

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