引言：如何快速交付一篇需求文檔（prd）？本文將從產(chǎn)品思維的視角拆解快速完成一篇項目制的需求文檔。愿對君有所裨益。

什么是PRD?

1. 文檔目的：

常規(guī)需求文檔的用途總體分為兩類：一種是細化需求，用于給開發(fā)傳達產(chǎn)品需求；另外一種，也是本文主講的，適用于項目制交付給甲方，給客戶傳達業(yè)務(wù)需求，對內(nèi)給開發(fā)傳達產(chǎn)品需求。

2. 文檔受眾：

明確你的PRD有哪些讀者，一般包括：項目參與人員（項目經(jīng)理、前端、后端、測試、UI設(shè)計、產(chǎn)品經(jīng)理），項目甲方（客戶），市場人員 ，運營人員，領(lǐng)導(dǎo)或者老板。

主要閱讀受眾的不同會決定整個文檔的格式，文字情感色彩。給內(nèi)部領(lǐng)導(dǎo)、政府、大型企業(yè)的客戶交付，整體寫作文案偏向概括與宏觀，更多的“互聯(lián)網(wǎng)黑話”；給小型客戶，內(nèi)部人員使用，就更接地氣，偏向于常規(guī)的互聯(lián)網(wǎng)文案基調(diào)更注重實用性。

3. 文檔價值：

三個重點：專業(yè)性、易讀性、可用性。

對客戶來說體現(xiàn)產(chǎn)品設(shè)計的專業(yè)度，既保證滿足客戶商業(yè)需求（比如演示，宣講，內(nèi)部存檔入庫）；對內(nèi)部團隊來說，能快速理解產(chǎn)品設(shè)計中的產(chǎn)品架構(gòu)、業(yè)務(wù)規(guī)則、異常情況、特殊字段、交互流程、設(shè)計原則，同時文檔易于不同人員查看理解，簡潔精煉，降低團隊內(nèi)溝通成本。

4. 文檔編輯工具

編輯文檔工具不受限制，這里推薦在線軟件，例如某企鵝的產(chǎn)品等，這類軟件有個特點，在設(shè)置大綱級別特別方便，容易調(diào)整文檔格式。

如何寫好PRD?

事前準(zhǔn)備（用產(chǎn)品思維思考）：

明確目標(biāo)用戶：明確你的PRD的目標(biāo)用戶，到底是誰看？（老板？業(yè)務(wù)方？團隊？）

確認用戶需求與解決的問題：確認PRD讀者的需求，哪類客戶群體偏多，決定文檔的結(jié)構(gòu)與文檔側(cè)重點；PRD最根本的目的還是減少溝通成本符和各方人員查看需求說明。

規(guī)劃架構(gòu)藍圖：先用思維導(dǎo)圖羅列文檔大綱，圈住寫的范圍與整體內(nèi)容框架。

做好具體細節(jié)準(zhǔn)備：包括提前做好產(chǎn)品信息結(jié)構(gòu)圖，功能清單，核心業(yè)務(wù)流程圖，原型設(shè)計等

1.命名與封面

常規(guī)命名公式：產(chǎn)品名稱+功能模塊+版本號，大部分甲方客戶會有特殊格式要求比如:內(nèi)部項目編號+產(chǎn)品名稱+VX.Y（X.Y為版本號）

封面常規(guī)格式：

●企業(yè)名稱（部門名稱）+項目名稱+項目編號+需求說明文檔

●文檔編碼或者文檔總頁數(shù)

●簽字方

●文檔修改記錄

根據(jù)具體要求進行調(diào)整，如果僅內(nèi)部使用可以簡化，文檔修改記錄不可刪除，方便團隊溯源。

2.文檔結(jié)構(gòu)

PRD文檔內(nèi)容結(jié)構(gòu)包括：文檔目的、名詞解釋（術(shù)語定義與縮略詞）、文檔編寫規(guī)范、系統(tǒng)概述（產(chǎn)品背景、目的）、功能架構(gòu)、功能清單、業(yè)務(wù)流程圖、業(yè)務(wù)用例、全局說明（交互說明、全局規(guī)則等）、非功能性需求。如果有相關(guān)文檔，附件說明。

文檔目的

顧名思義寫作本文檔的目的是什么，前文有詳寫故此不做過多贅述

名詞解釋

產(chǎn)品中涉及的一些專業(yè)術(shù)語的定義，與特殊字段的解釋與規(guī)則。例如在做政府的圖書管理后臺系統(tǒng)時（本文案例均來自此系統(tǒng)）涉及的名詞如下:

文檔編寫規(guī)范

整個文檔的編寫規(guī)范，對于格式要求比較嚴格甲方客戶，一般需要進行說明，內(nèi)部溝通可忽略。以下是常規(guī)的規(guī)范定義，可以根據(jù)自身寫作習(xí)慣進行調(diào)整，能解釋說明清楚，全文運用符號規(guī)范一致即可。

系統(tǒng)概述

主要是對整個產(chǎn)品的設(shè)計背景，解決的什么問題的描述。如果有條件利用chatgpt等一類AI平臺，可以比較快速的總結(jié)出來宏觀性的背景文案。如下：

這里涵蓋兩個方法：一個是寫prompt（提示指令）的原則，給AI進行下定義，盡量走多角度，多定義，多元素，寫明自己需要咨詢問題的前后要求與背景。二是提取數(shù)據(jù)的方法，所有AI生成的答案只是參考，需要將對應(yīng)的結(jié)構(gòu)化表述結(jié)合實際情況進行歸納整理。提取方法：抓取關(guān)鍵字+實際概念替換回答中通用性概念+結(jié)合實際業(yè)務(wù)做減法；如果需要更接地氣背景目的可以詳細描述產(chǎn)品的目的以及解決的實際問題，與預(yù)計帶來的收益效果。

再者，這部分也可以加入一些系統(tǒng)的規(guī)劃藍圖，例如整個系統(tǒng)的藍圖，參考格式：應(yīng)用層，業(yè)務(wù)層，技術(shù)層。

功能架構(gòu)

整個產(chǎn)品的功能結(jié)構(gòu)圖，常用腦圖形式進行展示，具體格式不限。包括系統(tǒng)層（具體系統(tǒng)應(yīng)用表現(xiàn)形式）、業(yè)務(wù)層（具體功能模塊與功能點）、權(quán)限結(jié)構(gòu)。

比如圖書管理系統(tǒng)系統(tǒng)層就涉及用戶端、管理端兩個系統(tǒng)。對應(yīng)系統(tǒng)對應(yīng)不同的功能結(jié)構(gòu)。參考如下：

功能清單

角色權(quán)限

業(yè)務(wù)流程圖

業(yè)務(wù)流程圖可選取泳道圖進行圖示，主要體現(xiàn)用戶在系統(tǒng)中的關(guān)鍵業(yè)務(wù)節(jié)點與操作流程，以及對應(yīng)數(shù)據(jù)的流向。一般分為兩個部分，一個是全局的流程圖，一個是關(guān)鍵業(yè)務(wù)節(jié)點的流程圖。

可選的流程圖類型有：業(yè)務(wù)流程圖，狀態(tài)流程圖，時序圖，數(shù)據(jù)流程圖。

簡要說下泳道圖的編輯規(guī)范：頭部為不同業(yè)務(wù)模塊，下方是對應(yīng)操作流程，如果角色眾多，左側(cè)可以對角色進行區(qū)分，以下是圖書管理系統(tǒng)的管理員業(yè)務(wù)流程示例：

業(yè)務(wù)用例

業(yè)務(wù)用例（Business Use Case）是指通過場景、流程圖、角色、業(yè)務(wù)規(guī)則等方式，描述用戶在使用產(chǎn)品時的操作流程和業(yè)務(wù)邏輯。可以理解為，對功能點的詳細描述，對字段的規(guī)則定義，對業(yè)務(wù)規(guī)則的描述。這里是整個文檔的核心，也是開發(fā)人員需要重點關(guān)注的對象。內(nèi)部溝通時，大部分開發(fā)沒有耐心去看你的整個文檔，所以建議重點維護此部分，將所有開發(fā)過程中需要注意的規(guī)則都寫明寫仔細，開發(fā)人員只需要查看此部分即可。業(yè)務(wù)用例同樣也分為兩個部分，全局業(yè)務(wù)用例（清單+用例圖）和具體業(yè)務(wù)用例。

參考結(jié)構(gòu)：用例概述+用例描述+業(yè)務(wù)流程（或者UML用例圖）+頁面原型+特殊說明

用例拆分原則：可以從后端接口設(shè)計的角度，或者功能點的角度進行拆分，最快捷的方式用增刪改查的視角進行拆分，比如訂單模塊：新建訂單，編輯訂單，刪除訂單，訂單查詢。

參考示例：

全局用例清單：

具體用例清單：

用例名稱：外借報表查詢

●概述

管理員在[外借報表]列表頁，查詢圖書外借信息，對外借圖書進行維護與管理。

全局說明

此模塊是指整個系統(tǒng)的全局說明，為了減少我們prd的寫作工作量，一般會把大部分通用規(guī)范與通用原則在此處進行整理。

●交互規(guī)則：包含頁面加載、按鈕點擊、頁面滾動、toast提醒交互、數(shù)據(jù)為空、彈窗交互樣式、頁面布局、選中樣式、獲取焦點樣式、通用的一些交互組件等。B端系統(tǒng)和C端系統(tǒng)略有不同，app、小程序、H5也存在差異。

●數(shù)據(jù)規(guī)則：描述產(chǎn)品的數(shù)據(jù)規(guī)范和限制，包括全局的數(shù)據(jù)生成規(guī)則、分頁處理、數(shù)據(jù)極值、全局通用性的數(shù)據(jù)規(guī)范，默認值等

●業(yè)務(wù)規(guī)則：一些全局通用的業(yè)務(wù)規(guī)則，比如數(shù)據(jù)的導(dǎo)入導(dǎo)出，按鈕防連擊處理

●接口規(guī)則：描述產(chǎn)品的接口規(guī)范和限制，包括接口格式、接口參數(shù)、接口安全等方面。例如，要求接口遵循RESTful API的設(shè)計原則，保證接口的可擴展性和易用性。這里更多是和后端開發(fā)或者技術(shù)經(jīng)理進行討論確定。有條件提供。

●測試規(guī)則：描述產(chǎn)品的測試規(guī)范和流程，包括測試用例、測試流程、測試環(huán)境等方面。也是屬于有條件提供，一般有測試人員，和測試討論出結(jié)果，不要過多干涉其他領(lǐng)域?qū)I(yè)人員的處理意見。

●其他說明：特定情況下的一些備注。

以下是部分示例：

非功能性需求

非功能性需求是描述產(chǎn)品功能以外的要求，通常與產(chǎn)品的性能、安全性、可靠性、可維護性、可用性、可擴展性、兼容性等相關(guān)。以下是一些常見的非功能性需求：

●性能要求：描述產(chǎn)品的性能指標(biāo)，例如響應(yīng)時間、并發(fā)數(shù)、吞吐量、負載能力等。

●安全要求：描述產(chǎn)品的安全需求，包括用戶身份認證、數(shù)據(jù)加密、安全審計、訪問控制等。

●可靠性要求：描述產(chǎn)品的可靠性需求，包括系統(tǒng)可用性、容錯能力、恢復(fù)能力等。

●可維護性要求：描述產(chǎn)品的可維護性需求，包括代碼可讀性、可擴展性、可維護性等。

●可用性要求：描述產(chǎn)品的可用性需求，包括用戶界面友好、易用性、可訪問性等。

●可擴展性要求：描述產(chǎn)品的可擴展性需求，包括系統(tǒng)架構(gòu)、組件化設(shè)計、擴展性設(shè)計等。

●兼容性要求：描述產(chǎn)品的兼容性需求，包括與其他系統(tǒng)的集成、不同瀏覽器、操作系統(tǒng)等的兼容性。

下方是示例：

文檔收尾

常見的尾部內(nèi)容有：補充規(guī)約、補充附件、參考文獻等，這里不過多說明，利用好搜索引擎即可。

以上就是編寫一篇完整prd的全部內(nèi)容，每個人所處的企業(yè)，項目環(huán)境都不相同，具體細致要求會存在一定差異，這時候自己就要學(xué)會變通，利用好互聯(lián)網(wǎng)的便捷，多查閱資料，多學(xué)習(xí)同行經(jīng)驗，對文檔質(zhì)量進行提升。prd最根本的目的還是為了高效溝通，傳遞各方需求與產(chǎn)品設(shè)計方案，所以不管怎樣，仍是以效率為主。希望看完此文后對你未來產(chǎn)品工作有一定參考意義與實際的幫助。

喜歡的點個贊，轉(zhuǎn)載請注明來源出處?。?！