1、理解并掌握PRD文檔

-寫作思路
-寫作方法
-寫作格式

2、什么是PRD文檔

– PRD文檔向上是對MRD內容的繼承與發(fā)展，向下則是要把MRD文檔里面的各種理論要求技術化，向研發(fā)部門與設計部門說明產品的的功能和性能要求。
– PRD文檔是產品文檔中最底層最細致的文檔，所以寫作的時候，需要細致耐心。

3、再談BRD/MRD/PRD文檔的區(qū)別與用途

3.1 BRD

-這么做有好處，并說明好處在哪里

– 唐僧出發(fā)前,參見唐皇（老板）,告訴唐皇西去取經的重要意義與大興佛法的好處,唐皇答應,并發(fā)放免簽護照（授權），于是唐僧帶著任務出發(fā)了，那個時候唐朝真實V5啊。

3.2 MRD

-通過BRD明確了這個事情值得一做后，描述應該這么做，并說明這么做的原因

– 唐僧上路了，但是他需要選擇走哪條路線，帶幾個人，為什么這么走，為什么帶這些人，要說清楚：
>A路線：妖怪多
>B路線：神仙多
>C路線：美女多
經過分析，唐僧決定選擇C路線，所以才有了三打白骨精，路過女兒國等經典故事（開個玩笑）

3.3 PRD

-?獲得了授權，而且已經確定了要走的路線，剩下的就是打造裝備（產品）了

– 要把裝備的需求給工匠（研發(fā)人員），就需要把你（PM）對裝備（產品）的要求講清楚
>金箍棒（需要能縮短到耳朵里面，直徑1毫米，長度6毫米，需要金色，重量必須控制在1KG）
>九齒釘耙（必須要9個齒，廢話啊，黑色，齒長8cm，把手長1.5米，直徑2.5厘米）
>于是工匠（研發(fā)人員）根據(jù)需求，打造出了曠世的武器

BRD>MRD>PRD是一個逐步論證并得出結果的過程，是產品經理思維升華的過程，是這三個文檔三位一體的過程。

4、PRD文檔面向的對象

4.1 研發(fā)人員

-由于研發(fā)人員本生專注于功能的實現(xiàn)與性能，所以他們相對對其它諸如運營，市場，設計等表現(xiàn)相對不太關心，對于產品更多的了解來至于產品經理的產品宣講。

4.2 設計人員

-設計人員本生更多的會關注與產品的調性與原型圖，所以對PRD文檔的需求是相對較弱的。
所以，PRD文檔，根據(jù)閱讀對象，就不要去耍花架子了，用最平鋪直敘最簡單的話，把問題說的一清二楚就行，繞來繞去小心被程序猿們掏出板斧劈成兩截啊。

5、PRD文檔的幾種表現(xiàn)方式

說到PRD文檔，很多朋友之前看過模版，都會不假思索的打開Word開始寫作，其實PRD文檔的目的在于把問題講清楚，而不是用什么工具！根據(jù)實際情況，能滿足把問題講清楚的方式大概有以下幾種：

– 文字模式（Word…..最常見的）
– 原型圖模式（Axure….推薦使用的）
– 圖片模式（有的產品經理本來就是美術轉交互轉產品，所以他們擅長于此，有門檻的….）
– 影像模式也可以，就是太燒油了

6、常見PRD文檔包含內容

文檔說明、產品說明、全局功能說明、詳細功能說明

6.1 文檔說明

6.1.1 產品版本號 （1.26）

-版本號 （ 1.26 ）
–> 重大調整升級
–> 產品結構功能等有調整
只有以上幾點情況出現(xiàn)，才會修改版本號
-子版本號（ 1.26 ）
–>在原有基礎上面對局部功能進行了升級或調整
–> 在原有基礎上面對局部功能進行了升級或調整
只有以上幾點情況出現(xiàn)，才會修改子版本號
-修正版本號（ 1.26 ）
–> 局部小范圍優(yōu)化與Bug修復
–> 一般是不動功能性的東西
只有以上幾點情況出現(xiàn)，才會修改修正版本號
-版本號的命名原則
–> 歸零原則：前一個數(shù)字增加一位，后面的數(shù)字都歸零
–> 收費原則：子版本號和修正版本號的變化，一般看做版本內升級，不加收費用，版本號變化則加
收費用

6.1.2 歷史修訂

– 編號
– 版本號
– 修訂章節(jié)
– 修訂原因
– 修訂日期
– 修訂人
歷史修訂的作用：
->對修改前后進行比較
->有利于維護和管理PRD
->修訂人
->修訂日期
->方便查閱，可以只看修訂部分

6.1.3 名詞術語表

將一些產品里面不易理解，容易混淆，或者縮寫的詞匯在開篇進行統(tǒng)一的列表說明，有利于閱讀。例如
產品100的：
-積分：根據(jù)產品100用戶的一系列操作行為系統(tǒng)根據(jù)后臺設定產生的虛擬分數(shù)，積分決定了用戶的等級
與論壇權限，積分的計算方式為：總積分=發(fā)帖數(shù)X1 + 銅幣X1 + 威望X1 + 會員歷史在線時間X1
-威望：反應了用戶在論壇里面的資歷，是根據(jù)發(fā)帖數(shù)量，回帖數(shù)量，附件上傳數(shù)量，在線時長等綜合因
素決定，是用戶積分的重要參考依據(jù)
-銅板：產品100的貨幣，主要用于購買有價值的下載資料與信息，完成新手任務可以獲得初期足夠的銅
板，發(fā)布下載資源也可以獲得相當數(shù)量的銅板，銅板是用戶積分的重要參考依據(jù)。

6.2 產品說明

包含：產品信息結構、產品結構圖、用戶使用流程圖

6.2.1 產品信息結構

– 信息結構圖是只按照產品經理思路中的產品表現(xiàn)信息來整理產品的一種示意圖（后面會舉例）
> 信息結構能幫助我們整理產品結構，同時是研發(fā)人員建立數(shù)據(jù)庫的參考

6.2.2 產品結構圖

– 產品結構圖是按照產品的邏輯與表現(xiàn)方式,結構化的表現(xiàn)產品構造的一種示意圖（后面會舉例）
- 通過這個產品結構圖，我們大致就能將之前抽象的邏輯形象化的表現(xiàn)出來，也便于文檔閱讀者理解我們的產品思路

6.2.3 用戶使用流程圖

– 用戶使用流程圖用于表述用戶在使用產品過程中的行為走向
通過用戶行為串聯(lián)信息結構與產品結構，閱讀者通過閱讀用戶使用流程，能更好的理解產品經理設計的用戶行為

使用流程圖 -> 產品結構 -> 產品信息結構

6.3 全局功能說明

6.3.1 全局功能說明

由于接下來我們要比較詳細的表述每個類與每個子類的功能說明，所以這里就要把那些不能放到子類里
面去的全局性的東西說清楚盡管是全局功能。但也可以分類說明，例如：UI、交互等等….

全局功能說明案例：

用戶交互統(tǒng)一說明：
– 本客戶端在用戶觸發(fā)操作后，應優(yōu)先加載用戶界面，同時在界面中加載數(shù)據(jù)的位置使用風火輪提示用
戶數(shù)據(jù)加載中。
– 本客戶端的時間顯示，建議使用人性化提示，例如：20分鐘前，一天前，三天前，超過7天的，則顯
示為具體時間，如：3月30日 17點55分，超過一年，則顯示12年3月30日17點55分。

6.3.2 詳細需求說明

整體說明完成以后，我們就要開始對各個需求板塊進行詳細的需求說明
– 根據(jù)實際的需求，你可以按照你習慣的表述順序來表述
常見的表述順序有：
>按照功能的邏輯來表述（更抽象，研發(fā)喜歡）
>按照產品結構來表述(頻道，頁面，模塊，元素的邏輯表述,相對比較適合產品經理的邏輯，產品經理喜
歡），即按前面的產品結構圖來表述。

– 具體哪一個，看團隊要求和默契程度

6.3.3 UML > 用例文檔 > 用例圖與狀態(tài)圖

UML登場了(其實產品經理的PRD文檔寫作所涉及到的UML知識非常有限)
– 中文名稱：統(tǒng)一建模語言
– 英文名稱：Unified Modeling Language
– 定義：是一種面向對象的建模語言，它是運用統(tǒng)一的、標準化的標記和定義實現(xiàn)對軟件系
統(tǒng)進行面向對象的描述和建模。
UML常見的說明圖類型
– 用例圖-表述
– 狀態(tài)圖
– 時序圖
– 結構圖
– 等….

6.3.4 什么是用例圖

用例：用例就是一種描述系統(tǒng)功能需求的方法
用例圖：用例圖表述的是系統(tǒng)的外部參與者與系統(tǒng)之間的關系,是由參與者與用例組成的示意圖
用例圖的組成要素：參與者(可以是人,也可以是另一個系統(tǒng),也可以是其它的東西,是相對的)、用例、關
聯(lián)線、方框。用例圖不說明具體的流程，用例圖強調的是系統(tǒng)與參與者的關系。?

6.3.5 用例說明

你看到的這個表格,只是一個基本格式,關于用例在業(yè)內并沒有一個成為和固定的專門供你套用的東西,一切都已你團隊的默認習慣和達到那你的目的依據(jù)來寫作用例。根據(jù)你自己的需求去做。

6.4 詳細功能說明

6.4.1 詳細功能需求描述的基本結構

產品的整體用例圖
-功能板塊1需求
– 功能板塊1的子功能1
? 功能板塊1的子功能1的元素1說明(用例描述)
? 功能板塊1的子功能1的元素2說明(用例描述)
– 功能板塊1的子功能2
? 功能板塊1的子功能2的元素1說明(用例描述)
? 功能板塊1的子功能2的元素2說明(用例描述)
? 功能板塊2需求(用例文檔)
– 功能板塊2的子功能1
? 功能板塊2的子功能1的元素1說明(用例描述)
? 功能板塊2的子功能1的元素1說明(用例描述)
– 功能板塊2的子功能2
? 功能板塊2的子功能1的元素1說明(用例描述)
? 功能板塊2的子功能1的元素1說明(用例描述)

6.4.2 詳細需求說明的原則

①MECE原則

MECE，是Mutually Exclusive Collectively Exhaustive，中文意思是“相互獨立，完全窮盡”。 也就是對于一個重大的議題，能夠做到不重疊、不遺漏的分類，

而且能夠藉此有效把握問題的核心，并解決問題的方法。

②MECE只是一種思考方式，當PRD文檔撰寫交付研發(fā)以后，其實多少還是會存在沒有考慮到位或者需求調整的情況

所以:

– 撰寫PRD文檔前一定要保證思考到位了,產品結構本身短期內不會有重大改動
– 需求分類與表述方式要參考MECE原則
– 這樣即便是在交付后，出現(xiàn)調整或需要優(yōu)化的地方，也不會出現(xiàn)重構的情況重構需求,重新調整產品結構等,對已經處在開發(fā)過程中的團隊來說是災難性的
– 需求撰寫，更多的是考驗耐心，思路，經驗，但產品架構的確定等更是考驗一個產品經理對產品的規(guī)劃與把握能力
– 不要害怕，不要迷信

7、優(yōu)秀的PRD文檔應該具備的特點

7.1 正確

確保文檔中的表述與產品經理的思路是對應且正確的

7.2 無歧義

文檔的表述方便閱讀理解，不會產生歧義

7.3 完備

MECE原則盡量保證對產品功能需求表述的系統(tǒng)完整

7.4 一致

文檔中用詞用語一致，對于同一事物的表述應該一樣，避免混用同義詞

7.5 具有優(yōu)先級

產品的功能性需求是有先后主次的，對于一次性規(guī)劃叫多功能的PRD，應該注明功能性需求的先后主次

7.6 可驗證

對于功能性的描述，是可以進行測試的，而不是不發(fā)測試，無法定性的東西，例如：效率高，交互完美等詞語，都是無法驗證的

7.7 可修改

PRD文檔利于后期的修改與升級

7.8 可追蹤

每個功能性需求的來源應該是清楚明白的

8、關于數(shù)據(jù)

“一份國外數(shù)據(jù)分析，樣本數(shù)據(jù)30萬份，其中71.3%的人左手持手機左手拇指進行操作，82.6%的人在iPad上右手操作，平放在腿上時用食指，雙手握時用右拇指”。
- 是不是和我們的想象很不一樣？
- 做產品，有時候需要感覺，有時候需要數(shù)據(jù)。

總結

以上是生活随笔為你收集整理的产品需求文档（PRD）札记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。