PRD 文檔的形式？

01-07

PRD文檔的形式常見的主要是 Word、圖片、交互原型這三種嗎

產品經理主要有兩項職責：①評估產品機會
② 定義要開發的產品；定義開發的產品則需要通過產品需求文檔(PRD）來描述產品的特徵和功能。

一. PRD(開發需求文檔）的作用

在學習如何撰寫PRD之前，我們先要明白寫PRD的目的是什麼：

①概念化」階段進入到「圖紙化」

我們之前在市場需求文檔（MRD）中闡述到的功能，都是表達的一個意向，不考慮實現方法和細節。而PRD則是將概念圖紙化，需要闡述詳細的細節和實現模型。產品人員可以通過撰寫PRD，梳理清楚方案實現過程中的各種問題和影響。

②向項目成員傳達需求的意義和明細

PRD的主要面向對象是項目經理、開發、設計和測試。如何向這些不同的角色表達清楚需求明細，就需要一份規範的PRD文檔來描述。項目經理通過文檔可以迅速了解任務的規模和相關介面，而開發設計人員通過文檔可以了解頁面元素和用例規則，測試人員可以提前根據文檔撰寫測試用例。PRD文檔在形式上是項目啟動的必要元素之一。

③ 管理歸檔需求

大都數的新需求都需要迭代幾個版本後才能走向成熟穩定的階段，如果沒有PRD文檔，在大型項目中，需求的迭代變更將變的無據可循。PRD的文檔修訂編號和命名也是項目規範化管理的主要方法之一。

二.PRD的表現形式

一般企業內部的PRD文檔選擇wiki系統或word文檔。wiki在協同和保密方面會有優勢，而且能夠記錄修改文檔的每一次變更。而word在閱讀修改方面比較有優勢，一般使用Word加SVN的方式來管理更新文檔。這個可根據每個企業的管理規範來選擇那種方法更合適。

三.PRD的主要構成

一份基礎的PRD文檔主要由三部分組成

①引言

引言部分主要包括：需求背景、需求目的、需求概要、涉及範圍、全局規則和名詞說明，交互原型地址等。引言部分的寫作目的是讓閱讀者快速理解需求背景和概要。如果是公司內部文檔，引言部分可以從簡寫作。

②業務建模

建模的目的是為了幫助閱讀對象更好的理解需要開發的需求，常用的模型種類包括：用例圖、實體圖、狀態圖、流程圖等。常用的建模語言如UML。UML具體的建模方法請戳這裡。

③ 業務模塊

業務模塊包含具體頁面的元素、用例規則，以及相關的原型，流程圖。業務模塊的描述是整個文檔最核心的部分，下面博主用案例來描述一下業務模塊的編寫方法。

四. 案例介紹：旅行箱–目的地攻略（應用商店搜索「旅行箱」）

需求的目標是在APP中展示相關國家/城市的旅遊資訊內容，如下圖所示：

那麼我們在第一部分的引言中可以寫下簡單的需求描述：

1. 目的地攻略以城市/國家為單位，展示八個欄目下的文章列表。

2. 初期運營指標為編輯所有涉及城市的歸屬國家攻略內容，相關城市暫不編輯；APP前台默認顯示國家內容卡片，城市內容卡片無數據時隱藏。

3. 運營系統提供內容生成對應的觸屏網頁，App讀取和下載對應網頁內容；

為了幫開發者迅速了解需求結構，我們需要建一個簡單的流程圖幫助開發理解功能：

相對複雜的運營系統，我們可以補充相關用例圖和實體關係圖：

引言和建模部分是為了幫助開發和測試人員快速理解需求，具體的頁面和用例規則還需要通過第三部分的業務模塊來描述，這裡我們節選案例中的文章列表頁來描述：

文章列表頁共包含一個頁面，四個用例

那我們的描述結構就為：

1. 文章卡片頁面元素

2. 收藏文章用例

3. 分享文章用例

4. 查看文章列表

5. 查看文章（太簡單可不描述）

文章卡片的頁面元素描述：

（收藏）用例的描述為

業務模塊的描述一般是原型圖+數據元素+用例描述，這樣可以在原型圖的基礎上加上對應元素屬性的描述，並通過動作描寫的方式表達用例規則和各種流程。這樣的寫作方式不僅可以向不同對象傳達產品經理的意圖，而且可以幫助產品經理自己梳理需求的邏輯和各種異常流程。

閱讀本篇文章，請在應用商店搜索「旅行箱」下載安裝，對照APP中的目的地攻略等頁面進行理解。如果覺得文章還不錯，請支持一下給應用一個評分。

原文地址 http://www.54xiaomeng.com/?p=978

之前的文章簡單介紹了商業需求文檔（BRD），但對於產品經理而言，PRD是產品項目中最為重要的文檔。

PRD是英文「Product
Requirement Document」的縮寫，翻譯為中文就是「產品需求文檔」，主要用於完整描述產品需求，向研發部門明確產品的功能和性能。

PRD的面向對象是研發部門，用於向他們說明需要開發的產品功能和這些功能的性能要求。PRD質量的好壞，在很大程度上不僅直接影響著研發部門是否可以明確產品的功能和性能，而且在很大程度上決定了產品的最終質量。

NO.1 PRD的主要內容

一份完整的PRD文檔主要包含兩部分內容：一是對項目的介紹，包括項目概述、項目價值、項目背景等；二是整份文檔的主體部分，對產品需求的詳細描述，包括功能需求和非功能需求。

對於不同的公司、不同的項目類型，PRD包含的內容會有所差異，但一般來說，比較常見的PRD都會包含版本修訂記錄、項目概述、項目價值、項目背景、場景描述、功能總表、業務流程圖、用戶界面、功能描述、非功能描述、附錄等模塊。

下面是一份比較常見的PRD的目錄。

1.項目概述

2.項目價值

3.項目背景

4.功能概述

4.1場景描述

4.2功能總表

4.3業務流程圖

4.4 功能描述

4.5 數據監控需求

5.用戶界面

6非功能需求

7.附錄

NO.2 產品功能的描述

用戶界面和功能描述是PRD最重要的兩個部分，用戶界面主要是以產品原型作為載體，用直觀圖形的形式展現產品的功能，功能描述則是在用戶界面的基礎上，以文字的形式詮釋產品功能的細節，使開發人員更清晰地明白產品功能性能的要求。

對產品功能進行描述，一般需要兩個步驟：

第一，
梳理產品功能描述部分的整體結構，有規律地將產品功能分成多個較小的功能單元，並確定描述的先後順序。

比如，在產品功能具體的分解時，可以按功能在系統中的位置、按業務流程、按功能主次、按功能所處界面位置等進行分解。

第二，
以用例的形式描述分解後的產品功能。

用例指的是在不展現系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。它的好處是可以將產品功能需求與產品設計徹底分離，不用考慮具體的系統設計與技術細節。

下面是一個關於旅遊用例圖的展現形式：

除了用例圖，還需要一個與之對應的用例表，規範的用例包括用例名稱、用例編號、角色、描述、基本流程、備選流程、異常流程、後置條件、備註等。

NO.3 PRD的基本要求

一份優秀的PRD文檔應該滿足五個方面的要求：完整、準確、清晰、簡潔、穩定。具體如下所示：

在項目開發中，如果產品需求發生變化（這種可能性是很大的，但是一般來說，都會將需求變化放到下一版本中），那麼在修改PRD的時候，也應該就修改PRD內容進行必要的確認。

NO.4 PRD的模板

很多公司應該都會有PRD模板，供產品經理參考。但我感覺，根據具體項目與產品功能需求的不同，產品經理是需要根據靈活情況進行修改的。比如，我們的產品經理在撰寫PRD時，主要是圍繞用戶界面與功能描述展開的，很簡潔，沒有用到用例，但是以圖文並茂的形式把產品功能介紹的很清楚了。

尹劍利,微信公眾號@尹劍利(yinjianli88)。人人都是產品經理網站專欄作家，研究生在讀,曾創業兩次,有過多家知名上市公司的實習經歷。熱愛人文歷史,痴迷互聯網。希望遇到志同道合的朋友多多交流。

http://weixin.qq.com/r/Djnbw3bEjivxrTKg92wc (二維碼自動識別)

大部分產品經理寫的是 Word 形式的 PRD，也有一部分是一份 Axure 的文檔。這個主要看公司或個人偏好甚至也跟你自己負責的產品形態有關。

我自己曾用過 Keynote 來寫 PRD，主要是宣講的時候很方便，但文本編輯的能力比較差。對於當時負責的產品（不那麼複雜）來說，也是夠用的。

前段時間用 Notion（書寫工具）來寫，相對 Word、Pages 而言確實更加高效。

但多年經驗下來，我個人發現傳統形式 PRD 弊端非常大：

撰寫過程的痛苦
閱讀者的痛苦
一個人的戰場（基本就我一個人去維護一份幾十頁的 PRD）
實時更新同時保證所有人in the loop的成本
開發過程中，調整需求，更新 PRD 的繁瑣
多期產品，上下文的缺失或信息的冗餘

最近嘗試用「看板」工具來完成 PRD，感覺相當實用，解決了之前很多的問題。

配圖為敏捷開發中，看板的經典模板

這個 idea 靈感主要來源於「敏捷開發-Scrum」，Scrum 的經典工具就是「看板工具」。實踐了一段時間，感覺這個方式較之傳統方法，其優勢主要是以下幾點：

1、從框架到細節，從 UC 到 Feature

框架，即整個產品的骨架。看板的設計即映射這一份骨架
細節，則是每一個「任務」對應的功能的具體描述。

2、利用分組來分期

保證上下文完整
過程可追溯

截圖來源我自己使用的工具，#Teambition

3、團隊協作，不再是傳說

多名產品經理或產品設計師，可共同完善功能列表及描述
團隊成員隨時補充遺漏的板塊，並指派給產品經理完善
針對功能的困惑也可通過評論的方式進行短暫的討論和問答

4、閱讀者的安全感與邏輯性

當期項目範圍及優先順序一目了然
zoom in 看單個 feature 的細節邏輯；zoom out 看整個產品的思路和布局

5、獲取更新信息簡單方便

最近有更新的feature 在看板中一目了然
更新內容也第一時間通知到每一位相關人

6、根據開發情況更新 PRD，不再痛苦

點對點的針對單個 feature 更新，不影響其他功能
無法完成的feature，直接移到二期，保證項目範圍的準確與實時

當然，更不用擔心存檔問題。只需將整個項目導出（Markdown 格式），然後上傳公司 wiki存檔。就可以了。

而看板工具，不管是國內還是國外的都非常多，且大多免費的版本就足夠使用。

PRD（Product-Requirement-Document，產品需求文檔），這對於任何一個產品經理來說都不會陌生的一個文檔，在網上搜索也很容易找到關於PRD的乾貨，但會寫還是不夠，很多產品新人都問我為什麼我的文檔開發哥都不看？怎樣才能寫好PRD呢？

Ruby語言的創始者松本行弘說過：「代碼越少，有可能出現bug的機會也越少。」文檔也是一樣，越是簡短，可能出現的錯誤也會越少，同時也更利於閱讀、維護和更新，所以建議大家的PRD要寫成「簡單易懂」。

產品需求文檔作為一種和開發人員溝通的重要工具，如果梳理得不好，會直接影響後續與開發人員的溝通質量，「簡單易懂」顯得十分重要。但很多剛做產品的同學不太了解其重要性，會走不少彎路，他們會發現：在開完需求會議後開發人員在開發的過程中很少去翻看需求文檔，通常情況下都是口頭詢問，同學們就覺得很奇怪，他們寫文檔寫得那麼詳細，為什麼開發人員就不看文檔呢？既然不看，就不用寫了，直接用口頭溝通不是更好嗎？其實，能用口頭闡述都小問題和小項目，如果是中、大型項目，參與人員比較多，文檔是有助於減低溝通成本和提高共走效率；還有一點，很多時候開發不看文檔，是嫌棄文檔的內容太長了，他們只需要簡單了解這個功能大概是做什麼的，怎樣去實現就可以了。反觀很多同學在寫的時候會進入一個誤區，事無巨細地描述規則，總害怕開發同事看不懂，一個比較複雜的功能可能寫個300字，結果人家直接不看了。

怎樣才能寫出簡單易懂的需求文檔呢？

1、分析核心需求

明確開發需求實現哪些功能需求，PRD很多時候只是對原型上沒有的說明進行補充，你總不能輸入框限制多少個字元都寫在原型上面，所以第一步需要看一下哪些是說明並沒有在原型上面提現，然後在PRD上面進行補充。例如，原型上面更多的是交互說明與規則說明，但對欄位的控制一般都很少去解釋，還有時候原型上很難包含所有情況頁面，所以PRD也有時候需要補充一下。

2、先填寫軀幹

為保持簡短性，需求描述主要寫成，提取關鍵詞，關鍵詞字數不要超過6個字，這樣可以讓開發哥最快的速度以內了解功能點；最好使用約定俗成的語言，因為產品與開發部在有些點上面的描述和說法是不一樣的，如果使用大家能馬上看得懂的言語就能提高效率，這個需要平時的積累和溝通的沉澱，最好每次項目結束總結範例，那下次開展項目可以更快更速度。

3、再增加枝葉

寫完關鍵詞後，圍繞關鍵詞展示具體內容，內容長度最好不要超過20個字，還把需要顯示的具體內容放入了解釋中，因為這些內容並不會影響開發，如果放在需求描述中，反而會降低閱讀的速度和增加理解上的負擔。

就前三點舉個例子：我曾經做過一個功能消息待閱讀，一級軀幹為欠費提醒、賬單提醒、生日提醒，二級枝葉為欠費提醒中對象、內容、時間等元素，最後對元素進行描述。

4、備註說明

在備註的加入需求來源、需求提出時間、需求提出人，避免出現產品開發完成後，由於開發周期太長，很多需求來源都淡忘了，無法得知為什麼當初有這樣的功能和需求，為什麼增加這個欄位，如果遇到項目需求確認人或者開發人員離開了，同時文檔中沒有留下任何確認過的需求來源記錄，在產品上線驗收的時候，需求出現了問題，那麻煩就大了，其實文檔也是保護雙方的一種手段。

5、時刻維護

文檔還需要保持時刻更新，因為在產品開發階段，會遇到零零散散的提升用戶體現或者修改功能需求，如果是到了最後上線期間才去補很容易產生遺漏，這裡也推薦避免3個遺漏的方法：

1、一定要及時把變更的需求寫入需求文檔中，不要拖到下次在寫

2、用高亮的顏色標記出變更的細節，如需要顯示的欄位內容

3、對於做了刪改的需求要標明原因以及時間

4、如果中途修改次數過多，建議專門做個文檔來記錄變動情況

6、項目總結

每經過一次項目，總結是必不可少的，在PRD方面也需要總結，在總結大會上需要收集開發對此項目PRD的意見和修改方向，如何才能更清晰簡單地闡述我們的觀點，「簡單易懂」不單單是產品部為這個目標奮鬥，開發的同事也應該參與其中，這個在下一個項目開發中才能取得更大的進步。

如果需要與我討論和合作的話，可以掃一掃下面的二維碼。

首先題主應該了解prd文檔的用戶群體，以及他的作用。

PRD文檔主要是面向程序員的，讓他們能夠清楚的了解軟體的各個功能，。其實沒有特定的形式，你可以跟你的開發朋友們談談看看他們更喜歡哪種。提高效率和達到目的才是王道，不要尋求特定的答案，找到適合的，就是最正確的。

贊