第三篇：產品需求文件（PRD）

在前面兩篇文章《關於產品經理的三個文件（BRD）》和《關於產品經理的三個文件（MRD）》中我把自己對商業需求文件（BRD）和市場需求文件（MRD）理解做了闡述。這一篇我再來說說產品需求文件（PRD）的撰寫。

不過說文件的撰寫之前，我需要先插一些內容。

上面這句話的後面半句又讓我想起之前的一個領導，他總喜歡打斷別人說話時這麼說：“你等會兒，我先插你一下…”，每次都搞得我好拘（菊）謹（緊）。

同學甲：我艹，小樓老師又開車了！

同學乙：小樓老師，不是說好不汙的嗎？

同學丙：汙皇，萬歲，萬萬歲！

讀者：一臉懵逼……

好了，以上純屬扯淡！咱們繼續正經分析，我要插點什麼進來！

我要插進來的內容是：產品原型。

經常有人說產品原型是產品需求文件的另一種形式。

這種說法沒有什麼問題。

但是，我更傾向於產品原型是市場需求文件與產品需求文件的過渡。

在市場需求文件中，我就在功能概況部分插入了原型圖。

也就是說，當我們在尚未決定產品研發之前的決策階段，就應該有原型參與進來，幫助我們決策。

那麼，決策完畢之後呢？

這個時候，原型圖則要承擔以下責任：

• 線框原型：確定產品結構、佈局、功能、模組關係、操作流程。
• 互動原型：功能可用性測試、使用者體驗測試。

也就是說，在撰寫產品需求文件之前，我們應該已經對產品進行了評審，確保了功能完整、可用且體驗良好。在此基礎上我們再梳理產品需求文件，則會變得更加容易，也能夠避免疏漏與錯誤。

接下來，再說產品需求文件。

產品需求文件其實我們只需要基於商業需求文件、市場需求文件以及產品原型做詳實的敘述就可以了。

在下面大家能夠看到文件的結構，其中背景、定位、使用者群體等均來自商業需求文件和市場需求文件，而結構與功能來自產品原型。只有產品安全與時間進度等需求是補充的產品需求。

有的同學可能有疑問：有沒有把產品背景、定位這些在每個文件裡都寫出來？

這是有必要的！

因為，每個文件的閱讀物件是不一樣的，作為產品經理有責任、有義務讓每一個參與者知道並理解產品的背景、環境、定位目標、文化理念與價值觀念。這樣才能讓每一位參與者都有明確的方向，形成一致的思想，促進產品的生產程序，避免人為障礙。

之前，我提到產品需求文件時，是這麼描述的：

產品需求文件（PRD）：用什麼賺？怎麼多賺？

• 用什麼賺？

這裡指的就是產品需要具備哪些功能？如何設計這些功能？

比如：產品的結構、組成、流程、使用者許可權等。

• 怎麼多賺？

這一點有兩個角度，一方面是產品設計，另一方面是產品安全。

（1）產品設計需要考慮使用者的愛好、習慣等方方面面，在完善基礎功能的同時，還要考慮中如何能夠盈利最大化。在滿足使用者的需求同時，挖掘潛在需求以及擴大使用者規模，都是盈利最大化需要考慮的內容。例如網路遊戲從最初的的點卡收費到道具收費，還有網際網路產品的分享功能，金融工具的收費分析功能，都是基於盈利最大化的設計。

（2）產品安全對產品是非常重要的，特別是網際網路產品！政策管控、環境變化、黑客攻擊、抄襲複製、訪問壓力、開發延期、不可抗力等等，方方面面可能對產品造成的風險都是產品經理需要考慮的。避免風險帶來的損失也是賺的一種。

那麼，既然知道了寫這篇文件的目的，接下來，我們來說一下這個文件要包含的內容。

一、文件屬性

• 文件名稱：XXX產品需求文件（或說明書）
• 版本號：V1.0
• 撰寫人：小樓
• 閱讀人：開發部、測試部、市場部、營運部
• 首次釋出時間：2017年1月28日
• 預計上線時間：2017年6月28日

二、修訂記錄

（1）修訂時間：2017年2月12日

（2）修訂內容：XXX頁面/XXX模組/XXX用例，新增/刪除/修改了XXX內容。

（3）修訂人：小樓

三、產品概況

（1）背景：參照商務需求文件。

（2）定位：參照商務需求文件。

（3）使用者：參照市場需求文件。

四、使用者角色

寫明不同的使用者型別，例如：遊客、註冊使用者、匿名使用者、Vip使用者、管理員等。

五、產品結構

• 產品結構圖：參照前文。
• 產品資訊圖：這張圖是在產品結構圖的基礎之上細化它的組成，包括模組與元素。

• 用例圖：可以理解為不同的使用者角色能夠使用的功能。（圖片來自網路）

• 業務流程圖

不同角色行為形成的對產品功能的操作流程，給出相應的流程圖。下面以使用者評論為例。

六、產品功能

（一）、用例編號

登入賬號：XXX-001

註冊賬號：XXX-002

瀏覽資訊：XXX-003

……

（二）、用例說明（以釋出評論為例）

（1）用例名稱：釋出評論

（2）用例編號：XXX-019 （編號格式各公司有不同規範，此處是XXX是產品名稱簡寫。）

（3）角色：註冊使用者

（4）用例描述：使用者瀏覽諮詢時釋出評論。

（5）前置條件：登入賬號、瀏覽評論

（6）基本事件：

1. 在評論頁點選評論按鈕，進入評論介面；
2. 在評論編輯區中輸入內容，點擊發布按鈕釋出評論。

（7）分支事件：點選清空按鈕清空輸入的評論內容。

（8）約束條件：評論內容必須超過10個字元。

（9）異常事件：未輸入內容時或輸入不符合要求時給予提示。

（10）後置條件：編輯評論、刪除評論（後置條件是指完成此用例才可執行的用例，即本用例是後置條件中所述用例的前置條件。）

（11）流程圖/場景圖：

• 流程圖

• 場景圖

七、產品安全

所有對於產品安全有威脅的風險均要考慮，並分類整理，提出對應的解決方案。例如：原創資訊內容的圖片要加上水印或標記避免惡意抄襲複製行為；視訊類產品可以通過隨機時間與位置的唯一使用者標識水印，震懾某些使用者盜錄傳播的行為。

八、時間進度

（1）研發進度

這一塊需要與技術負責人確定任務的劃分和完成的時間節點，通過甘特圖進行管理控制。

（2）優先順序

一些產品的功能並非同期上線，在此可以根據上線優先順序規劃每一部分產品功能的上線時間與研發進度。

以上內容是本人對產品需求文件撰寫的理解，分享給大家。如有問題歡迎指正！

用了三天時間終於把《關於產品經理的三個文件》全部寫完了，期間也受到了很多朋友的幫助與鼓勵，我也希望我寫的這些內容能夠給更多的人以幫助！如果覺得我寫的文章有幫助，請在下面多頂我幾下，讓我更興奮的做下去。覺得那篇文章有用就收藏分享，但是別忘了喜歡！

感謝每一位支援小樓的朋友！