你是否遇到過因需求不明確而導致的項目延誤？讓我們一起學習如何通過精確的PRD文檔避免這些問題，保證產(chǎn)品開發(fā)的每一個環(huán)節(jié)都能高效對接、無縫執(zhí)行。

互聯(lián)網(wǎng)產(chǎn)品邏輯復雜，為了保證從到開發(fā)到上線過程中，實施的沒有偏差，大家協(xié)作時需要達成一致并且形成規(guī)范，我們經(jīng)常聽到1個詞“需求”，這個功能沒有按照“需求”開發(fā)，這個“需求”的標準就是PRD文檔，本文總結(jié)了以下幾點，供大家學習和參考：

一、RPD是什么？

PRD（Product Requirement Document），中文意思是：產(chǎn)品需求文檔。它是對需求的具體描述，闡述產(chǎn)品具體要做成什么樣子，要按照什么標準或規(guī)范來做而形成的文檔。

二、為什么要寫PRD？

在互聯(lián)網(wǎng)開發(fā)團隊中有這么幾個角色：UI/UE、前端、后端、測試。產(chǎn)品經(jīng)理設計完后，就需要剛提到的幾個角色來具體實施落地了，首先大家要知道需求是什么？比如說做一個電商系統(tǒng)，公司為什么要做這個系統(tǒng)？這個系統(tǒng)具體要做成什么樣子的？這些問題都要統(tǒng)一落實到文檔，有依據(jù)，所以PRD文檔的最重要作用就是——作為開發(fā)團隊協(xié)作的依據(jù)！

不管前端還是后端都按照文檔開發(fā)，要確保大家按同樣的標準和需求來開發(fā)，開發(fā)同學如果理解上有歧義，有偏差時要依據(jù)文檔，有疑問時，要第一時間跟產(chǎn)品經(jīng)理溝通確認，這樣才能順利的進行后續(xù)的開發(fā)工作，同樣，測試工程師寫測試用例也要依據(jù)產(chǎn)品需求文檔，因為bug的定義是“實際結(jié)果與期望結(jié)果不符”，期望結(jié)果是誰給出的？是產(chǎn)品經(jīng)理，所以源頭都是產(chǎn)品需求文檔。

三、如何寫PRD？

1. 版本記錄

版本記錄的目的是為了清晰的記錄每次變更的內(nèi)容是什么？什么時間發(fā)生的變更？以及提出變更的人是誰。因為隨著產(chǎn)品設計及開發(fā)，需求會有微調(diào)或者改動，而需求變更次數(shù)太多的話，大家的信息獲取有可能產(chǎn)生偏差，有人按照1.0做的，有人按照2.0做的，這時就要有“依據(jù)”，到底哪一版是最新的，最終定版是哪一版，否則會浪費開發(fā)資源。

2. 產(chǎn)品概述/背景

任何實施團隊在做的時候，都務必要明確大家在做的是什么產(chǎn)品/功能，為什么要做這個產(chǎn)品/功能，這個產(chǎn)品/功能解決什么問題，產(chǎn)品經(jīng)理切勿把開發(fā)當工具人，只有讓開發(fā)知道為什么要做，從內(nèi)心認同這個產(chǎn)品時，才能保證后續(xù)的質(zhì)量。

3. 功能需求

1）業(yè)務場景

產(chǎn)品是有很多功能/子功能構(gòu)成，比如說“導入商品”，這就是一個功能，每個功能都是在特定的場景下來解決用戶的特定的需求，比如導入商品，當用戶首次使用系統(tǒng)，并想要批量新增商品時，就產(chǎn)生了這個訴求，“導入商品”這個功能就是在這個場景下解決用戶的訴求的，它屬于降本增效類的功能。寫“業(yè)務場景”時，重點寫在什么場景下，哪一部分用戶產(chǎn)生了什么訴求或遇到了什么問題，系統(tǒng)功能是如何解決這個問題的。

2）需求說明

這部分是整個PRD文檔中最最重要的，因為具體落地實施就是依據(jù)這部分，如果說前面的產(chǎn)品背景有些“虛”，那么這部分就是最最實際，開發(fā)最關心的，然后前后端和測試關注的點不一樣，所以這部分務必要寫的清晰明確全面，從這一部分能看出產(chǎn)品的基本功是否深厚，下面我們來具體說一下這里面要寫什么。

（1）流程圖

流程圖有很多種，有數(shù)據(jù)流、有業(yè)務流程圖、有交互流程圖，有泳道圖，這里根據(jù)公司的需要而定。注意，這里的流程圖不是產(chǎn)品整體的流程圖（因為整體流程圖很復雜，且冗長），這里的流程是具體某個功能的流程圖，重點是要把每個節(jié)點、判斷條件、后置結(jié)果寫清楚，沒有邏輯錯誤，要閉環(huán)。

（2）E-R圖

E-R圖即是數(shù)據(jù)對象之間的關系，1對1、多對1、多對多。寫這個的目的是為了讓后端建表和字段的時候有依據(jù)，比如一筆訂單多次出庫，那么訂單表的1條數(shù)據(jù)就可能對應出庫表里面的多條數(shù)據(jù)。

（3）名詞解釋（定義）

產(chǎn)品在設計需求時，經(jīng)常會自己定義一些概念，這些概念需要有明確的定義，比如“審核中”狀態(tài)的具體定義，再比如“過賬”的含義，這些名詞第一次出現(xiàn)在開發(fā)同學眼里時，他們是不知道的，只有產(chǎn)品自己知道，所以需要明確的寫出來，避免開發(fā)產(chǎn)生歧義。

（4）交互說明

寫“交互說明”主要是給前端同學看的，比如一個下拉框，它默認選中什么，有哪些枚舉值，字數(shù)最多顯示多少，超出顯示不下怎么處理，有沒有禁用狀態(tài)，鼠標懸停和點擊分別是什么效果等等。

（5）各種情況枚舉

這部分比較考驗產(chǎn)品經(jīng)理的全面思維和經(jīng)驗，很多產(chǎn)品同學設計完產(chǎn)品后可能會有遺漏，不是漏了這就是漏了那，這樣開發(fā)會不斷地追問，主要就是沒有窮盡各種情況，而這部分也是測試關心的，因為測試要把99%的場景/情況都測到，才能保證上線后沒有bug，比如商品下架在前端怎么展示，商品刪除了在前端怎么展示，商品沒有庫存在前端怎么展示等等。

下面作者以一個簡單的商品列表為實例，簡單展示下需求說明怎么寫

（6）實例：商品列表

• 數(shù)據(jù)來源：商品表，所有狀態(tài)的商品
• 列表排序規(guī)則：按商品創(chuàng)建時間倒序排列
• 列表加載：默認加載全部列表
• 列表查詢條件：商品名模糊查詢、商品編碼精確查詢
• 列表字段及定義：商品名、商品圖、商品編碼、條碼、狀態(tài)、價格、創(chuàng)建時間、操作
• 列表操作：新增、編輯、刪除、上架、下架、導入等等
• 交互說明：略

需要文檔模板的可以留言。

4、非功能需求

非功能需求主要包括了性能需求、安全性需求、其他合規(guī)性需求等等。

四、總結(jié)

在寫RPD文檔時，每個公司都有每個公司的模板，雖然有區(qū)別，但是本質(zhì)都差不多，只要我們明白了PRD的作用和目的，書寫思路，其實就不必拘泥于具體的形式。