在說B端產(chǎn)品需求文檔如何寫之前，先說一下需求文檔的展現(xiàn)形式，我以前分享WORD形式的PRD文檔寫法，很多人會說我分享的內(nèi)容過時了，現(xiàn)在都是用AXURE來寫文檔，當我分享AXURE形式的PRD文檔寫法的時候，很多人又說，你這AXURE寫的不專業(yè)。其實表現(xiàn)形式啥的，真心不重要，重要的是要達到目的，PRD的目標是啥？目標就是讓團隊知道需求實現(xiàn)的具體細節(jié)，讓團隊達成統(tǒng)一意見，做到開發(fā)有據(jù)可依，而不是爭論表現(xiàn)形式，只要能夠幫助團隊成員達成共識，幫助團隊成員建立認知的一致性就夠了，具體怎么表現(xiàn)形式不重要，選一個團隊都能接受的形式，提高溝通和開發(fā)效率就行了。如果團隊之前習慣了word形式的PRD，那你就用word寫；如果團隊成員習慣了axure形式的PRD，那你就用axure寫，一切以提高工作效率，達成一致意見為目標。好，接下來開始分享關(guān)于B端產(chǎn)品的WORD形式的PRD該如何寫，希望對大家有所幫助和啟發(fā)。PRD的組成部分1、文檔產(chǎn)品名稱寫個需求文檔，你得告訴人家是什么吧，尤其在公司有很多文檔的情況下，做好文檔管理更是必不可少的一個環(huán)節(jié)。一般來說文檔產(chǎn)品命名（這個文檔命名是指文件的名稱，不是文檔里面的頂部名稱，文檔里面內(nèi)容的頂部名稱可以參考下圖）可以這樣寫【XXXX需求文檔V1.X】，或者【XX需求文檔V20201202】。一個可以直觀的看到需求文檔的修改次數(shù)，一個可以直觀的看到文檔的修改日期，很多人可能說如果后面加日期的話，同一天修改多次咋辦？這也好辦，可以在名稱后面加上序號，比如【XX需求文檔V20201202_01】，這樣就知道修改多少次了，當然文檔修改的次數(shù)還是越少越好，太多了，產(chǎn)品經(jīng)理的公信力就會下降了。
2、文件狀態(tài)文檔的狀態(tài)是草稿？正式發(fā)布？正在修改？
當前版本是多少，尤其是你版本修改很多的情況下。文檔密級分為普通、機密、絕密，比如你寫的使用手冊就是普通，你的產(chǎn)品沒有上線前寫的文檔屬于機密，絕密一般情況下遇不到，比如銀行項目，國家級項目，就是絕密。
3、版本歷史產(chǎn)品經(jīng)理也不是神，難免會犯錯，所以寫的文檔難免會更改，這個時候文檔修訂記錄就起作用了。首先是變更的版本，然后是修訂日期、原因與修改情況描述、修訂人。這里的3.2.5是大綱欄目，這樣的好處是你修改那一條，人家直接去根據(jù)欄目定位到你修改的那一條，作為產(chǎn)品經(jīng)理，也要注重一下用戶體驗，同時修改的部分需要高亮顯示，用不同顏色字體標出來，這樣別人找的時候容易找。
4、目錄目錄就不用說了，寫文章有文章目錄，寫文檔有文檔目錄，一般word【引用-插入目錄】都有。
5、文檔介紹
主要介紹文檔的目的、文檔面向的主要用戶，讀者對象、參考文獻、術(shù)語與縮寫解釋等。
6、項目綜述6.1 項目背景從大的方向，講講項目的相關(guān)背景，有什么目標、有沒有競品對象？階段性計劃是什么，傳遞做這個需求的目的是什么？要達到什么樣的目標？讓項目開發(fā)人員對你的項目背景有了解，程序員知道的越多，做起項目來越有方向性。如果業(yè)務(wù)比較復雜，最好用業(yè)務(wù)流程圖來解釋一下，比如XX業(yè)務(wù)流程圖，名字可以命名為業(yè)務(wù)流程。
6.2 項目目標最好是一些具體的可量化的項目目標，而且最好符合SMART原則。任何項目都是有預期收益和期待的業(yè)務(wù)價值的，對于B端產(chǎn)品，有時候業(yè)務(wù)價值收益不好直接衡量，可以考量功能的使用情況，滿意度，等等。
6.3 平臺架構(gòu)主要把系統(tǒng)的整體架構(gòu)表現(xiàn)出來，讓閱讀對象對系統(tǒng)的骨架有個整體性的認知。
6.4 功能架構(gòu)上面是從整體的系統(tǒng)架構(gòu)的角度出發(fā)，而功能架構(gòu)更多是從功能的角度出發(fā)，列舉一下需要開發(fā)的功能。
7、業(yè)務(wù)需求陳述7.1 公共需求這一模塊主要把一些公共的需求說明放在這，免得每次都得說一遍，總之將大部分頁面公共的功能說明放在此。比如每個報表頁面提供導出EXCEL功能、點擊刪除按鈕需要二次彈框確認等。
7.2 功能模塊需求說明某一個功能模塊頁面具體的需求闡述，下面以某列表頁舉例。
數(shù)據(jù)排序方式說明。例如：根據(jù)時間的倒序排列，最新數(shù)據(jù)在最上面。這些要規(guī)范清楚，不然技術(shù)就會按照自己的理解來寫；
這里列舉一下異常情況：突然沒有網(wǎng)絡(luò)的情況、接口調(diào)用超時的情況、收不到回調(diào)之后的情況、是否有逆向流程情況、誤操作的情況、數(shù)據(jù)丟失情況等。包含此項內(nèi)容是否為了促使產(chǎn)品經(jīng)理對產(chǎn)品方案思考周全，包括所有的異常情況。8、數(shù)據(jù)埋點按照公司的統(tǒng)一的埋點要求描述需要埋點監(jiān)控的按鈕、頁面、事件等?？梢詫?shù)據(jù)埋點文檔直接插入需求文檔內(nèi)。 9、角色和權(quán)限角色權(quán)限表，可通過EXCEL的方式插入進來，也可以直接編寫。例如下圖：
10、運營計劃項目配套的運營推廣計劃，產(chǎn)品是1，運營是0，好的產(chǎn)品更需要好的運營計劃來加持，產(chǎn)品在設(shè)計時就應該確認運營計劃。11、待決事項所有待定事項上面我列的點可能比較多，實際工作中除了從0-1的產(chǎn)品設(shè)計，其他的產(chǎn)品迭代設(shè)計可能并不需要這么多，具體需要哪些，大家可以根據(jù)自己的需要酌情刪減，還是那句話，沒有最好的文檔，只有溝通效率最高的文檔。
文章來源于產(chǎn)品劉 ，作者劉大大a
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。
