prd開發手冊（PRD文檔構建及使用流程）

2023-10-19 19:19:56

前言 ：正如大家在工作中遇到的那樣，產品需求文檔越來越被重視，因此整理了這份文檔方便大家日後在工作中，更加快速的構建自己的產品需求文檔。

此文檔由Axure構建。

首先我整理了我對此文檔需求的結構如下：

本次採用的是一個項目中多平臺多版本的控制模式，方便管理同一項目中的不同類型任務需求，主要包含了兩部分：產品簡介 產品文檔，接下來，我將根據每一部分做具體的用法介紹。

產品簡介使用介紹

1. 產品簡介

對項目本身進行簡短的介紹，方便理解本次項目的幾個主要組成部分：

簡要說明產品的使用價值我是誰（一兩句話寫清楚產品的身份）？我有什麼用（我是做什麼的，我能提供什麼服務等）？為什麼選擇我們（與競爭對手相比，我們產品的優勢，核心競爭力是什麼）？目標用戶、使用場景產品的主要用戶群是誰？用戶主要在什麼場景下使用我們的產品。行業概要簡要闡述行業現狀未來的發展趨勢競爭對手情況分析

2. 版本說明

這裡主要是對自己的項目進行版本更替說明，以及多平臺項目進行版本說明，做好版本連結到對應的產品文檔當中去。

3. 自查表

這裡主要列出了當我們在進行文檔撰寫過程中，所需要注意的事項，方便完成文檔後，對文檔進行自查，完善文檔的不足之處。是否完成列表欄採用的是文字圖標進行對錯的標識，這套文字圖標是我經常使用的，附上連結 http://www.axureux.com/home/fontawesome.html

產品文檔使用介紹

根據版本說明創建對應的產品文檔，並在版本說明中做好對應版本的連結跳轉（採用的是在新標籤中打開），產品文檔命名方式是「平臺-版本名」，方便區分。接下來主要針對產品文檔的各個頻道進行說明，方便大家更好的進行修改和使用。

1. 菜單欄

組成部分：項目名稱 頻道欄目一級切換 子屬性二級切換 不同產品文檔的切換。

本菜單除開二級切換，其餘部分採用的是母版製作，所以大家可以根據自己的需求進行調整。

對應彈出選項採用的是動態面板製作，可以根據不同欄目進行管理，按需求進行增減與調整。

對應不同產品文檔的切換做好連結跳轉，因為我裡面只有一個文檔所以沒做連結，同樣這個使用動態面板製作，可以按需增減與調整，做好連結跳轉到對應產品文檔的更新日誌頁面即可。

2. 產品概覽使用介紹

這個欄目主要包括了更新日誌 需求列表 開發排期。

更新日誌：主要記錄此文檔的修改記錄，方便查閱負責人與修改人，以及修改內容時間等信息。

需求列表：列出本次版本項目，所需開發的新功能和調整的功能，說明原因，方便後面對調整新增的功能進行測試，排查遺漏。

開發排期：對項目進行時間點安排，及時跟進項目進度（要每天更新當前進度），推進項目進行，如果大家有使用其他在線工具進行項目進度管理也可以在排期詳情中附上連結，方便查閱更加詳盡的開發進度。

3. 產品架構

這個欄目主要包括了實體關係圖 結構圖 業務流程圖 任務流程圖 頁面流程圖，這個欄目主要是產品在梳理項目需求所使用的。

實體關係圖（又稱ER圖）：我在文檔中也示例了2個實體關係圖的畫法，此圖主要是理清實體（數據對象）及其屬性的相關聯繫。

實體關係圖例如：

結構圖：包含了產品結構圖和產品信息結構圖，區分了這兩個結構圖的差異，這個是產品在工作中經常用到的，對產品的欄目，頻道，頁面，模塊、元素進行梳理。

產品結構圖，例如：

產品信息圖，例如：

業務流程圖：

通過業務流程圖，鑽研關鍵事件的流程，分析為什麼要這麼做，探索出更深層次的問題，從而對現有不合理的業務流程進行重組優化，進而制定優化方案，改進現有流程。主要使用泳道圖來進行繪製，闡述在項目中各個角色是如何產生相關聯繫。

業務流程圖，例如：

任務流程圖：基於業務流程，進行任務流程梳理，闡述角色和程序發生交互的流程，你如何進行操作，系統如何進行反饋。

任務子流程圖：

頁面流程：

根據不同的子任務流程，對其交互過程中所需的頁面及其操作點，進行梳理，方便理解各個頁面間的跳轉關係，是如何產生聯繫的。這個我認為是很關鍵的，不是簡單的將頁面關聯在一起就完成了，而是通過任務流程，理解頁面間是如何產生彼此聯繫。這樣可以更好的思考，流程是否完善，能否提高用戶體驗，並對頁面進行優化。

頁面總流程圖：

4. 產品原型

這個欄目主要包括了全局說明 控制項規範 交互原型 交互說明，這個欄目主要是產品與UI、程序配合時使用，通過原型圖能更好的闡述產品的整體樣貌。

全局說明：主要對產品的通用性進行說明，譬如：z軸內容層級、屏幕適配性、功能權限、加載方式、彈層樣式、欄位屬性、異常狀況、頁面交互方式，根據項目本身進行通用性的闡述。

這裡我只列出了幾項，大家可以根據自己的需求添加欄目和相應頁面。

控制項規範：對自己在原型中使用的一些元素、控制項、組件做統一的規範，這邊要感謝@大梨，這邊我使用的是他整理的web元件以及移動元件，具備統一性， 整個原型項目看上去才會更加簡潔美觀。

掛載了兩套，大家可以根據自己需求調整內聯框架的跳轉，以及也可以自己製作相關的控制項，保證原型項目的一致性。

交互原型：這裡主要展示帶交互的原型，原型的目錄結構可以按照產品結構圖定義好的頁面進行。

交互說明：這裡主要對原型頁面進行描述說明，根據用戶與界面之間發生的交互操作，提供相應的反饋，可能是提示內容，也可能是界面內或界面之間的跳轉。

在這之前可以設置一個目錄頁，用來快速調整每個頁面的說明。

這裡提供了兩種交互說明的方式：一種站點地圖方式，按照產品的信息結構，對每個頁面進行描述，一個頁面一個描述。如下：

另一種方式是：流程分解方式，控制一個流程3-4個頁面，以流程的方式對其進行描述介紹。

如下：

此架構用圖來自 Qinsman，感謝！

大家可以根據項目對原型說明的具體需求進行選擇，我比較常用第一種，方便頁面的調整和修改。

5. 非功能需求

這裡包含了三部分：埋點需求 性能需求 兼容性需求，對產品中的非功能需求進行描述，根據自身需求進行添加。

6. 用例文檔

這裡包含了四部分：角色說明 用例關係 活動過程 用例描述。

用例圖是UML的一種類圖表現方式，是從用戶角度描述產品功能，並指出該用戶在產品各功能中的操作權限。流程圖是通過線框圖形的方式描述產品功能的處理過程，主要是描述功能的執行順序、分支和循環的邏輯。

7. 需求卡片

主要用來採集需求，往往在項目進行中可能會根據一些情況對需求進行調整，這裡我們需要對需求進行整理，方便後續查看，主要包含了：

需求編號：該需求的編號或序號，可以是時間 序號的形式，如：20150430-001。

需求類型：分為功能性需求和非功能性需求。

功能性需求：主要涉及產品邏輯架構、交互、功能以及BUG類的需求，這些需求的重要性較高，因為涉及到產品的正常使用。非功能性需求：主要涉及產品的UI設計等等，如某個按鈕應該為矩形還是圓角矩形，這些需求重要性較低，並不影響產品的正常使用。

需求來源：該需求主要提出的人員以及提出的場景。

提出人員：該需求提出人員的詳細信息，如性別、年齡、教育程度、崗位經驗等信息，這有助於產品經理了解該需求所對應的用戶類型，能夠在需求梳理時，了解某個用戶群體的需求類型。提出場景：該需求提出的使用場景、如地點、環境和時間等，便於產品經理了解用戶是在何種條件下會使用該需求所涉及的功能，如果該需求提出場景是經常發生的，那麼該需求的重要性就會相對有所提高。

需求描述：這是單項需求卡片最為重要的要素，該部分主要體現的是需求的詳細內容，如需求所涉及的現象，希望得到解決的方案等等。該要素會對需求產生各種描述，需要產品經理在整理需求時，進行思考、分析和歸納。

需求原因：該需求提出的原因，該部分可能會在「需求描述」中也予以體現，主要體現的是提出該需求的主要原因，該部分便於產品經理對需求描述進行歸納總結。

需求屬性：分為重要性、緊迫性以及持續時間。

重要性：該需求對於產品的重要程度，該需求的完善對於產品的成長運營具有積極意義；緊迫性：該需求完善的時間要求，主要體現在功能類需求，其中BUG類需求最高，該需求的解決便於產品的正常使用；持續性：該需求的持續時間長度，主要體現為該需求是否能夠隨著產品的不停迭代更新，依舊能夠對產品的使用發揮作用。

本文由 @時光若刻 原創發布於人人都是產品經理。未經許可，禁止轉載

題圖來自 Pixabay，基於 CC0 協議

,