產品需求文檔的寫做(一) – 寫前準備(信息結構圖)

當咱們初次接觸產品需求文檔時，首先會從網絡上尋找產品需求文檔模板，但願從中瞭解和學習具體的寫做要求，但實際上，如今網絡上絕大部分的PRD文檔都是與實際工做不相符的，或者說是複雜的。

前幾天一位從事產品類工做的朋友，發來一份他寫的產品需求文檔目錄截圖給我(下圖)，當時我就鬱悶了，這些類目更像是MRD文檔，而不是PRD文檔了，所以我決定寫幾篇講述寫做PRD文檔的文章，分享一些我關於PRD文檔的看法和寫做方法。

PRD是英文Product Requirement Document的縮寫，中文的意思是產品需求文檔，具體的名詞介紹你們能夠詢問Google。PRD文檔是基於BRD、MRD的延續文檔，主要用於產品設計和開發使用，所以閱讀這份文檔的人羣絕大多數是設計與技術人員。在這類人羣中，設計師更多依賴於原型進行交互或視覺的設計，所以看這份文檔的人就會偏向於技術人員。相對於技術人員，他們不太關注產品的商業需求和市場願景，由於在進行產品討論立項時，產品的定義就已經向參與設計和研發的人員宣講過，所以技術人員更多的是關注界面、功能、交互、元素等等內容，所以PRD文檔是一份詳細的產品功能需求說明文檔，是產品文檔中最底層和最細緻的文檔。

PRD文檔是一份沒有閒話，直入主題的功能說明文檔，所以咱們在寫做時，腦海裏構思的是成品產品的界面功能的邏輯線框圖。在寫做這份文檔前，咱們須要先作一些準備，把BRD、MRD的相關需求消化並融合規劃出產品的結構圖。由於這些準備工做是屬於思惟類的，因此我推薦使用思惟導圖軟件(MindManager)進行規劃工做。

規劃產品的第一步就是梳理出產品的信息結構，有了信息結構咱們才能繼續往下規劃產品結構，而且信息結構是服務端技術人員建立數據庫的依據，是數據結構的輔助文件。對於新產品或者新功能，沒有人可以比產品經理更加清楚所須要的信息內容了，所以第一步咱們就須要先將這些信息羅列出來，造成結構化。（以下圖）

這張圖是以個人博客做爲示例，在羅列信息結構時，咱們更多的是考慮信息數據，所以在這一步，咱們還不須要深刻的考慮產品的界面與功能。信息結構的考慮有面向前端的，也有面向後端的，具體視產品類型而定。

例如CMS之類的程序，這類程序採用框架式開發，將功能與模板獨立，所以前端具備多變性，而且這類產品屬於平臺型產品。針對這類產品，咱們在規劃信息結構時，只須要簡單的考慮一些前端的功能需求，更多的是面向後端管理員操做進行考慮，從後端入手規劃和羅列出所須要的信息內容結構。

不管是什麼樣的產品類型，不管從哪裏入手，咱們第一步都是先要羅列信息結構，由於信息結構圖不只是輔助技術人員建立數據庫的圖表，也是輔助產品人員進行產品功能規劃的參考，只有對信息或數據的結構瞭解，咱們才能玩轉數據，玩轉產品。

在信息結構轉數據結構時，若是是針對已經存在的產品而增長的新功能，那麼技術人員就須要根據這個信息結構進行數據庫對比，已經存在的數據便直接調用，若是不存在，則就須要具體的討論，肯定新信息的使用途徑和之後的擴展方向，以便確認是建立數據表仍是建立數據字段。（雖然產品經理不須要技術開發，可是若是可以懂技術原理和數據庫原理，很是有助於產品規劃和技術溝通。）

信息結構圖是產品層面的理解，若是要入庫這些信息，還須要進行數據結構的討論。一條信息的存儲有不少附加屬性，具體是存成字段仍是數據表，仍是說存在中間表或者關聯表，這些都須要在完成PRD文檔後和數據庫技術人員共同討論。討論時除了展現信息結構圖，還要講解產品原型和功能需求，以便數據庫技術人員瞭解產品意圖，方便他們作數據庫規劃時考慮到之後的擴展。

信息結構圖是咱們將概念想法造成結構化的第一步，也是咱們接下來幾步工做的輔助文件，同時在接下來的幾步工做中，咱們還會不斷的完善信息的結構。

下一篇我將講解如何梳理產品需求，並根據信息結構規劃出產品結構圖和用戶流程圖。

本文出自 產品經理@唐傑 ，轉載時請註明出處及相應連接。

本文永久連接: http://tangjie.me/blog/52.html