初學的產品小白，你是否對產品經理的相關工作毫無概念，不知道別人常說的 PRD、需求文檔是什么而苦惱？
還想要一個模版，學習和動手模仿一份，期待面試加分？
又或者你是一名已入職的初級產品經理，由于自學或培訓入行，沒有系統的產品知識，撰寫的需求文檔邏輯混亂、毫無頭緒，還常常給領導各種挑剔、開發各種怒懟呢？
到底什么是產品口中的需求文檔？什么樣的文檔才算是優秀的 PRD，構思時需要抓住哪些重點進行撰寫？
作為資深的產品老油條，文檔撰寫 300+ 起，版本迭代更是數不勝數。寫個 PRD 就和喝水那么簡單，我想我可以分享一些經驗給你~
更多文檔撰寫指南：
什么是需求文檔
需求文檔（Product Requirement Document）作為產品經理的必學基礎技能，主要是用來承載當前版本的需求背景、產品方案、原型界面等內容的產品說明文檔。
我常用的需求文檔模版，一般由產品概覽、產品結構、UML 相關、流程梳理、文檔相關、消息推送、原型界面、功能交互、廢紙簍等 9 個部分組成。
接下來，我們就對這些內容展開聊聊。
產品概覽，主要包含了版本封面、版本日志、版本背景、更新內容等 4 個模塊。
1. 版本封面
版本封面在需求文檔的第一頁，用于展示“項目名稱、版本編號、版本開發時間、版本發布時間、版本相關負責人”等相關內容。
你說這封面有什么用？一般是用來裝 B 的，顯得文檔規范高大上，提升團隊成員參與感~
2. 版本日志
撰寫版本日志，主要是為了讓相關需求方了解版本的迭代過程，以及幫助其了解版本的更新內容。
所以版本日志的撰寫需要通俗易懂，避免通過系統視角，對更新內容進行生硬的描述。
（悄悄告訴你~現在為了偷懶，都用 ChatGPT 自動生成版本日志了，還別說效果真的頂！）
版本日志還有一個作用是，你可以翻看之前的迭代內容，為數據分析提供依據。
3. 版本背景
版本背景可以說是文檔的說明書，它明確告知了讀者當前版本的開發目的和必要性。
版本背景的內容，一般包含“版本背景、版本目標、需求說明、相關功能”等幾個部分。
什么情況可以不寫？
- 你領導；
- 懶得寫。
4. 更新內容
更新內容一般是給相關開發人員看的。主要指出當前版本的關聯需求有哪些，讓前后端知道開發范圍。
你說版本迭代那么快，每次都要寫更新內容，太麻煩了不寫行不行？
當然可以，只要你能忍受這些：
- 開發階段前后端同事輪番轟炸你微信，問你這次開發內容是啥；
- 當你打開塵封已久的文檔，由于不清楚當時迭代了什么，又因為涉及內容太多，而要梳理相關規則時，一臉懵逼生無可戀，簡直無從下手。
產品架構分為了產品結構、功能結構、頁面結構等三個部分。
- 產品結構：主要呈現一個產品或系統的模塊分布；
- 功能結構：以一個功能或模塊為主題，展示該功能的組成；
- 頁面結構：描述一個版本的相關頁面及頁面之間的從屬關系。
說實話，由于團隊版本迭代的節奏較快，我基本上文檔內已經很少附上這些內容了。
除非是在進行新系統設計、年度規劃、系統重構等情況時，我才會花點時間構思產品結構。
所以，你可以視實際情況，考慮刪減部分。
UML 的模塊包含了類圖、用例、狀態圖、活動圖、時序圖，我一般用的比較多的是類圖和狀態圖。
- 類圖：主要用來呈現不同對象、對象之間關系的一種模型；
- 狀態圖：描述一個對象在周期內，相關狀態及其變更條件的過程。例如一個電商訂單從待付款到已付款的變化。
有童鞋就問了，UML 是啥東西聽都沒聽過，是不是和技術相關阿？那技術的東西我又不是開發，學來干啥？
UML 是一門圖形語言，它代表了面向對象的思想，我曾經就踩過不懂 UML 的坑，說多了那都是淚。
感興趣可以看：《3 本進階產品必備書籍，帶你快速入門 UML 建?！?。
該模塊主要針對于“業務、功能、頁面”等相關流程進行系統梳理。
- 業務流程：一般描述某業務涉及的各個角色、規則和環節等關系，幫助產品深入思考業務場景；
- 功能流程：研究主體為一般為某個功能，并梳理出該功能涉及的相關系統條件和流程變化等；
- 頁面流程：指的是作為用戶進行某些操作時，相關的頁面跳轉過程。
作為初級產品，入門時一般會進行功能級的設計（例如一個動態發布功能），這時候需要你掌握“功能流程圖、頁面流程圖”的基礎繪制，輔助理清設計過程中將遇到的各類問題。
當積累了不少功能設計經驗后，你可能會接到一些業務優化的需求，而業務優化的前提是完全理解業務場景。
通過針對某個具體業務，繪制相關的業務流程圖，便能幫你搞清楚業務難題和優化方向，從而輔助相關功能設計落地。
文檔相關模塊，用來存放一些概念說明、數據相關等內容。
具體有“版本排期、名詞解釋、角色權限、全局說明、數據實例、數據埋點”等。
- 版本排期：當一個業務需求較復雜時，我們會將功能模塊拆分為多個版本，此時就要進行多版本排期，以供需求方參考；
- 名詞解釋：對系統、業務名詞進行解釋，幫助讀者快速了解、掌握相關概念知識；
- 角色權限：定義不同角色在系統中的操作權限；
- 全局說明：對系統的設計規范、規則要求進行統一說明，確保相關人員理解；
- 數據實例：針對某些數據表，進行數據模擬，提升讀者對相關功能的進一步理解；一般涉及數據創建的需求，也可以在該模塊說明，用作部分功能的自定義配置；
- 數據埋點：如版本涉及數據跟蹤和數據埋點要求，可在此進行補充。
這個模塊的內容，可視具體情況酌情刪減。
并非每個版本文檔都需要這么細的規則說明，有些小版本僅需“全局說明”就夠了。
消息推送的類型主要有：短信、郵件、APP 推送、訂閱消息、模板消息等。
消息推送主要告知開發，當前版本涉及的消息內容、消息規則，及其他推送的注意事項。
有些時候對舊推送改版的時候，作為產品文檔的撰寫人也會回顧，以便于進行規則迭代。
試想下，如果你手上負責的系統，當前的推送規則包含了好幾百條，而又沒有相應的文檔留存寫明推送規則，這時你該提桶跑路呢還是提桶跑路呢？
所以，建議你有精力的話可以做個消息推送的總文檔，以便應對上述場景發生。
原型分為高保真原型和低保真原型，如果不需要演示給客戶看，我建議你為了工作效率（偷個懶不過分吧~），繪制低保真原型就可以了。
一些常用的原型界面有：異常頁、結果頁、對話框、原型頁。
- 異常頁：用于存放部分頁面的異常狀態，例如“搜索商品為空、訂單列表為空”等；
- 結果頁：當用戶完成某項操作后，展示的操作結果頁面，例如“訂單交易完成”；
- 對話框：將當前版本的所有對話框提示，單獨存放在一個“對話框”頁，以便開發便捷查詢；
- 原型頁：指具體的版本功能涉及頁面。
功能交互模塊，一般撰寫版本迭代中，涉及相關功能的交互規則。
例如”用戶注冊“的功能流程，就可以用”用戶注冊交互“的單獨頁面進行撰寫。
交互一般可分為動態交互和靜態交互。
動態交互，顧名思義即包含了自動化或觸發式的一系列變化的交互效果。
而靜態交互，是指將這種動態交互效果，通過一張張頁面、組件鋪開組成的交互流程圖。
有些人就要問了，為什么要用靜態交互呢，使用動態交互不是更酷炫嗎？
溝通的本質，是減少信息差?！孟?/p>
文檔本質是一種溝通方式，需要方便開發查閱和理解。
如果使用動態交互，一個稍微復雜的交互效果，做的人效率低不說，查閱的開發同事，要重復點擊多少次，才能完全理解其中的邏輯，換我也崩潰~
所以，使開發一目了然、快速抓住交互重點才是文檔的核心，那么靜態交互在這種情況，就成了最優解。
廢紙簍，顧名思義就是放一些已廢棄、暫時不用的文檔內容。
一個版本文檔內，一般涉及到新邏輯變更，我的習慣是順手復制一份放入廢紙簍，興許變更內容不理想，還可以從廢紙簍中恢復當前文檔內容。
需求文檔作為產品的基礎能力，本質是一種溝通工具。
它主要用來承載產品方案、原型界面等內容，一般有 9 個部分：產品概覽、產品架構、UML 相關、流程梳理、文檔相關、消息推送、原型界面、功能交互、廢紙簍等。
每個模塊都有特定的作用，撰寫時要注意規范性、易讀性，前后端查閱時，才不至于懟你太狠~
隨手點個贊，謝謝你喜歡~
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
熱評 bling～