欲練此功，必先自宮。

本系列文章的宗旨是讓大家從源頭上理解PRD每個章節的內容，對內容的表達可以創新，但萬變不離其宗。?enjoy~

寫PRD時，你是否曾經做過以下的事：

• 從公司研發規范文檔中下載模版，進行內容填寫；
• 當不了解章節的內容時，直接寫略或者刪掉；
• 在網上找到相似產品的PRD，對文章內容進行替換。

前幾年我所在公司剛轉型的時候，PRD管理比較混亂，很多產品經理常常使用上一個迭代，或者其它產品團隊的PRD模版。把其中的內容進行替換，自作主張的刪減，嚴重者只剩下“產品功能”這一部分。導致了很多需求要么沒有可讀性，要么又臭又長，甚至需求遺失，團隊溝通成本極高，項目延期率居高不下。

這與其說是產品的偷懶行為，不如說是對PRD的理解不夠，不得其法。

PRD的定位

我們知道，PRD是MRD的技術量化版，可以指導產品實現，是承上啟下的重要文檔。因此在產品實現過程中，PRD的重要性不言而喻。因此好的PRD文檔，無論格式和內容如何演變，一體式也好，word也好，以下兩個問題必定是明確的：

• 在產品實現過程中，誰會看這個PRD；
• PRD是否具備所有讀者需要的內容。

所以，PRD的內容需要根據產品形態，項目組織形式等情況，做相應的調整。通常情況下，讀者包含但不僅限于以下角色：產品總監、研發、UI、測試、相關產品團隊（含硬件團隊）、運營、客服。

PRD的結構

互聯網敏捷團隊，輕文檔，重過程，對PRD形式沒有特殊要求，最重要的是要合適你的團隊，大公司的模版不一定適用小公司，小公司模版也不一定適合大公司。有得的隊研發強，有的團隊測試強，有的團隊運維強，PRD要有所側重；有得團隊經過長期磨合，一個眼神，就知道你的隱性需求，PRD當然可以不寫，但是你給別的團隊用，可能要解釋半天甚至返工。在團隊磨合過程中，要形成恰當的PRD，需要對PRD的理解上有了一定的功底，才能寫出最合適的PRD。

因此，本系列文章的宗旨是讓大家從源頭上理解PRD每個章節的內容，對內容的表達可以創新，但萬變不離其宗。

整體概覽如下，后面會對每個章節分解說明：

基本結構

先從簡單的說起，很多只重視“產品功能”的描述，對其它信息不重視，這是一種誤區，特別是文檔本身的基本信息。當文檔涉及到跨項目，跨部門，跨公司，跨集團時，這些內容是很重要的。

封面

這部分是需求的門面，一定程度上可以展示公司和團隊形象。

• 公司信息：包含但不僅限于logo，名稱，傳真等，一方面提升公司形象，一方面便于聯系
• 保密級別：公開，普通，機密，絕密等，在一些游戲產品或涉及公司重大戰略的產品，保密很重要。這同時也是一種免責聲明。
• 文檔名稱：xx項目/產品 PRD，我見到不止一次，A項目的文檔寫著B項目的文檔名稱。
• 文檔編號：如果公司有要求則按公司要求，無要求則根據產品體系自行填寫，文件名最好帶上文檔編號。
• 文檔編寫人：編寫人信息，包含部門， 姓名等，代表的是一種責任。
• 編寫時間：一般為重要文檔版本對外發布時間。

版本信息

又叫修改控制紀錄，這部分就像軟件的更新說明一樣，表明文檔與上個版本有什么區別。

• 日期：版本的修改時間；
• 版本：文檔版本號，結構與產品版本號類似；
• 版本描述：修訂xx章節，新增xx章節，刪除xx內容，讓讀者對文檔變更內容有個大致了解；
• 版本作者：該版本的編寫人，便于溝通；
• 審核人、批準人：根據實際項目變更委員會的組成情況，確定是否需要。

編制說明

一般情況下PRD文檔都省略或合并了這個部分。我曾經參與過一個國家級的項目，當時由多個公司，n多專家共同編寫，歷時幾個月，產品文檔共有10個分冊，十本紙質的加起來將近有30公分厚。編制說明用于說明文檔編制的情況，互聯網提倡小而美，快速落地mvp，不會有那么大的需求，所以大家會在背景或概要描述時順便提一句。

• 編制來源：描述因何進行編寫文檔。如：因什么政策，有xx公司牽頭，xx公司參與，以什么為目標，展開本次工作。
• 編制過程：描述文檔編制的過程。如：x日成立工作組，x日組織了研討，x日組織專家分析，x日正式啟動編寫。
• 文檔體系結構：用于描述本項目或產品涉及所有文檔，如：xx綜述分冊，xx業務模型分冊，xx需求規格分冊，xx數據模型分冊等。
• 編制說明：用于描述當前文檔的定位和邊界，如：本文檔負責是承接并敘述xx相關成果內容，起草單位：xxx。

目錄和正文

目錄：在修訂文檔后，更新域即可。一般情況下用不到目錄，定位段落的時候用文檔結構圖比較方便。但是如果需要打印成紙質的項目，目錄就必不可少了。

正文：PRD的主體。一般包含引言，概述，功能需求，非功能需求，環境。PRD的功力深淺，就在這體現了。

引言

引言即文檔開頭，是PRD正文部分的開始部分。

其作用是提供輔助讀者深入理解整個文檔所需的其它相關信息

背景

描述所說明的軟件的應用，盡可能精確地描述所有相關的利益干系人。

• 軟件／產品名稱：待開發軟件/產品名稱；
• 提出者、開發者、用戶：明確產品干系人；
• 例子：xx產品，是由xxx與xxx合作項目，由xxx提出，由xxx承擔開發人物，目前用戶為xx項目的車主。

參考資料

列出有關資料的名稱、文件編號、發表日期、出版單位、作者等，并說明參考文件的來源。

包含但不僅限于：

• 經過核準的任務計劃書
• 上級機關批文
• 項目相關的合同
• 本項目其它已發表的文件，如：MRD、原型
• 文中引用的其它文件、研發規范等

術語

列出本文件中用到的專業術語的定義和縮略語對照，便于理解，適用于接觸新業務領域的團隊。

概述

如果說引言是幫助讀者理解文檔，那么概述則是幫助讀者理解項目和產品本身。

項目／產品描述

敘述該項軟件／產品應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發的背景材料。

• 應用目標：可以理解為產品要解決什么問題，如：針對xx狀態下，無法進行xxx的情況，使xx產品可以通過xxx完成對xxx的工作開展。
• 范圍：明確產品邊界，說明產品將干什么，不干什么。
• 開發背景：為何要開發這個產品，一般情況下根據團隊理解程度，節選BRD、MRD相關調研背景資料。

建議平時多與團隊溝通探討，不要把評審當做一種宣貫。

系統模型

用于幫助讀者理解系統整體結構，常用于向上匯報，幫助理解系統整體運作。

（1）系統總體結構圖

產品涉及的系統整體所處環境分解關系、各層次作用以及數據傳遞關系，便于理解各系統之間如何配合工作，各自邊界是什么。

（2）網絡拓撲結構圖

系統所處的網絡環境，用于理解各系統部署情況。幫助讀者理解集群，負載，網絡安全等相關信息，便于產品設計和相關決策。

這部分要求產品需要具備一定的技術能力。

假設和約束

指的是產品在實現過程中，必須滿足的假設條件和所受的限制。這部分是被大家刪減最多的部分。

（1）約束

這個比較好理解，就是影響產品的一些限制，比如：

• 必須兼容的相關系統或硬件
• 必須使用的語言，技術，或者通信協議，如java，dubbo，nginx，灰度，xmpp
• 必須控制的成本，安全要求，保密要求。
• 必須滿足的完成時間，比如xx節日之前。

（2）假設

總有一些因素，不是產品的約束，但它們的改變可能影響到需求，比如：

• 最終獲取的經費預算滿足xx條件
• 某某技術的成熟度滿足xx條件
• 公司xx資源滿足xx條件
• 市場部或運營部具有xx能力

常見的運營需求也算是一種對運營的假設行為，此部分一方面有助于理解產品所需的資源，便于推進相關任務的進行，另一方面便于研發人員思考相關約束，減少后期返工和修改。

相關閱讀

PRD修煉真經?卷一：一份標準化產品需求文檔的邏輯思路

PRD修煉真經?卷二：一份標準化產品需求文檔的邏輯思路

PRD修煉真經?卷三：一份標準化產品需求文檔的邏輯思路

作者：小星星，8年互聯網工作經驗，5年技術，3年產品。

本文由 @小星星 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議