PRD到底該怎么寫?更全面的文檔范例來了

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

產品經理日常工作不可缺少的一點就是寫PRD,想要寫好它,需要一套完整的寫作思路和框架。

2015年,我寫了一篇梳理PRD的文章《PRD到底該怎么寫?》,獲得3.5萬次閱讀,423次收藏。至今已過去5年,在這5年里,我一直從事產品產品相關的工作,也經歷過一次完整的創業,對PRD又有了一些新的思考。

這篇文章是《PRD怎么寫》的升級版,彌補了之前文章的不足,對怎么寫PRD,描述得更具體、更全面,是我思考的沉淀,也希望對大家有一定幫助。

01 你是否遇到過這樣的問題?

  • PRD里關鍵需求描述不準確,研發過程中不斷修改,導致項目延期;
  • 產品總監、項目經理、研發、測試總是不斷挑刺,信譽度降低,自信心受打擊;
  • 到新公司負責新項目,前任產品經理留下的文檔晦澀難懂,不知所云。

如果遇到以上一個或多個問題,那么你可能需要反思,自己寫PRD的思路是不是有問題?寫PRD是產品經理非常重要的基本功,寫好PRD,可以提高團隊效率,減少無效的溝通。

02 什么是PRD?

PRD是Product Requirement Document的簡稱,其中文翻譯為:產品需求文檔。該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最重要的一個文檔。

PRD的主要使用對象有:研發、測試、交互設計師及其他業務人員。

  • 研發可以根據PRD獲知整個產品的邏輯,作為編碼的依據;
  • 測試可以根據PRD編寫測試用例,為正式測試做準備;
  • 交互設計師可以根據PRD設計交互細節;
  • 業務人員可以通過PRD提前了解產品,為運營和推廣做準備;

PRD是項目啟動之前,必須經過評審達成共識的最重要文檔。

產品經理的PRD,就像建筑設計師的設計圖紙,是設計和思考的文檔化呈現。

《用戶體驗要素》作者在書中有一句很經典的話:“文檔不能解決問題,但定義可以”,PRD就是要定義需求。

03 動手之前,先思考這幾個問題

1. 解決什么問題?

解決用戶什么問題?發現問題比解決方案更重要。給公司能否帶來收益?相關干系人的需求是什么?是不是老板說這樣做的?是不是“他們”說這樣做的?他們是誰?真正的問題是他們說的那樣嗎?

產品經理正確的設計思路如下:

這叫RTPA設計框架,是一種逆向思維假設分析,我們要使用這樣一種思考技巧:假設初始需求都是錯誤的,即問題并不存在,你需要重新發現問題。

不要需求方一提需求,就開始著手設計,多問幾個為什么并著手調查,以了解真正的問題。

下面是一次完整的設計思路示例:

2. 怎么衡量?

不同的干系人,通過什么指標去衡量問題是否已解決?有沒有埋點?有沒有業務數據?誰來運營?

3. 需要多少資源?

為了實現這個解決方案,需要多少資源、多少人?能大致評估嗎?

4. 會不會太復雜?

這個解決方案會不會太復雜?復雜是產品的墳墓。有沒有性價比更高的解決方案?會不會影響現有的業務?會不會影響歷史數據?

5. 有風險嗎?

這個方案會有風險嗎?有沒有違法?相關政策是什么?尤其是金融、游戲領域,國家監管比較嚴,有可能上不了應用市場,有可能三方服務商不會提供服務。

6. 有創新嗎?

有更創新的解決方案嗎?競品怎么做的,有沒有調研3個以上的競品方案。

7. 用戶怎么說?

需求真的是提交人說的那樣嗎?有親身體驗過場景嗎?有跟用戶面對面交流嗎?熟悉相關領域的基本知識嗎?有看不懂的名詞嗎?

動手寫文檔或做設計方案之前,一定要問問自己以上幾個問題,想清楚了在動手,任何一個問題沒想清楚,都不要進行下一步。

04 寫PRD的基本步驟

搭框架、定流程、扣細節,這是從一名產品前輩那了解到的產品設計流程,寫PRD,也可以按照這個思路。

1. 搭框架

首先遍歷出所有用戶角色,再針對每個角色,提供相應的系統/功能,然后按照某種維度進行結構劃分。這個步驟完成后,就可以輸出產品的系統架構圖及系統的功能結構圖。

產品架構圖,出自《電商產品設計全攻略》

更細化的功能結構圖

產品由一個個功能組成,功能是邏輯結構,一個完整的功能具備輸入、處理、輸出三大特性。從大到小的劃分是:系統>功能???gt;功能,用戶+功能組成了用例,用例是PRD文檔里描述占比70%以上的內容,所以合理的功能結構,是寫好PRD的前提。

2. 定流程

每個產品都有一個核心業務流程,這個核心業務流程涉及多個角色,這個步驟就是把各個角色和功能聯系起來。通過核心業務流程,閱讀者可以了解產品全貌,對產品有個宏觀的認識。

此外,每個系統也有各自的核心業務流程,全業務流程+子系統業務流程,可以概括產品的業務邏輯。

這個步驟輸出產品核心業務流程圖,子系統核心業務流程圖,活動圖,狀態機圖,與外部系統交互可能還有時序圖。

3. 扣細節

這一步的核心的畫原型和功能設計,通過原型表達產品的界面和交互。功能設計主要是從輸入處理輸出三個方面去考慮,用戶執行輸入指令后,系統會進行邏輯處理,然后輸出結果。此外,還要考慮功能涉及到哪些數據,表結構怎樣設計,這些會涉及大量細節,PRD大部分內容,都是在描述這些細節。

步驟1和步驟2沒有嚴格的順序,也可以先梳理業務流程,再根據流程中的具體場景梳理出實際功能或系統結構。

05 文檔的組成部分

1. 修訂記錄

記錄每次文檔更新的時間、作者、修訂內容,便于追溯歷史變動;

2. 全局說明

包括名詞解釋、統一異常處理、列表默認數據規則等。

  • 名詞解釋:每個行業都有專業術語,可以提前將晦澀難懂的術語提前做好解釋,便于達成共識,更好溝通;
  • 統一異常處理:網絡異常、后臺服務異常的交互邏輯;
  • 列表默認數據規則:默認列表的排序方式,默認顯示條數,超過多少條翻頁,缺省值展現方式;
  • 所有涉及全局的描述,都可以羅列在這里。

3. 項目背景

每個產品,都有一套價值模型。以信貸產品為例,針對用戶的價值指標有放款額、審批時長、是否上征信等;針對后臺業務人員,有審批時效、通過率、放款率、壞賬率等指標;針對老板,有投資回報比、員工成本、凈利潤等價值指標,每一個需求,應該都是圍繞某個價值指標展開。

背景從現狀、方案、目標3方面描述。

  1. 現狀:描述當前需求方遇到的問題,最好能跟價值模型關聯;
  2. 方案:針對這個問題,所提供的解決方案概述;
  3. 目標:期望獲得多少價值指標提升;

通過項目背景的描述,可以讓項目參與者感受到自己的工作價值。

4. 項目范圍

項目范圍對應搭框架部分,將功能結構圖在此處羅列;

5. 業務流程

業務流程對應定流程部分,將核心業務流程、子系統業務流程在此處羅列;

6. 功能需求

這個部分在PRD中占比最大,搭框架部分,已經將產品功能點全部梳理出來了,這部分就是對功能點進行逐一描述。

功能是從系統的角度來看,我們還要考慮用戶角度,所有我們采用用戶+功能的方式來描述需求,這就是用例。完整用例名稱一定是動賓結構,如添加文章、刪除文章、修改文章、查看文章列表。

一個完整的用例包含:

  1. 描述(非必須)
  2. 前置條件
  3. 后置條件
  4. 界面交互
  5. 業務流程
  6. 異常和分支流程
  7. 數據字典(非必須)

1)描述

功能的簡要描述。

2)前置條件

要操作此功能,需要具備什么角色、權限或狀態。

3)后置條件

執行完這個用例后,關聯的數據會有什么變化,頁面怎么跳轉。

4)界面

每個界面都可以拆分成多個元素,如表單、文本、鏈接、圖片等;

表單的每個元素要描述是否可為空、是否有初始內容、是否默認選中、是否有字數限制等,還有對應的錯誤提示;

文本要考慮最大顯示長度,超過怎么處理;

鏈接一定要指定點擊后跳轉到哪個頁面;

圖片要考慮顯示的比例,如果未加載出來該顯示什么;

還要考慮界面的內容是寫死還是通過后臺配置;

界面元素:

5)業務流程

當用戶完成輸入并提交時,后端應該做什么校驗,不同輸入該怎么處理,不同結果該返回什么值,最好通過業務流程圖+文字來描述,確保邏輯完整。

示例:

文字版:

6)異常和分支流程

異常流程如網絡錯誤、接口返回異常、服務器內部錯誤等;

以登錄為例,分支流程包括找回密碼、密碼登錄等,分支流程非必須,簡單的分支流程可以直接通過主流程體現,具體可以視情況按照一定顆粒度進行拆分。

7)數據字典

這個用例涉及哪些數據,可以通過數據字典描述,這一步非必須,最終表結構也不一定就是這樣,只是給開發一個參考。有技術背景的產品,也可以做得更細。以注冊功能涉及的用戶表為例:

產品經理一定要懂基本的數據庫知識,程序=數據結構+算法。用戶使用產品時,本質上是在和數據進行交互,只是在用戶和數據之間,加了一些列算法。

7. 非功能需求

數據需求。常見的就是數據埋點,產品經理需要梳理出埋點事件表,告知開發,讓開發在編碼過程中進行埋點。

監控需求。需要監控某個接口或某些服務,當出現異常時,可以發送報警信息至相關人員。

性能需求。需要支撐多大的并發,運維人員可以提前準備部署方案。

06 最后

一定要用正確的思路去寫PRD,更要想清楚PRD所呈現方案的價值。方向不對,努力白費。記住,找準問題比解決方案更重要。

 

作者:刀哥;公眾號:刀哥說。

本文由 @刀哥 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 受益匪淺

    回復
  2. 怒贊

    回復
  3. 寫的非常的好,值得學習借鑒。

    回復
  4. 受教,感謝

    回復
  5. 刀哥已經做了一個真實的完整案例,關注刀哥公眾號:刀哥說,刀哥發給你。

    回復
  6. 評論區大家的需求基本是一種,最好是能展現個真實的案例文檔,這樣會理解會更直觀些

    回復
  7. 如果有個案例就完美了 :oops:

    回復
    1. 刀哥已收到。

      回復
  8. 最后評論一個就是,快說,是不是偷偷的把某家公司的PRD模板給解釋了一下,然后上傳的啊 :idea:

    回復
    1. 刀哥從事產品多年,踩過不少坑,都是經驗之談。

      回復
  9. 大贊一個,這篇文章綜合了其他許多介紹PRD文檔的寫法,很多產品總是把PRD一點一點的寫成了一個交互文檔,而真正存在內涵的是項目背景業務流程、詳細的功能需求、非功能需求等等,如果是個pd數量很大的項目那就可能會牽扯到數據字典,最后的最后,就是感覺真的是很好!

    回復
  10. 有很大的收獲,謝謝!!

    回復
  11. 要是能提供一個完整真實的案例就相當不錯了

    回復
  12. 受教了

    回復
  13. 受教了

    回復
  14. 受教了

    回復
  15. 只問一句:產品的信息結構圖在哪?還是有必要輸出吧。

    回復
    1. 每個用例都有數據字典,我理解這就是信息結構,只是沒有做信息結構圖。

      回復
    2. 數據字典已經到了軟件研發的概要設計階段了。
      信息結構圖原沒有數據字典這么詳細(有長度,有類型,主外鍵。。。),但是產品經理在一開始進行主流程設計,功能解析設計階段,就應該有一張信息結構圖。

      回復
    3. 灰常有道理,有信息結構圖,讓相關人員能更快速了解整體、全貌,數據字典偏細。

      回復
  16. 說,哪里抄來的。

    回復
    1. 刀哥混跡IT圈多年,關注互金、保險、理財領域,不存在抄一說,有問題歡迎和刀哥討論。

      回復
圈子
關注微信公眾號
大家都在問