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

36 評論 123855 瀏覽 750 收藏 15 分鐘

產品經理日常工作不可缺少的一點就是寫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. 搭框架

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

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

更細化的功能結構圖

產品由一個個功能組成,功能是邏輯結構,一個完整的功能具備輸入、處理、輸出三大特性。從大到小的劃分是:系統>功能模塊>功能,用戶+功能組成了用例,用例是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協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 大佬,有沒有原型模板啥的可以學習下呀,感激不盡哦!

    來自廣東 回復
  2. 和我認知里的PRD不太一樣,感覺比較像DRD的寫法。產品定位,用戶調研,需求分析,競品分析這些部分不需要寫嗎?

    來自山東 回復
  3. 一直很苦惱需求文檔咋寫,老是寫的不規范,終于找到了示例

    來自北京 回復
  4. 請問下作者,前置功能和后置功能是什么意思,可以舉例說明下嗎?

    來自江蘇 回復
    1. 我的理解是,前置條件是指你這個功能點,需要其它模塊或者功能協助調整的,比如上下游,上游要改造什么,才能銜接上這部分需求;后置條件是指你這個功能點可能對后續其它的業務流程或者功能有什么影響,比如下游的流程。

      來自河北 回復
  5. 刀哥,有沒有模板呀,跪求大佬來一份呀,拜托拜托

    回復
  6. 要是有模板就更好了,是不是我要求太高了

    來自四川 回復
  7. 關于文本的限制從產品的角度我們是給前端的限制條件更好些還是給數據庫的限制條件更好些呢?

    來自天津 回復
    1. 前端吧,如果從后端進行限制,加大訪問速度。

      來自陜西 回復
  8. 如果能提供一個模板就更好了

    來自福建 回復
  9. 又細致又清晰,不僅說了怎么寫PRD,還說了在寫PRD之前要考慮的事情,打開了思路。
    請教刀哥幾個問題:
    1. 您舉得例子是用戶注冊登錄的操作,所有的交互只停留在頁面內,完整定義了字段規則和異常提示。但是如果涉及到多個頁面之間的交互,或者有需要用戶操作的彈窗提示。全部放在【規則】這一欄是不是不太好,會顯的比較雜亂,導致考慮不全面。
    2. 數據字典這個地方是為了讓開發去記錄這些數據嗎?

    來自北京 回復
    1. 1、頁面見的交互可以用剪頭+備注說明業沒有問題,這樣對閱讀者更友好;
      2、數據字典是盡可能描述自己能想到的數據字段,供開發參考,不是必須要寫的。

      來自四川 回復
  10. ?? 很棒,看了幾次都覺得受益匪淺。感謝分享

    來自廣東 回復
  11. 曾經苦逼的寫接口說明、AC;如今每個公司食物鏈頂層的人總會對每個人的能力有不同的“正確且嚴格”的解讀。真不知道PM怎么活下來的 ??

    來自廣東 回復
  12. 受益匪淺

    來自廣東 回復
  13. 怒贊

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

    來自北京 回復
  15. 受教,感謝

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

    來自河南 回復
  17. 如果有個案例就完美了 ??

    來自湖北 回復
    1. 刀哥已收到。

      來自四川 回復
  18. 最后評論一個就是,快說,是不是偷偷的把某家公司的PRD模板給解釋了一下,然后上傳的啊 ??

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

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

    來自河南 回復
  20. 有很大的收獲,謝謝!!

    來自美國 回復
  21. 要是能提供一個完整真實的案例就相當不錯了

    來自新疆 回復
  22. 受教了

    回復
  23. 受教了

    回復
  24. 受教了

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

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

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

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

      來自四川 回復
    4. 有經驗的研發測試,看到信息結構階段,差不多就知道如何實現功能了

      來自廣東 回復
  26. 說,哪里抄來的。

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

      來自四川 回復