prd是什么意思

據說產品經理有三個證件：brd，mrd，珠三角。在日常工作中，很多產品的方向已經被領導定了，所以編制brd和mrd的機會比較少，產品細化中使用的prd更常用。

珠三角在項目中扮演什么角色？什么是好的珠三角？怎么寫prd？本文將依次回答相應的問題，如有錯誤或遺漏，請給出建議。

01

prd作用：要你有什么用？

prd是一個將產品需求和相應的需求解決方案放在一起的文檔。文檔面對與項目相關的各種角色，并在項目推廣中發揮重要作用，例如：

1)產品：根據prd公布方案，作為比較終檢驗產品實現程度的依據；

2)設計：根據prd的原型作為ui設計的參考；

3)發展：按照珠三角的制度規則等。作為研發的基礎；

4)測試：按照prd規則編寫用例和測試；

根據需求的覆蓋面，還會涉及到其他角色，比如運營、商務、金融等。無論面對誰，比較終目標都是為了讓團隊成員能夠理解業務，在產品研發過程中得到更好地執行。

02

prd要求：想要我怎樣？

為了讓珠三角更好地運作，編寫文檔時需要清晰、完整且容易閱讀的方式將復雜抽象的解決方案呈現出來.我們如何才能達到這個效果？文件至少必須滿足以下要求：

1)場景完整:需要考慮與需求相關的各種業務場景，尤其是特殊場景的響應機制。避免場景缺失造成的方案漏洞。

2)框架清晰:提供系統架構、業務模式、功能結構、系統流程等一系列框架，幫助會員從視角了解系統概況。

3)邏輯自洽:系統運營涵蓋正向和反向業務流程、主流程和分支流程，形成系統運營無沖突的閉環。

4)規則簡明:描述系統全局描述、功能模塊、非功能需求等規則。并使它們變得流行和完整。

5)設計友好:系統頁面的布局、導航、交互、文案等交互動作都要按照尼爾森的可用性原則進行設計。

根據具體情況，編制珠三角時會有其他要求。比如非功能性需求(數據索引需求、運營需求等)。)應明確定義無異議。

03

prd編寫：注意你的尺度！

知道了珠三角的需求，在編制的時候就可以貼近需求了。但是要求只能作為指導思想，并沒有告訴我們具體怎么寫。你可能還有這些疑問。

01

prd要用什么形式呈現？

prd有兩種常見形式：——word和原型。兩種形式各有利弊。比如目錄的word版本，更容易概覽全局；原型在描述功能需求時更加靈活。

那樣的話，首先要看公司制度。如果有相應的規范，我們可以直接實現(規范也可以調整)。如果公司不要求，產品經理將與團隊和采用大家認可的、更方便表達和閱讀的方式即可。溝通

02

prd要寫到什么顆粒度？

寫過珠三角的同學應該都有過這個問題。尤其是對于規則的描述，寫厚了怕遺漏，寫薄了怕沒人看。除了描述上精簡用詞，還能從規則提煉和原型設計上進行把控。

1)規則細化：常規規則和可重用規則用“全局描述”來描述。比如手勢操作，輸入框的定義和限制等。

2)原型設計：輸出原型不要有高保真原型，耗時，影響ui播放；不具備復雜的交互，不利于快速識別，但可以在備注中說明；不要過度設計.

03

prd由哪些部分組成？

總結以往項目的prd的常用部件，從一般、一般、細節部分拆解，僅供參考。每份prd的具體組成需要項目結合實際情況進行增刪。

1)通用部分：名稱、目錄、更新記錄；

2)總結部分：項目背景、預期收益、方案概述、項目范圍、項目風險；

3)詳細部分：產品框架、全局描述、原型頁面、功能需求、非功能需求；

04

prd組成：請問你完整嗎？

終于，該寫了！珠三角生產是產品經理的基礎工作之一，可以直接反映產品經理的底層職業能力是否扎實?，F在我們知道了

通用部分

文檔名稱用于區分不同的產品和版本。一般的命名方法是產品名稱版本號。這里的“版本號”名稱每個公司都不一樣，版本號可以用v1.0或者日期。可以識別并快速區分。

如：xx車輛租賃管理系統v1.0；xx車輛租賃管理系統-210504。

1）文檔名稱

一般word形式的prd都會配備文檔目錄，讓讀者更直觀的了解整個情況。

使用原型版本可以達到類似的效果。你可以把頁面定義為一個“目錄”，把word版本的內容放在里面，也可以通過定期給原型頁面命名來達到這個效果。下圖(部分頁面隱藏)。

2）文檔目錄

prd的每一次更新都要有記錄，幫助讀者了解每一次更新的內容。

更新記錄一般以表格的形式呈現，主要字段包括：更新時間、變更屬性(添加、刪除、修改)、更新內容、更新人員。

02

3）更新記錄

概要部分

背景描述是讓讀者了解項目或需求的來源和具體情況。背景包括業務概述、業務流程、當前問題、整體解決方案等相關內容。

相應的內容會涉及到用戶調研和整體方案撰寫，可以直接使用。編譯方法見b端產品設計：整體方案長這樣？。

1）項目背景

產品r&d是公司經營行為的延伸，必須有經營目標(預期收益)。

定制產品是為了實現客戶對項目的目標預期而設計的(從乙方的角度來看，客戶可以通過驗收)，自主開發產品的預期收益不能簡單粗暴地由業務收入決定。

2）預期收益

方案概述是讓讀者從全局的角度了解方案設計的思路，以免直接陷入細節。什么是程序概述？基于整體解決方案的擴展，。對于b端自研產品的預期收益制定需要符合smrat原則，可以考量功能使用率、客戶滿意度等。

3）方案概述

制度不能解決所有問題，所以會有界限。項目范圍是指產品的業務范圍和相關系統。在項目實施前，需要及時與項目干系人確定項目范圍、實施時間和資源消耗(成本)，避免關鍵信息溝通不暢帶來的項目風險。

針對痛點問題描述產品的核心功能模塊、技術實現方案、運營支持方案等內容。

風險是一個無論如何都不能忽視的問題。預先設定風險項目和解決方案，從而降低失控的概率。項目中存在哪些風險項目？

流程：沒有明確的標準化流程；進度沒有及時更新；任務報告占用了太多資源(人員、時間).

計劃：重要事項省略；時間評價不合理；任務分配不合理；該計劃沒有預留緩沖時間.

人員：人員不足；新人員的改編費用；任務和人員技能的不匹配…

溝通：信息傳遞機制不完善導致溝通效率低下(傳遞方式、觸發傳遞條件、指定對接人).

需求：需求的變化；變更引起的工作調整(項目規劃、設計、開發和測試).

技術：開發環境不穩定；對技術困難的評估不足；開發和測試時間評估不準確；三方系統對接進度延遲.

其他：服務器不到位；市場和政策問題.

03

4）項目范圍

5）項目風險

產品框架是系列構成圖的構成，為了讓讀者對產品的構成和結構有更深入的了解。包括以下內容：

系統架構圖：開發當前系統不同層次的功能模塊，表達功能層次的概況。

功能結構圖：系統結構的反匯編是對一級菜單和二級菜單中具體頁面操作項的細化。細化成字段，就成了信息架構圖。

操作流程圖：用戶使用系統時，如何通過一系列操作完成相應的任務。

狀態機圖：描述每個關鍵節點的狀態是如何觸發和流動的。比如訂單狀態的改變。

以下是過去項目的例子，其中一些已經簡化。下圖。

圖：系統架構圖

圖：功能結構圖

(950

圖：狀態機圖

詳細部分

全局通用術語、縮寫、交互、系統規則、異常等相關內容可以在全局描述中統一解釋。避免在文檔中重復出現，這樣會導致文檔臃腫，閱讀困難。比如：輸入框定義、類型、數量限制等。分頁規則、各種類型彈出窗口的交互式描述等。

異常包括斷線、誤操作、數據丟失等。需要描述如何處理相應的案例，也可以寫在具體功能需求的描述中。

1）產品框架

原型是比較終產品每一頁內容的呈現，它闡述了用戶和產品之間的交互過程。通過產品架構，可以獲得需要設計的頁面和頁面元素。有關原型工具選擇、顏色匹配選擇、頁面類型和交互注意事項的詳細信息，請參考上一節b端產品設計：拆個“詳細設計”給你看。

原型頁面通常與規則一起呈現，規則注釋在頁面旁邊。

2）全局說明

對每個頁面和彈出窗口都做了詳細的功能描述，并對功能邏輯、字段規則等信息進行了清晰的描述。同時，要盡量使用分段語句描述，避免大規模的話語描述。更詳細的內容，新文章介紹。

思維(用什么工具寫prd文檔)" src=" https://p6-tt . byteimg.com/origin/pgc-image/5bb 1 e2e f 664 a 4316 bb 000 c 039118 ec 7 . png " class=" aligncenter "

圖：原型頁面規則注釋

5）非功能需求

除了功能性需求的描述，不要忘記非功能性需求。非功能性需求有很多種，也會涉及到很多利益相關方，應該根據具體項目的具體需求來設計。一般，如性能要求、操作要求、數據統計要求等。

性能要求：性能要求需要考慮用戶體驗和資源輸入成本，例如響應時間、比較大并發性、兼容性要求.

運營計劃：產品的配套運營和推廣計劃，在設計運營者和產品時應予以確認和記錄。

數據統計：可以根據產品需求設計數據嵌入需求，可以監控嵌入點，如按鈕、頁面、事件等。可以自己埋，也可以用市面上成熟的數據采集軟件。

以上。