作為一個產品新人，入職之后，首先就要開始撰寫各種文檔。而在我看來，其中最重要的非產品需求文檔莫屬。產品需求文檔的英文名稱為：product requirement document，簡稱PRD。該文檔是將一個產品由抽象到具體最重要的步驟之一，也是讓技術人員詳細了解一個產品的【三部曲】之一，其他兩步分別是產品原型和語言溝通。而PRD也是令很多產品新人比較頭疼的東西，那么PRD到底該怎么寫？下面筆者就結合了一些文章和自己的經驗給大家講解一下，新手如何制作需求文檔。
要明白寫文檔的直接目的！
首先我們要明白，我們的文檔是給哪些人看的，一般PRD大約會給以下這三類人看：技術人員、公司BOSS以及客戶。
而本文以目標用戶為技術人員為例簡述需求文檔如何制作。
即然目標人群已經明確，那么將PRD交給技術人員最直接的目的是什么？那就是讓技術人員看完PRD之后，便會知道你的產品具體是一個什么樣子有那些技術功能需求。一個好的PRD會有什么樣的效果？那就是技術人員只有你的PRD，沒有原型，不經過語言溝通，他做出來的東西依然是你心中理想的樣子。
我該寫什么？
接下來進入主題，首先，我們需要列出需要的功能模塊，而每個功能模塊都需要包含：項目概述、需求說明和階段規劃三部分，
項目概述：顧名思義，就是要做到看完之后讓人大概對這個產品有一個初步的了解，并且心中對產品有一個雛形。那么目的明確了，怎么去實現：首先說明使用人群，使用人群明確之后，才好針對他們的需求，去設計和開發功能，也就是用戶需求，而用戶需求往往都是多而雜的，需要對其分類之后，再詳細描述
對于技術來說，無關開發的內容技術是不會去看的。什么是無關開發的內容？我曾見過的有：市場調研、競品分析、用戶研究、產品價值觀、以及上圖的開發風險分析，以上內容基本都可以單獨拿出來做為一個獨立的文檔去寫，不要一廂情愿的認為技術人員會去看這些內容，技術的明確答復就是：我！不！看！
需求說明：具體說明這個需求如何實現、怎么操作以及相關的操作流程等
基本上寫完以上內容，你的需求文檔就已經成型了；如果技術人員看完之后還不知道要去做什么，那只能說明你的PRD不合格。但是真的不合格該怎么辦？你需要做的不是去改，畢竟連寫都寫不好，你又能改成什么樣子？你現在所需要的是補救！那么怎么去補救？你需要去寫一個階段規劃，如下圖：
階段規劃
所謂的階段規劃就是：將一個產品的開發過程一步一步的分解開，詳細的說明技術人員在接下來的這段時間具體要做些什么，如果用文字描述不清，那就借助工具：比如說大家用的最多的流程圖，你需要在圖中把你的產品邏輯順序畫清楚，既要簡潔，又要全面，這并不矛盾。除了流程圖，你也可以用N-S圖，PAD圖以及E-R圖等，你要記住，用工具不是目的，目的是用工具去解決問題。基本上階段規劃寫完之后，PRD就可以結稿了，接下要做的事情就是隨著需求的變更而不斷的去修改內容了。
本文到這里就即將結尾，如果閱讀本文之后，你還是無法寫出令技術人員滿意的文檔，導致技術人員無法理解你的意圖，那么不要擔心，請等待我下一篇文章的發表，在下一篇文章里，我會去教你們：如何用Axure中最簡單的功能去制作一個另人滿意的產品原型。
