請查收 | 好用的PRD教程

2 評論 8459 瀏覽 70 收藏 15 分鐘

編輯導語:PRD文檔撰寫恐怕是產品經理必備技能之一。那么,產品小白在入手撰寫PRD文檔時可能會有哪些混淆之處?如何撰寫才可以做到完整且便于梳理呢?本篇文章里,作者就列出了撰寫PRD文檔的幾點注意事項,相信會對初入行的你有所幫助。

都說產品經理有3大文檔:BRD、MRD、PRD。日常工作中很多產品早已由領導層定好了方向,所以BRD和MRD的編寫機會較少,更常用的是在產品細化階段所用到的PRD。

PRD在項目中起什么作用?什么才是好的PRD?PRD要如何編寫?本文將依次回答相應問題,如有錯漏還請指教。

一、PRD作用:要你有什么用?

PRD是將產品需求和對應需求解決方案一起呈現的文檔。文檔面向項目相關的多方角色,在項目推進中承擔了重要作用,比如:

  1. 產品:根據PRD進行方案宣講,并作為最終檢驗產品實現程度的依據;
  2. 設計:根據PRD的原型作為UI設計參考;
  3. 開發:根據PRD的系統規則等內容作為研發依據;
  4. 測試:根據PRD的規則來編寫用例及測試。

根據需求的覆蓋情況也會有其他角色參與,如運營、商務、財務等。不管面向誰,最終目的都是為了讓團隊成員能夠理解業務,在產品研發過程中得到更好地執行。

二、PRD要求:想要我怎樣?

為了PRD更好地發揮作用,編寫文檔時需要清晰、完整且容易閱讀的方式將復雜抽象的解決方案呈現出來。怎么才能達到這樣的效果呢?文檔起碼需要符合以下要求:

  • 場景完整:需要考慮需求相關的各業務場景,尤其是特殊場景的應對機制。避免場景缺失造成方案漏洞。
  • 框架清晰:提供系統架構、業務模型、功能結構、系統流程等系列框架,幫助成員從全局層面了解系統概況。
  • 邏輯自洽:系統操作涵蓋業務的正向和逆向流程、主流程和分支流程,形成系統操作閉環且不沖突。
  • 規則簡明:對系統全局說明、功能模塊、非功能需求等各項規則進行描述,編寫需通俗且完整。
  • 設計友好:系統頁面的布局、導航、交互、文案等交互動作,設計需要符合尼爾森可用性原則。

結合具體情況,PRD編寫時也會存在其他要求。比如非功能性要求(數據指標需求、運營需求……),也要做到對要求的定義明確無異議。

三、PRD編寫:注意你的尺度!

知道了PRD的要求,編寫時可以向要求靠攏。但是要求只能作為指導思想,卻沒有告訴我們具體怎么編寫,你可能還有這些疑問。

1. PRD要用什么形式呈現?

PRD常見形式有2種——word和原型。2種形式各有優劣,比如word版的目錄讓人更容易總覽全局;原型版在功能需求描述時表現更靈活。

采用那種方式要先看公司制度,如有相應規范直接執行即可(規范也可以調整),如果公司沒有要求,則產品經理經過和團隊溝通,采用大家認可的、更方便表達和閱讀的方式即可。

2. PRD要寫到什么顆粒度?

寫過PRD的同學應該都有過這個疑問。尤其是對規則的描述,寫粗了怕有遺漏,寫細了怕沒人看。除了描述上精簡用詞,還能從規則提煉和原型設計上進行把控。

  1. 規則提煉:對約定俗成的規則、可復用的規則的通過“全局說明”進行描述。如手勢操作、輸入框定義及限制等。
  2. 原型設計:輸出的原型不要有高保真原型,耗時且影響UI發揮;不要有復雜交互,不利于快速識別,可在備注中說明;不要過度設計……

3. PRD由哪些部分組成?

對過往項目的PRD常用組成部分進行總結,從通用、概要、詳細等部分來拆解,僅供參考。每份PRD的具體組成需要項目結合實際情況進行增刪。

  • 通用部分:名稱、目錄、更新記錄;
  • 概要部分:項目背景、預期收益、方案概述、項目范圍、項目風險;
  • 詳細部分:產品框架、全局說明、原型頁面、功能需求、非功能需求 。

四、PRD組成:請問你完整嗎?

終于到了編寫環節!PRD制作是產品經理的基礎工作之一,能夠直觀反映產品經理的底層專業能力是否扎實?,F在知道了PRD的組成,接下來以原型版為例具體說說各部分如何編寫。

1. 通用部分

1)文檔名稱

文檔名稱是為了能區分不同產品和版本。常規命名方式是產品名稱+版本號。這里“版本號”的命名每個公司都不一樣,可以用V1.0或日期作為版本號。能識別并快速區分即可。

如:XX車輛租賃管理系統V1.0;XX車輛租賃管理系統-210504。

2)文檔目錄

一般word形式的PRD會配有文檔目錄,讓閱讀者更直觀的了解全局。使用原型版本也可以做到類似的效果,可以單獨用頁面定義為“目錄”,將word版本的內容放進去,也可以通過對原型頁面的規則命名達到此效果。如下圖(部分頁面做了隱藏)。

請查收 | 好用的PRD教程

3)更新記錄

每次PRD的更新一定要進行記錄,幫助閱讀者了解每次更新的內容。更新記錄一般以表格形式呈現,主要字段包含:更新時間、變更屬性(新增、刪除、修改)、更新內容、更新人員。

請查收 | 好用的PRD教程

2. 概要部分

1)項目背景

背景描述是為了讓閱讀者了解項目或需求的來源和具體情景。

背景包含了業務概況、業務流程、當前問題、整體解決思路等相關內容。相應內容在用戶調研和編寫整體解決方案時都會涉及,可直接使用。編寫方法詳見《B端產品設計:整體方案長這樣?》。

2)預期收益

產品研發是公司商業行為的延伸,一定會有商業目標(預期收益)。定制化產品是為了實現客戶對項目的目標期望(從乙方角度,客戶驗收通過即可),自研產品的預期收益則不能簡單粗暴的直接用業務收益來定。

對于B端自研產品的預期收益制定需要符合SMRAT原則,可以考量功能使用率、客戶滿意度等。

3)方案概述

方案概述是為了讓閱讀者從全局層面了解方案設計的思路,不至于直接陷入細節中。

什么是方案概述呢?基于整體解決思路進行拓展,針對痛點問題描述產品的核心功能模塊、技術實現方案、運營支持方案等內容。

4)項目范圍

系統不可能解決所有問題,所以會有邊界。

項目范圍是指產品所涉及的業務范圍、所關聯的系統等。

項目實施前需要及時和項目相關方(干系人)確定項目的范圍、實施時間、消耗資源(成本),避免關鍵信息溝通不暢導致的項目風險。

5)項目風險

風險是任何事項都不能忽視的問題。提前預設風險項及解決方案,從而降低失控概率。項目中存在哪些風險項呢?

  • 流程:沒有明確的規范流程;進度更新不及時;任務匯報占用資源過多(人員、時間)……
  • 計劃:重要事項遺漏;用時評估不合理;任務分配不合理;計劃沒有預留緩沖時間……
  • 人員:人員不足;新人員的適應成本;任務和人員技能的不匹配……
  • 溝通:信息傳遞機制不到位導致溝通效率低(傳遞方式、觸發傳遞條件、指定對接人)……
  • 需求:需求變更;變更導致的工作調整(項目計劃、設計、開發、測試)……
  • 技術:開發環境不穩定;技術難點評估不足;開發和測試用時評估不準;三方系統對接進度延期……
  • 其他:服務器沒到位;市場及政策問題……

3. 詳細部分

1)產品框架

產品框架是系列組成圖表組成,為了閱讀者更深刻的理解產品在組成和結構。包含以下:

  • 系統架構圖:通過不同層級開展現系統的功能模塊,表達功能層面的概況。
  • 功能結構圖:系統結構的拆解,是一級菜單>二級菜單>具體頁面>操作項的細化。再細化到字段,就成了信息架構圖。
  • 操作流程圖:用戶使用系統時如何通過系列操作完成對應任務的過程。
  • 狀態機圖:描述各關鍵節點的狀態如何觸發和流轉。如訂單狀態的變化。

以下是過往項目的示例,部分內容做了簡化。如下圖。

請查收 | 好用的PRD教程

圖:系統架構圖

請查收 | 好用的PRD教程

圖:功能結構圖

請查收 | 好用的PRD教程

圖:系統操作流程圖

請查收 | 好用的PRD教程圖:狀態機圖

2)全局說明

針對全局通用的術語、縮略語、交互、系統規則、異常情況等相關內容,可以在全局說明中統一說明。避免在文檔中反復出現,導致文檔臃腫,造成閱讀困難。

比如:輸入框定義、類型、數字限制等,分頁規則,各類型彈窗交互說明等。

異常情況則包含了斷網、誤操作、數據丟失等情況,需要描述對應情況下如何處理,也可以寫在具體功能需求描述中。

3)原型頁面

原型是對最終產品各頁面上內容的呈現,闡述了用戶與產品之間交互過程。通過產品架構可以得出需要設計的頁面和頁面元素。關于原型工具選擇、配色選擇、頁面類型、交互注意事項等內容詳見上一篇《B端產品設計:拆個“詳細設計”給你看》。

原型頁面通常和規則一起進行呈現,頁面旁邊是規則備注。

4)功能需求

針對每個頁面、彈窗進行詳細的功能描述,將功能邏輯、字段規則等信息描述清楚。同時盡量采用分段的陳述式描述,避免大段論述型描述。更詳細的內容新開文章介紹。

請查收 | 好用的PRD教程

圖:原型頁面+規則備注

5)非功能需求

除了功能需求的描述,千萬不要忘了非功能性需求。非功能性需求有很多種,也會涉及多個相關方,要結合具體項目具體需要進行設計。常規比如性能需求、運營需求、數據統計需求等。

  • 性能需求:性能需求需要考慮用戶體驗和資源投入成本,比如響應時間、最大并發量、兼容性需求……
  • 運營計劃:產品配套的運營推廣計劃,設計運營方,產品設計時需要確認并記錄。
  • 數據統計:可根據產品需求進行數據埋點要求設計,進行埋點監控,如按鈕、頁面、事件等??梢宰约郝顸c,可以使用市場成熟的數據采集軟件。

以上。

 

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
1人打賞
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 路過

    回復
    1. +1

      回復