手把手教你寫B端產品PRD

在說B端產品需求文檔如何寫之前,先說一下需求文檔的展現形式,我以前分享WORD形式的PRD文檔寫法,很多人會說我分享的內容過時了,現在都是用AXURE來寫文檔,當我分享AXURE形式的PRD文檔寫法的時候,很多人又說,你這AXURE寫的不專業。其實表現形式啥的,真心不重要,重要的是要達到目的,PRD的目標是啥?目標就是讓團隊知道需求實現的具體細節,讓團隊達成統一意見,做到開發有據可依,而不是爭論表現形式,只要能夠幫助團隊成員達成共識,幫助團隊成員建立認知的一致性就夠了,具體怎么表現形式不重要,選一個團隊都能接受的形式,提高溝通和開發效率就行了。如果團隊之前習慣了word形式的PRD,那你就用word寫;如果團隊成員習慣了axure形式的PRD,那你就用axure寫,一切以提高工作效率,達成一致意見為目標。好,接下來開始分享關于B端產品的WORD形式的PRD該如何寫,希望對大家有所幫助和啟發。PRD的組成部分1、文檔產品名稱寫個需求文檔,你得告訴人家是什么吧,尤其在公司有很多文檔的情況下,做好文檔管理更是必不可少的一個環節。一般來說文檔產品命名(這個文檔命名是指文件的名稱,不是文檔里面的頂部名稱,文檔里面內容的頂部名稱可以參考下圖)可以這樣寫【XXXX需求文檔V1.X】,或者【XX需求文檔V20201202】。一個可以直觀的看到需求文檔的修改次數,一個可以直觀的看到文檔的修改日期,很多人可能說如果后面加日期的話,同一天修改多次咋辦?這也好辦,可以在名稱后面加上序號,比如【XX需求文檔V20201202_01】,這樣就知道修改多少次了,當然文檔修改的次數還是越少越好,太多了,產品經理的公信力就會下降了。
圖片

2、文件狀態文檔的狀態是草稿?正式發布?正在修改?

當前版本是多少,尤其是你版本修改很多的情況下。文檔密級分為普通、機密、絕密,比如你寫的使用手冊就是普通,你的產品沒有上線前寫的文檔屬于機密,絕密一般情況下遇不到,比如銀行項目,國家級項目,就是絕密。
圖片

3、版本歷史產品經理也不是神,難免會犯錯,所以寫的文檔難免會更改,這個時候文檔修訂記錄就起作用了。首先是變更的版本,然后是修訂日期、原因與修改情況描述、修訂人。這里的3.2.5是大綱欄目,這樣的好處是你修改那一條,人家直接去根據欄目定位到你修改的那一條,作為產品經理,也要注重一下用戶體驗,同時修改的部分需要高亮顯示,用不同顏色字體標出來,這樣別人找的時候容易找。
圖片

4、目錄目錄就不用說了,寫文章有文章目錄,寫文檔有文檔目錄,一般word【引用-插入目錄】都有。
圖片

5、文檔介紹
主要介紹文檔的目的、文檔面向的主要用戶,讀者對象、參考文獻、術語與縮寫解釋等。

圖片

圖片

6、項目綜述6.1 項目背景從大的方向,講講項目的相關背景,有什么目標、有沒有競品對象?階段性計劃是什么,傳遞做這個需求的目的是什么?要達到什么樣的目標?讓項目開發人員對你的項目背景有了解,程序員知道的越多,做起項目來越有方向性。如果業務比較復雜,最好用業務流程圖來解釋一下,比如XX業務流程圖,名字可以命名為業務流程。

圖片

6.2 項目目標最好是一些具體的可量化的項目目標,而且最好符合SMART原則。任何項目都是有預期收益和期待的業務價值的,對于B端產品,有時候業務價值收益不好直接衡量,可以考量功能的使用情況,滿意度,等等。
圖片

6.3 平臺架構主要把系統的整體架構表現出來,讓閱讀對象對系統的骨架有個整體性的認知。
圖片

6.4 功能架構上面是從整體的系統架構的角度出發,而功能架構更多是從功能的角度出發,列舉一下需要開發的功能。
圖片

7、業務需求陳述7.1 公共需求這一模塊主要把一些公共的需求說明放在這,免得每次都得說一遍,總之將大部分頁面公共的功能說明放在此。比如每個報表頁面提供導出EXCEL功能、點擊刪除按鈕需要二次彈框確認等。

圖片

7.2 功能模塊需求說明某一個功能模塊頁面具體的需求闡述,下面以某列表頁舉例。

  • 查詢條件
圖片
  • 列表字段
圖片
  • 排序

數據排序方式說明。例如:根據時間的倒序排列,最新數據在最上面。這些要規范清楚,不然技術就會按照自己的理解來寫;

  • 異常情況處理

這里列舉一下異常情況:突然沒有網絡的情況、接口調用超時的情況、收不到回調之后的情況、是否有逆向流程情況、誤操作的情況、數據丟失情況等。包含此項內容是否為了促使產品經理對產品方案思考周全,包括所有的異常情況。8、數據埋點按照公司的統一的埋點要求描述需要埋點監控的按鈕、頁面、事件等。可以將數據埋點文檔直接插入需求文檔內。 9、角色和權限角色權限表,可通過EXCEL的方式插入進來,也可以直接編寫。例如下圖:

圖片

10、運營計劃項目配套的運營推廣計劃,產品是1,運營是0,好的產品更需要好的運營計劃來加持,產品在設計時就應該確認運營計劃。11、待決事項所有待定事項上面我列的點可能比較多,實際工作中除了從0-1的產品設計,其他的產品迭代設計可能并不需要這么多,具體需要哪些,大家可以根據自己的需要酌情刪減,還是那句話,沒有最好的文檔,只有溝通效率最高的文檔。

文章來源于產品劉 ,作者劉大大a

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容