寫了多年P(guān)RD后，他總結(jié)了PRD語法、形式、自查（附大廠模板）

邏輯過重的后端需求，干脆就使用Word/Excel/TXT格式的PRD。

好處是在行文的過程中，可以二次梳理思路，暴露問題。

一般這樣的需求文檔都包括：

版本說明(含變更日志)、背景、目標、需求范圍、需求用例（正文，包含所有核心內(nèi)容，如功能邏輯說明等）、參考資料等。

（1）需求背景

• 現(xiàn)狀

  當前業(yè)務(wù)流程怎么了，當前功能是怎么樣的，問題是什么，需要怎么辦，以達到什么目標。

• 用戶故事

  也可以更簡單的以“作為誰，希望通過什么，實現(xiàn)什么”這樣的用戶故事形式也可以。

• 場景

  是需求的外在，拆解和窮盡需求場景，為窮盡功能和邏輯規(guī)則打基礎(chǔ)。拆解需求場景的方法：

 按業(yè)務(wù)順序，想象或模擬用戶操作順序；

 按目標生命周期，比如草稿、待審核、審核中；

 按正常、異常、正向、逆向，形成交叉矩陣。

（2）需求目標

用戶角度的驗收標準，即從效果的角度表達需求的預期（不表達如何實現(xiàn)）。

例如：

a、用戶在點擊頁面之后3秒內(nèi)必須加載完成。  

b、用戶能看到自己買到的商品。 

c、用戶可以刪除自己的商品購買記錄。

（3）需求范圍

需求范圍就是描述需求的目標項、邊界、排除項，其作用是理清邊界。

目的是防止需求蔓延（參考PMBOK指南）。

需求范圍可以使用功能框架圖。

需求用例是需求的正文部分。

先將需求分成任務(wù)點，進行描述。

描述的語句要嚴格按照文檔語法原則進行（下文會繼續(xù)聊到）。

如下圖：

二、PRD的語法

這里主要以Word樣式的PRD為對象。

1、需求文檔的語法

（1）說明文一字千金

需求文檔就像是說明書一，去掉形容詞、比喻句、副詞等。

（3）避免用詞不當

在文檔或口頭交流的時候，經(jīng)常用到諸如“維度”、“顆粒度”、“參數(shù)”、“字段”、“項”、“列”、“表”等詞匯。

產(chǎn)品需求文檔中，要做到用詞嚴謹，避免詞語歧義或失準。

常見用法例如：

 以“訂單號+產(chǎn)品編碼”的[維度]進行唯一性判斷；

 按照“訂單”[顆粒度]進行匯總；

 以“時間”作為請求[參數(shù)]；

 數(shù)據(jù)庫的[字段]為“number”；

 頁面搜索欄的“姓名”搜索[項]；

 頁面列表的“年齡”[列]。

（4）按順序描述

開發(fā)和測試人員通常希望將一個模塊的工作做完，再進行下一個，而不是來回跳。

因此行文順序上，按照先后、左右、大小等常規(guī)的順序進行，一個模塊寫完再寫下一個。

前面寫過的內(nèi)容，后面不要再寫了，避免歧義。

比如：要在已有接口增加獲取一個字段，并在頁面展示，可以這樣兩步描述：

a、在xx接口，增加xx字段，存入數(shù)據(jù)庫xx表。接口邏輯調(diào)整為xx。舊數(shù)據(jù)初始化方案是xx。 

b、在xx頁面列表中，新增一列“xx”，對應(yīng)取值是數(shù)據(jù)庫xx表中的字段xx。

（5）以“在哪里，做什么”為主線

文檔以任務(wù)線為核心句式結(jié)構(gòu)，即：“在哪里，做什么”。

盡量用正向語序，不要倒敘，也不要用括號或破折號。

比如避免前面描述完，后面又接著一個“即xxxxx”、“也就是說xxxxx”。

（6）非本需求的功能，不要放在文檔中

產(chǎn)品經(jīng)理是信息布道者，信息中樞。

而開發(fā)和測試人員，是希望所見即所得的閱讀方式。所以不必要的任務(wù)不要加入進來。

比如不要使用“可能這次要做”、“注意，這個本次不做，只作為提前知悉”之類的內(nèi)容。

正文一定傳達的是“做什么”。如果想補充，那么放在參考資料部分。

（7）采用合適的行文結(jié)構(gòu)

1）如果需要在舊功能基礎(chǔ)上做優(yōu)化，可以用對比結(jié)構(gòu)進行描述，比如：

• 修改前：xxxx；

• 修改后：xxxx；

2）對于并列條件較多的，可以用平行列舉的結(jié)構(gòu)描述，比如：

每天一次，定時監(jiān)控【退款單】(表f_oms_refund)，若同時滿足下列條件：

同時滿足上述條件，則進行數(shù)據(jù)抓取。

①數(shù)據(jù)更新時間為前兩天；

 ②退款成功的（refund_status為：2、5、8、12、24任一個）；

 

 ③rma_sn不為空；

 ④order_sn已存在于【發(fā)票列表】中。

注意：如果不熟悉數(shù)據(jù)庫，建議不要寫數(shù)據(jù)庫，而是要寫清楚頁面取值位點并配以截圖，避免弄巧成拙。

3）如果需求點有多個，但屬于同一個頁面功能模塊下的，那么可以放在一個用例中，分點描述，就像書本的目錄一樣進行編號。

（8）窮盡原則

“窮盡”是方案嚴謹?shù)幕A(chǔ)。

窮盡包括窮盡需求的功能點，窮盡每個功能點的要素，窮盡每一個邏輯判斷、性能要求、異常機制、用戶權(quán)限等。

比如：做一個新頁面，就要從導航欄目、界面交互、搜索功能、網(wǎng)站介紹性文字、默認列表展示內(nèi)容、列表數(shù)據(jù)統(tǒng)計等全部說清。

同時對于后端產(chǎn)品而言，基本上每個需求都要說明性能要求、異常機制等。

（9）最后，不要遺漏對性能的要求、對歷史數(shù)據(jù)是否處理、以及權(quán)限要求

性能的要求，如果不懂技術(shù)術(shù)語，則寫出性能支持的數(shù)據(jù)或現(xiàn)象范圍。

比如：預計半年內(nèi)數(shù)據(jù)量為100萬/天，要求接口響應(yīng)3s內(nèi)。

歷史數(shù)據(jù)是否要初始化，及與發(fā)版的時間順序。

權(quán)限就是賦予頁面數(shù)據(jù)、功能權(quán)限。

2、通用項進行統(tǒng)一

（1）命名統(tǒng)一

頁面一些常見的插件的命名可能有多個版本，產(chǎn)品經(jīng)理需一開始就在需求文檔中確定用哪一個。

比如下面這幾組意思相近的插件名稱：

a、表示刪除或禁用的：刪除、禁用、關(guān)閉、封存；

b、表示啟用的：開啟、啟用、生效；

c、表示設(shè)置的：配置、設(shè)置；

d、表示編輯的：編輯時間、修改時間、更新時間、操作時間。

（2）數(shù)據(jù)庫表中的通用字段命名統(tǒng)一（開發(fā)負責的）

比如：

每個開發(fā)習慣不同，所以要固定用哪一種，避免千人千面。

a、是否已寫入：用“is_use”、“is_used”還是“is_write”表示？

 

b、已寫入/未寫入：用“1/0”，還是用“1/2”表示？

筆者曾經(jīng)遇到一個開發(fā)比葫蘆畫瓢，把“goods_sn”（商品編碼），寫成“good_sn”，這就鬧笑話了。

（3）頁面展示統(tǒng)一

比如：數(shù)據(jù)表為空字符串時，前端展示什么，是顯示“/”，還是空白？