4千字，總結產品需求文檔的形式、規(guī)范、自查
本文總結一個最基礎的話題：PRD。目錄如下： 一、PRD的形式
二、PRD的規(guī)范三、PRD的自查方法
一、PRD的形式
1、原型附帶文字
移動端產品當然是把產品DEMO展示出來為第一位。
附帶的文字，多是對原型的交互的說明、取值邏輯說明等。
比如這樣：
比如這樣：
2、文字附帶原型
邏輯過重的后端需求，干脆就使用Word/Excel/TXT格式的PRD。
好處是在行文的過程中，可以二次梳理思路，暴露問題。
一般這樣的需求文檔都包括：
版本說明(含變更日志)、背景、目標、需求范圍、需求用例（正文，包含所有核心內容，如功能邏輯說明等）、參考資料等。
（1）需求背景
現狀
當前業(yè)務流程怎么了，當前功能是怎么樣的，問題是什么，需要怎么辦，以達到什么目標。
用戶故事
也可以更簡單的以“作為誰，希望通過什么，實現什么”這樣的用戶故事形式也可以。
場景
是需求的外在，拆解和窮盡需求場景，為窮盡功能和邏輯規(guī)則打基礎。拆解需求場景的方法：
按業(yè)務順序，想象或模擬用戶操作順序；
按目標生命周期，比如草稿、待審核、審核中；
按正常、異常、正向、逆向，形成交叉矩陣。
（2）需求目標
用戶角度的驗收標準，即從效果的角度表達需求的預期（不表達如何實現）。
例如：
a、用戶在點擊頁面之后3秒內必須加載完成。
b、用戶能看到自己買到的商品。
c、用戶可以刪除自己的商品購買記錄。
（3）需求范圍
需求范圍就是描述需求的目標項、邊界、排除項，其作用是理清邊界。
目的是防止需求蔓延（參考PMBOK指南）。
需求范圍可以使用功能框架圖。
需求用例是需求的正文部分。
先將需求分成任務點，進行描述。
描述的語句要嚴格按照文檔語法原則進行（下文會繼續(xù)聊到）。
如下圖：
（5）參考資料
參考資料部分，附上調研過程中查到的相關模板、數據表、腳本、接口地址、歷史文檔、原型鏈接等。
二、PRD的規(guī)范
這里主要以Word樣式的PRD為對象。
1、需求文檔的語法
（1）說明文一字千金
需求文檔就像是說明書一，去掉形容詞、比喻句、副詞等。
能用一句話說明的就不要說第二句。（3）避免用詞不當
在文檔或口頭交流的時候，經常用到諸如“維度”、“顆粒度”、“參數”、“字段”、“項”、“列”、“表”等詞匯。
產品需求文檔中，要做到用詞嚴謹，避免詞語歧義或失準。
常見用法例如：
以“訂單號+產品編碼”的[維度]進行唯一性判斷；
按照“訂單”[顆粒度]進行匯總；
以“時間”作為請求[參數]；
數據庫的[字段]為“number”；
頁面搜索欄的“姓名”搜索[項]；
頁面列表的“年齡”[列]。
（4）按順序描述
開發(fā)和測試人員通常希望將一個模塊的工作做完，再進行下一個，而不是來回跳。
因此行文順序上，按照先后、左右、大小等常規(guī)的順序進行，一個模塊寫完再寫下一個。
前面寫過的內容，后面不要再寫了，避免歧義。
比如：要在已有接口增加獲取一個字段，并在頁面展示，可以這樣兩步描述：
a、在xx接口，增加xx字段，存入數據庫xx表。接口邏輯調整為xx。舊數據初始化方案是xx。
b、在xx頁面列表中，新增一列“xx”，對應取值是數據庫xx表中的字段xx。
（5）以“在哪里，做什么”為主線
文檔以任務線為核心句式結構，即：“在哪里，做什么”。
盡量用正向語序，不要倒敘，也不要用括號或破折號。
比如避免前面描述完，后面又接著一個“即xxxxx”、“也就是說xxxxx”。
（6）非本需求的功能，不要放在文檔中
產品經理是信息布道者，信息中樞。
而開發(fā)和測試人員，是希望所見即所得的閱讀方式。所以不必要的任務不要加入進來。
比如不要使用“可能這次要做”、“注意，這個本次不做，只作為提前知悉”之類的內容。
正文一定傳達的是“做什么”。如果想補充，那么放在參考資料部分。
（7）采用合適的行文結構
1）如果需要在舊功能基礎上做優(yōu)化，可以用對比結構進行描述，比如：
修改前：xxxx；
修改后：xxxx；
2）對于并列條件較多的，可以用平行列舉的結構描述，比如：
每天一次，定時監(jiān)控【退款單】(表f_oms_refund)，若同時滿足下列條件：
同時滿足上述條件，則進行數據抓取。
①數據更新時間為前兩天；
②退款成功的（refund_status為：2、5、8、12、24任一個）；
③rma_sn不為空；
④order_sn已存在于【發(fā)票列表】中。
注意：如果不熟悉數據庫，建議不要寫數據庫，而是要寫清楚頁面取值位點并配以截圖，避免弄巧成拙。
3）如果需求點有多個，但屬于同一個頁面功能模塊下的，那么可以放在一個用例中，分點描述，就像書本的目錄一樣進行編號。
（8）窮盡原則
“窮盡”是方案嚴謹的基礎。
窮盡包括窮盡需求的功能點，窮盡每個功能點的要素，窮盡每一個邏輯判斷、性能要求、異常機制、用戶權限等。
比如：做一個新頁面，就要從導航欄目、界面交互、搜索功能、網站介紹性文字、默認列表展示內容、列表數據統計等全部說清。
同時對于后端產品而言，基本上每個需求都要說明性能要求、異常機制等。
（9）最后，不要遺漏對性能的要求、對歷史數據是否處理、以及權限要求
性能的要求，如果不懂技術術語，則寫出性能支持的數據或現象范圍。
比如：預計半年內數據量為100萬/天，要求接口響應3s內。
歷史數據是否要初始化，及與發(fā)版的時間順序。
權限就是賦予頁面數據、功能權限。
2、通用項進行統一
（1）命名統一
頁面一些常見的插件的命名可能有多個版本，產品經理需一開始就在需求文檔中確定用哪一個。
比如下面這幾組意思相近的插件名稱：
a、表示刪除或禁用的：刪除、禁用、關閉、封存；
b、表示啟用的：開啟、啟用、生效；
c、表示設置的：配置、設置；
d、表示編輯的：編輯時間、修改時間、更新時間、操作時間。
（2）數據庫表中的通用字段命名統一（開發(fā)負責的）
比如：
每個開發(fā)習慣不同，所以要固定用哪一種，避免千人千面。
a、是否已寫入：用“is_use”、“is_used”還是“is_write”表示？
b、已寫入/未寫入：用“1/0”，還是用“1/2”表示？
筆者曾經遇到一個開發(fā)比葫蘆畫瓢，把“goods_sn”（商品編碼），寫成“good_sn”，這就鬧笑話了。
（3）頁面展示統一
比如：數據表為空字符串時，前端展示什么，是顯示“/”，還是空白？
可以使用日期+模塊名+需求名稱+作者+版本號，例如：20180920_【個人資料】編輯個人資料優(yōu)化_張三_V1.0。
三、PRD的自查
需限定輸入的范圍，做輸入校驗。
示例：最多輸入10個數值，輸入不合規(guī)則的內容，則在輸入框下方紅色字體提示，比如：“請不要輸人漢字！”。
（2）下拉框
下拉的同時是否支持輸入搜索，是否支持多選。
（3）導入文檔
表頭校驗、自校驗、與系統校驗、寫入邏輯（全部不予導入或部分導入)、下載結果文檔；
（4）已有功能的邏輯規(guī)則變更
則要考慮舊數據兼容或初始化。
（5）基礎數據刪除
則要考慮基礎數據被調用的地方，刪除和編輯怎么處理。
比如：
商品分類中維護的“商品類型”被刪除，那么再編輯和刪除該分類下的歷史數據的時候就可能報錯，所以基礎數據維護時候要校驗調用情況。
（6）設置規(guī)則
考慮規(guī)則去重、規(guī)則優(yōu)先級。
一般情況下，沒有優(yōu)先級的話，規(guī)則的去重和命中次序校驗起來比較麻煩。（在<后端產品經理寶典>一書中有專門介紹）。
（7）列表的數據的排序
一般按照修改時間的倒敘排列，也可以用數據庫id代替序號。
用數據庫id的好處是，方便用戶和技術協作追溯數據。
（8）異常機制
每時每刻都要有逆向思維，告訴開發(fā)人員什么算異常？異常了怎么標示出來。
比如：
表1字段A，匹配表2字段B，將匹配成功的數據寫入表3。就要考慮表1中字段A為空的情況該怎么辦。
（9）頁面長期不登錄
則給自動退出。主要考慮到后端系統的保密性。
（10）凡是帶操作的
一般都要設置頁面權限。
最簡單的方式是所有系統的權限都分三個等級：不能查看、只能查看、可以編輯。
（11）功能修訂
比如規(guī)則變更，需要考慮舊數據是否要按照新規(guī)則進行初始化。
2、按需求類型自查
（1)功能需求
需要窮盡功能覆蓋的使用場景，窮盡本功能相關聯的各個系統模塊，窮盡本功能的用戶角色、權限。
（2)性能需求
數據量較大時的系統壓力、反應速度；
批量上傳、下載要考慮數量上限，考慮是否異步處理；
考慮瀏覽器兼容性；考慮調用接口超時的備用策略等。
（3）安全需求
敏感詞屏蔽（同步過濾和異步召回）、防刷單機制、數據補推機制、風險預警等。
3、關鍵詞提醒自查
筆者不完全羅列了幾個關鍵詞，可以作為自查的維度。
（1）完整
流程是否存在斷頭路。
比如當正常流程無法傳輸的時候，是否可以用導入的機制救急。業(yè)務高峰的系統，是否有降級處理邏輯。
默認：是否給予了默認值。
比如設置規(guī)則功能業(yè)務未設置怎么辦？
4、其他
自查的方式還有很多，比如也可以按照“增、查、改、刪、顯、傳、算”自查等。
總結
需求文檔最基礎，努力做到心中有典型功能，邏輯自查舉一反三，需求要點不缺失，文檔內容不歧義。
產品經理要養(yǎng)成好的態(tài)度和習慣。比如：
1）保持學習學習其他人的文檔書寫長處，可以把好的東西借鑒過來，吸取精華。
2）要自己多看多換位思考，揣摩他人是否能讀懂，把問題止步于自查。
3）請求同事（包括產品經理、程序員、測試員等）幫助互評自己的文檔，接受對方的建議。
4）文檔是改出來的，因此自己寫好后，放一段時間再看，再改。
點擊“閱讀原文”
查看更多干貨