欲練此功，必先自宮。
本系列文章的宗旨是讓大家從源頭上理解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能力
常見的運營需求也算是一種對運營的假設行為，此部分一方面有助於理解產品所需的資源，便於推進相關任務的進行，另一方面便於研發人員思考相關約束，減少後期返工和修改。
【未完待續】
題圖來自 Unsplash，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
