4千字總結(jié)產(chǎn)品需求文檔的形式、規(guī)范、自查

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