手把手教你寫 Word 版本PRD

2、由於產品經理經常會變更需求，經常愛拍腦袋，容易變卦，所以程式設計師就想到用一個文件來約束產品經理。

3、測試人員需要根據產品需求文件來驗收產品質量。

4、當你的專案有新人進入的時候，可以讓新人更快的瞭解產品。當你離職的時候，繼任的產品經理也可以根據你的文件來熟悉產品迭代的內容。

5、有利於你裝逼。你面試的時候拿著一份寫的很規範的PRD文件，面試官會覺得你碉堡的。

1、文件產品名稱

寫個需求文件，你得告訴人家是什麼吧，尤其在公司有很多文件的情況下，什麼BRD、MRD，你不給人家說明，人家知道你發的什麼鬼。一般來說文件產品名稱可以這樣寫。

這裡面有幾點是必須要寫的。

• 文件的狀態是草稿？正式釋出？正在修改？

• 當前版本是多少，尤其是你版本修改很多的情況下。

• 文件密級分為普通、機密、絕密，比如你寫的使用手冊就是普通，你的產品沒有上線前寫的文件屬於機密，絕密一般情況下遇不到，比如銀行專案，國家級專案，就是絕密。

2、版本歷史

產品經理也不是神，難免會犯錯，所以寫的文件難免會更改，這個時候文件修訂記錄就起作用了。

首先是變更的版本，然後是修訂日期、原因與修改情況描述、修訂人。

這裡的3.2.5是大綱欄目，這樣的好處是你修改那一條，人家直接去根據欄目定位到你修改的那一條，作為產品經理，也要注重一下使用者體驗，同時修改的部分需要高亮顯示，用不同顏色字型標出來，這樣別人找的時候容易找。

3、目錄

目錄就不用說了，寫文章有文章目錄，寫文件有文件目錄，一般word【引用-插入目錄】都有。

4、文件介紹

主要介紹文件的目的、文件面向的主要使用者，讀者物件、參考文獻、術語與縮寫解釋等

5、產品概述

從大的方向，講講專案的相關背景，有什麼目標、有沒有競品物件？階段性計劃是什麼，傳遞做這個需求的目的是什麼？要達到什麼樣的目標？讓專案開發人員對你的專案背景有了解，程式設計師知道的越多，做起專案來越有方向性。

如果業務比較複雜，最好用業務流程圖來解釋一下，比如p2p的業務流程圖，名字可以命名為業務流程。

6、產品需求

也就是功能清單，feature list，系統模組比如你有APP端、微信端、業務控臺端。

比如這樣的一個頁面，一級選單是首頁、二級選單顯示首頁上有那些模組，有註冊入口、廣告banner、投資人數、黃金體驗標、XX寶，然後黃金體驗標、XX寶是可以點進去的，這個時候就是三級選單。

7、產品結構圖

這個也稱作腦圖，用xmind或者mindmanger來畫。

1、頻道：某一個同性質的功能或內容的共同載體，也可稱為功能或內容的類別。比如首頁、理財也、我的這樣一些

2、子頻道：某頻道下細分的另一類別，比如理財頁不同子頻道之間的切換。

3、頁面：單個或附屬某個頻道或分類下的介面，點選進入詳情介面。

4、模組：頁面中多個元素組成的一個區域內容，可以有一個或多個，也可以迴圈出現(例如:文章列表)。

5、模組元素：模組中的元素內容，以理財為例，有產品詳情、資訊披露這些。

當然如果你想往下寫可以接著往下寫，感興趣的同學可以寫寫通知中心、個人中心這些。

8、全域性功能說明

UI設計會出一個UI設計規範，當然我們做產品的也會對產品中經常需要對一些公共情況做說明，可以做一個全域性說明。

• 8.1 打斷後重新開啟App

• 8.2 點選空白區域或無網路情況

對於比較耗流量的APP來說需要，比如淘寶瀏覽商品大圖的時候比較消耗流量。

• 8.3 頁面內互動

說明：

選擇類提示框均用系統自帶的提示框，操作按鈕“確定”在右，“取消”在左。

Toast、Alert控制元件顯示效果：淡入淡出

• 8.4 鍵盤型別說明

點選（密碼、郵箱、驗證碼）輸入框時，彈出字母鍵盤

點選（手機號）輸入框時，彈出數字鍵盤。

• 8.5 頁面間互動

9、產品詳細功能說明

一般用用例表來進行說明，以登入註冊模組為例，有流程圖的話，先把任務流程圖畫出來，然後是用例表，用例表包含簡要說明、行為者、前置條件、後置條件、功能說明、備註。功能說明一定要排版簡潔、層次清晰，功能說明無遺漏。

10、非功能性需求

非功能性需求主要包含效能需求、適配需求、環境需求、統計需求、預留介面等，以下圖為例：

11、相關文件

如果一個專案分解成多個團隊。多個需求文件協同合作。如一個UGC社群，有PC端社群，有APP端社群。這需要不同的研發團隊，Web前端、APP又分為安卓、iOS。所以需求文件會拆分為PC端需求文件和APP端需求文件。

12、上線需求

設計什麼時候OK、什麼時候測試，具體的上線時間，具體一些特殊的流程需求等。

有些人總是迷信所謂的標準文件，其實沒有所謂的標準文件，只要你能把你的需求講明白，提高效率，能使產品儘快上線，儘快搶佔市場，那麼你的產品文件就是標準的。