超詳細(xì)！一份漲薪 3 倍的需求文檔撰寫指南

初學(xué)的產(chǎn)品小白，你是否對(duì)產(chǎn)品經(jīng)理的相關(guān)工作毫無概念，不知道別人常說的 PRD、需求文檔是什么而苦惱？

還想要一個(gè)模版，學(xué)習(xí)和動(dòng)手模仿一份，期待面試加分？

又或者你是一名已入職的初級(jí)產(chǎn)品經(jīng)理，由于自學(xué)或培訓(xùn)入行，沒有系統(tǒng)的產(chǎn)品知識(shí)，撰寫的需求文檔邏輯混亂、毫無頭緒，還常常給領(lǐng)導(dǎo)各種挑剔、開發(fā)各種怒懟呢？

到底什么是產(chǎn)品口中的需求文檔？什么樣的文檔才算是優(yōu)秀的 PRD，構(gòu)思時(shí)需要抓住哪些重點(diǎn)進(jìn)行撰寫？

作為資深的產(chǎn)品老油條，文檔撰寫 300+ 起，版本迭代更是數(shù)不勝數(shù)。寫個(gè) PRD 就和喝水那么簡單，我想我可以分享一些經(jīng)驗(yàn)給你~

更多文檔撰寫指南：

什么是需求文檔

需求文檔（Product Requirement Document）作為產(chǎn)品經(jīng)理的必學(xué)基礎(chǔ)技能，主要是用來承載當(dāng)前版本的需求背景、產(chǎn)品方案、原型界面等內(nèi)容的產(chǎn)品說明文檔。

我常用的需求文檔模版，一般由產(chǎn)品概覽、產(chǎn)品結(jié)構(gòu)、UML 相關(guān)、流程梳理、文檔相關(guān)、消息推送、原型界面、功能交互、廢紙簍等 9 個(gè)部分組成。

接下來，我們就對(duì)這些內(nèi)容展開聊聊。

一、產(chǎn)品概覽

產(chǎn)品概覽，主要包含了版本封面、版本日志、版本背景、更新內(nèi)容等 4 個(gè)模塊。

1. 版本封面

版本封面在需求文檔的第一頁，用于展示“項(xiàng)目名稱、版本編號(hào)、版本開發(fā)時(shí)間、版本發(fā)布時(shí)間、版本相關(guān)負(fù)責(zé)人”等相關(guān)內(nèi)容。

你說這封面有什么用？一般是用來裝 B 的，顯得文檔規(guī)范高大上，提升團(tuán)隊(duì)成員參與感~

2. 版本日志

撰寫版本日志，主要是為了讓相關(guān)需求方了解版本的迭代過程，以及幫助其了解版本的更新內(nèi)容。

所以版本日志的撰寫需要通俗易懂，避免通過系統(tǒng)視角，對(duì)更新內(nèi)容進(jìn)行生硬的描述。

（悄悄告訴你~現(xiàn)在為了偷懶，都用 ChatGPT 自動(dòng)生成版本日志了，還別說效果真的頂！）

版本日志還有一個(gè)作用是，你可以翻看之前的迭代內(nèi)容，為數(shù)據(jù)分析提供依據(jù)。

3. 版本背景

版本背景可以說是文檔的說明書，它明確告知了讀者當(dāng)前版本的開發(fā)目的和必要性。

版本背景的內(nèi)容，一般包含“版本背景、版本目標(biāo)、需求說明、相關(guān)功能”等幾個(gè)部分。

什么情況可以不寫？

1. 你領(lǐng)導(dǎo)；
2. 懶得寫。

4. 更新內(nèi)容

更新內(nèi)容一般是給相關(guān)開發(fā)人員看的。主要指出當(dāng)前版本的關(guān)聯(lián)需求有哪些，讓前后端知道開發(fā)范圍。

你說版本迭代那么快，每次都要寫更新內(nèi)容，太麻煩了不寫行不行？

當(dāng)然可以，只要你能忍受這些：

1. 開發(fā)階段前后端同事輪番轟炸你微信，問你這次開發(fā)內(nèi)容是啥；
2. 當(dāng)你打開塵封已久的文檔，由于不清楚當(dāng)時(shí)迭代了什么，又因?yàn)樯婕皟?nèi)容太多，而要梳理相關(guān)規(guī)則時(shí)，一臉懵逼生無可戀，簡直無從下手。

二、產(chǎn)品架構(gòu)

產(chǎn)品架構(gòu)分為了產(chǎn)品結(jié)構(gòu)、功能結(jié)構(gòu)、頁面結(jié)構(gòu)等三個(gè)部分。

1. 產(chǎn)品結(jié)構(gòu)：主要呈現(xiàn)一個(gè)產(chǎn)品或系統(tǒng)的模塊分布；
2. 功能結(jié)構(gòu)：以一個(gè)功能或模塊為主題，展示該功能的組成；
3. 頁面結(jié)構(gòu)：描述一個(gè)版本的相關(guān)頁面及頁面之間的從屬關(guān)系。

說實(shí)話，由于團(tuán)隊(duì)版本迭代的節(jié)奏較快，我基本上文檔內(nèi)已經(jīng)很少附上這些內(nèi)容了。

除非是在進(jìn)行新系統(tǒng)設(shè)計(jì)、年度規(guī)劃、系統(tǒng)重構(gòu)等情況時(shí)，我才會(huì)花點(diǎn)時(shí)間構(gòu)思產(chǎn)品結(jié)構(gòu)。

所以，你可以視實(shí)際情況，考慮刪減部分。

三、UML 相關(guān)

UML 的模塊包含了類圖、用例、狀態(tài)圖、活動(dòng)圖、時(shí)序圖，我一般用的比較多的是類圖和狀態(tài)圖。

1. 類圖：主要用來呈現(xiàn)不同對(duì)象、對(duì)象之間關(guān)系的一種模型；
2. 狀態(tài)圖：描述一個(gè)對(duì)象在周期內(nèi)，相關(guān)狀態(tài)及其變更條件的過程。例如一個(gè)電商訂單從待付款到已付款的變化。

有童鞋就問了，UML 是啥東西聽都沒聽過，是不是和技術(shù)相關(guān)阿？那技術(shù)的東西我又不是開發(fā)，學(xué)來干啥？

UML 是一門圖形語言，它代表了面向?qū)ο蟮乃枷耄以?jīng)就踩過不懂 UML 的坑，說多了那都是淚。

感興趣可以看：《3 本進(jìn)階產(chǎn)品必備書籍，帶你快速入門 UML 建模》。

四、流程梳理

該模塊主要針對(duì)于“業(yè)務(wù)、功能、頁面”等相關(guān)流程進(jìn)行系統(tǒng)梳理。

1. 業(yè)務(wù)流程：一般描述某業(yè)務(wù)涉及的各個(gè)角色、規(guī)則和環(huán)節(jié)等關(guān)系，幫助產(chǎn)品深入思考業(yè)務(wù)場景；
2. 功能流程：研究主體為一般為某個(gè)功能，并梳理出該功能涉及的相關(guān)系統(tǒng)條件和流程變化等；
3. 頁面流程：指的是作為用戶進(jìn)行某些操作時(shí)，相關(guān)的頁面跳轉(zhuǎn)過程。

作為初級(jí)產(chǎn)品，入門時(shí)一般會(huì)進(jìn)行功能級(jí)的設(shè)計(jì)（例如一個(gè)動(dòng)態(tài)發(fā)布功能），這時(shí)候需要你掌握“功能流程圖、頁面流程圖”的基礎(chǔ)繪制，輔助理清設(shè)計(jì)過程中將遇到的各類問題。

當(dāng)積累了不少功能設(shè)計(jì)經(jīng)驗(yàn)后，你可能會(huì)接到一些業(yè)務(wù)優(yōu)化的需求，而業(yè)務(wù)優(yōu)化的前提是完全理解業(yè)務(wù)場景。

通過針對(duì)某個(gè)具體業(yè)務(wù)，繪制相關(guān)的業(yè)務(wù)流程圖，便能幫你搞清楚業(yè)務(wù)難題和優(yōu)化方向，從而輔助相關(guān)功能設(shè)計(jì)落地。

五、文檔相關(guān)

文檔相關(guān)模塊，用來存放一些概念說明、數(shù)據(jù)相關(guān)等內(nèi)容。

具體有“版本排期、名詞解釋、角色權(quán)限、全局說明、數(shù)據(jù)實(shí)例、數(shù)據(jù)埋點(diǎn)”等。

1. 版本排期：當(dāng)一個(gè)業(yè)務(wù)需求較復(fù)雜時(shí)，我們會(huì)將功能模塊拆分為多個(gè)版本，此時(shí)就要進(jìn)行多版本排期，以供需求方參考；
2. 名詞解釋：對(duì)系統(tǒng)、業(yè)務(wù)名詞進(jìn)行解釋，幫助讀者快速了解、掌握相關(guān)概念知識(shí)；
3. 角色權(quán)限：定義不同角色在系統(tǒng)中的操作權(quán)限；
4. 全局說明：對(duì)系統(tǒng)的設(shè)計(jì)規(guī)范、規(guī)則要求進(jìn)行統(tǒng)一說明，確保相關(guān)人員理解；
5. 數(shù)據(jù)實(shí)例：針對(duì)某些數(shù)據(jù)表，進(jìn)行數(shù)據(jù)模擬，提升讀者對(duì)相關(guān)功能的進(jìn)一步理解；一般涉及數(shù)據(jù)創(chuàng)建的需求，也可以在該模塊說明，用作部分功能的自定義配置；
6. 數(shù)據(jù)埋點(diǎn)：如版本涉及數(shù)據(jù)跟蹤和數(shù)據(jù)埋點(diǎn)要求，可在此進(jìn)行補(bǔ)充。

這個(gè)模塊的內(nèi)容，可視具體情況酌情刪減。

并非每個(gè)版本文檔都需要這么細(xì)的規(guī)則說明，有些小版本僅需“全局說明”就夠了。

六、消息推送

消息推送的類型主要有：短信、郵件、APP 推送、訂閱消息、模板消息等。

消息推送主要告知開發(fā)，當(dāng)前版本涉及的消息內(nèi)容、消息規(guī)則，及其他推送的注意事項(xiàng)。

有些時(shí)候?qū)εf推送改版的時(shí)候，作為產(chǎn)品文檔的撰寫人也會(huì)回顧，以便于進(jìn)行規(guī)則迭代。

試想下，如果你手上負(fù)責(zé)的系統(tǒng)，當(dāng)前的推送規(guī)則包含了好幾百條，而又沒有相應(yīng)的文檔留存寫明推送規(guī)則，這時(shí)你該提桶跑路呢還是提桶跑路呢？

所以，建議你有精力的話可以做個(gè)消息推送的總文檔，以便應(yīng)對(duì)上述場景發(fā)生。

七、原型界面

原型分為高保真原型和低保真原型，如果不需要演示給客戶看，我建議你為了工作效率（偷個(gè)懶不過分吧~），繪制低保真原型就可以了。

一些常用的原型界面有：異常頁、結(jié)果頁、對(duì)話框、原型頁。

1. 異常頁：用于存放部分頁面的異常狀態(tài)，例如“搜索商品為空、訂單列表為空”等；
2. 結(jié)果頁：當(dāng)用戶完成某項(xiàng)操作后，展示的操作結(jié)果頁面，例如“訂單交易完成”；
3. 對(duì)話框：將當(dāng)前版本的所有對(duì)話框提示，單獨(dú)存放在一個(gè)“對(duì)話框”頁，以便開發(fā)便捷查詢；
4. 原型頁：指具體的版本功能涉及頁面。

八、功能交互

功能交互模塊，一般撰寫版本迭代中，涉及相關(guān)功能的交互規(guī)則。

例如”用戶注冊“的功能流程，就可以用”用戶注冊交互“的單獨(dú)頁面進(jìn)行撰寫。

交互一般可分為動(dòng)態(tài)交互和靜態(tài)交互。

動(dòng)態(tài)交互，顧名思義即包含了自動(dòng)化或觸發(fā)式的一系列變化的交互效果。

而靜態(tài)交互，是指將這種動(dòng)態(tài)交互效果，通過一張張頁面、組件鋪開組成的交互流程圖。

有些人就要問了，為什么要用靜態(tài)交互呢，使用動(dòng)態(tài)交互不是更酷炫嗎？

溝通的本質(zhì)，是減少信息差。——好夕雷

文檔本質(zhì)是一種溝通方式，需要方便開發(fā)查閱和理解。

如果使用動(dòng)態(tài)交互，一個(gè)稍微復(fù)雜的交互效果，做的人效率低不說，查閱的開發(fā)同事，要重復(fù)點(diǎn)擊多少次，才能完全理解其中的邏輯，換我也崩潰~

所以，使開發(fā)一目了然、快速抓住交互重點(diǎn)才是文檔的核心，那么靜態(tài)交互在這種情況，就成了最優(yōu)解。

九、廢紙簍

廢紙簍，顧名思義就是放一些已廢棄、暫時(shí)不用的文檔內(nèi)容。

一個(gè)版本文檔內(nèi)，一般涉及到新邏輯變更，我的習(xí)慣是順手復(fù)制一份放入廢紙簍，興許變更內(nèi)容不理想，還可以從廢紙簍中恢復(fù)當(dāng)前文檔內(nèi)容。

總結(jié)

需求文檔作為產(chǎn)品的基礎(chǔ)能力，本質(zhì)是一種溝通工具。

它主要用來承載產(chǎn)品方案、原型界面等內(nèi)容，一般有 9 個(gè)部分：產(chǎn)品概覽、產(chǎn)品架構(gòu)、UML 相關(guān)、流程梳理、文檔相關(guān)、消息推送、原型界面、功能交互、廢紙簍等。

每個(gè)模塊都有特定的作用，撰寫時(shí)要注意規(guī)范性、易讀性，前后端查閱時(shí)，才不至于懟你太狠~

隨手點(diǎn)個(gè)贊，謝謝你喜歡~