市場、運營或用戶反饋，我們需要這樣，需要那樣的產品改進或產品設計。需求審核也已經通過了。然后產品經理理完思路，進行流程設計，產品設計也隨之做好了。一臉蒙蔽，這些產品設計和設計的細節全部在產品經理的腦海里呀，怎么辦？總不能天天跑到技術哪里，我需要技術實現這樣的產品需求，需要實現那樣的設計效果，每天口頭一遍一遍的交流吧？嗯？作為產品，有這樣的需求或則有這樣的疑惑。對頭，PRD就是為這樣的需求或則這樣的疑惑而生的。PRD的作用就是，把需求白字黑字外加圖像的生動明確的表示出啦，便于技術開發；便于需求更改，便于需求記錄；便于需求溝通……等等。有了PRD,需求溝通時的撕逼大大減少。

如果市場分析、用戶研究、用戶需求分析是用戶、市場告訴我們需要什么的產品，那么PRD文檔就是把產品需求告知給技術實現的直接方式。PRD是這樣的存在：

避免出下如下圖的悲劇，保證產品人員的人身安全。我們有必要認真好好探究探究，PRD應該怎么樣寫？怎么樣才能寫出一份合格的需求文檔。

一份合格的需求文檔應該包含這些內容。

一、PRD文檔頭

文檔名稱、作者或則撰寫人、文檔編寫日期、版本紀錄、目錄。

寫個需求文檔，你的告訴人家這是什么吧？這是什么文檔，不然人家技術還以為你是給人家發的什么少兒不宜的文檔呢。有了文檔名稱的告訴人家是誰寫的吧。人家要拿顯示器砸你應該找到人對號入座，不然會殃及無辜的。文檔日期也寫上，不然人家技術會認為，這需求已經是去年提的需求了。沒有版本紀錄，鬼知道你這是第幾版。目錄，清晰的記錄文檔的脈絡結構，讓人知道怎么去讀你的PRD文檔。合格的文檔頭，應該長這個樣子的

OK有了一個漂亮的文檔頭，那下來就到文檔里面內容的填充咯。

二、PRD文檔內容結構

PRD文檔內容結構包括：概述、產品需求說明、產品流程說明、產品結構和功能說明、其他產品需求、上線需求說明。如果需要的話有相關文檔，附件說明。

1、概述

從大的方向，講講項目的相關背景、有什么目標、有沒有競品對像？而階段性計劃是什么？傳遞做這個需求的目的是什么？要達到什么樣的目標？要達到這個目標階段性計劃是什么？

2、產品需求

落到具體的地方，產品有哪些需求？增加了哪些需求？調整了什么？取消了什么？需不需要其他資源的配合？有什么影響？，從這幾個地方說清楚。

3、產品流程說明

講清楚每個邏輯點，每個地方應該怎么走？應該做什么樣的判斷？如果進行這個操作返回給用戶什么內容？用戶觸發之后得到什么內容？

常見的流程圖：

泳道圖：

4、產品結構說明

根據產品的內在邏輯，分解、細化需求，將需求細化說明。針對內在的需求邏輯，考慮到那個需求不同情況的不同反饋，邏輯嚴密，考慮到每個邏輯分支。如果有和其他產品關聯，考慮到對其他產品的影響。在描述的時候，不要用戶含糊的詞語，“可能”、“也許”之類的詞語。如果無法biao表述清楚，可以舉個例子說明。

例如：

必要的時候添加用例說明：

舉例：

5、其他產品需求

涉及到其他產品的產品線時，需要協同多個產品線進行多方面考慮。協同調整，避免出現遺漏，出現不必要的偏差。

6、相關文檔

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

7、上線需求

測試通過的需求，具體的上線時間，具體一些特殊的流程需求等。

8、其他需求、附件

作為需求的一種補充，對一些需求進行補充說明，或者需要的文件說明等。

結語

OK這樣一個文檔下來，需求明確了，如果要改需求也是有版本紀錄，有方向的改進了。不然，作為個產品經理你時不時跑到，跑到技術那邊說一嘴，哎呀，哎呀，這個需求不是這樣的呀，你做錯了，重新改。技術保證打不死你，人家辛辛苦苦做出來，然后你所不是這樣。送你大大的一個白眼。寫好PRD，真愛生命，遠離撕逼。最后，豌俠所說的都是沒用的，大家自行體會。

作者：豌俠說(微信號：wanxiashuo)

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