作為一個產(chǎn)品新人，入職之后，首先就要開始撰寫各種文檔。而在我看來，其中最重要的非產(chǎn)品需求文檔莫屬。產(chǎn)品需求文檔的英文名稱為：product requirement document，簡稱PRD。該文檔是將一個產(chǎn)品由抽象到具體最重要的步驟之一，也是讓技術人員詳細了解一個產(chǎn)品的【三部曲】之一，其他兩步分別是產(chǎn)品原型和語言溝通，會在接下來的兩篇文章中細說。而PRD也是令很多產(chǎn)品新人比較頭疼的東西，那么PRD到底該怎么寫？

要明白寫文檔的直接目的！

一般PRD大約會給以下這三類人看：技術人員，公司BOSS以及客戶，而本文以及接下來的兩篇文章所說的內(nèi)容目標用戶均是【技術人員】。

即然目標人群已經(jīng)明確，那么將PRD交給技術人員最直接的目的是什么？那就是讓技術人員看完PRD之后，便會知道你的產(chǎn)品具體是一個什么樣子。一個好的PRD會有什么樣的效果？那就是技術人員只有你的PRD，沒有原型，不經(jīng)過語言溝通，他做出來的東西依然是你心中理想的樣子。

我該寫什么？

上圖便是我為了寫這篇文章特意寫的一個PRD，是一款快速原型設計軟件的PRD，類似于Axure的手機版。我個人偏愛用Axure去寫文檔，這樣可以把產(chǎn)品原型直接嵌套進去，更加方便和直觀，而且個人推薦用Axure去寫PRD。當然，工具只是輔助性的，文檔好壞看的還是內(nèi)容，大神用word同樣可以將文檔寫的栩栩如生。

接下來進入主題：首先看右側內(nèi)容，你們只需看一點，就是【文檔的版本】：一個文檔誕生之后，肯定是要經(jīng)歷不斷修改的過程，那么修改之后，為了讓他人清楚的知道你修改的內(nèi)容，你就需要更新你的版本號，并寫好日期與修改的內(nèi)容。

然后看左側的列表，也就是目錄，只有三條，因為我喜歡三這個數(shù)字，既簡約而又不簡單，使人看起來一目了然。每條都有四個字，因為我有點輕微強迫癥，如果不對齊就會渾身難受，而且用過五筆的都知道，無論是兩字詞組還是四字成語，都只需要敲擊四下鍵盤就能輸入。

列表的三條分別是：【項目概述】、【需求評估】和【階段規(guī)劃】，可能會有人說：為什么這么少？能問出這點的人們，首先你們需要先明確我們寫文檔的目的：只要能讓技術人員完全了解一個產(chǎn)品的樣子，哪怕是你只寫一條也不會有人說你。下面我們舉個反例。

上圖是在百度找的需求文檔，我以一個技術人員的角度去看這個文檔，看完前六條之后，我甚至不知道我要去做的是什么東西，那么它錯在哪？

1. 不能快速進入主題。
2. 無關開發(fā)的內(nèi)容太多。

那什么是【無關開發(fā)】的內(nèi)容？我曾見過的有：市場調(diào)研、競品分析、用戶研究、產(chǎn)品價值觀、以及上圖的開發(fā)風險分析，以上內(nèi)容基本都可以單獨拿出來做為一個獨立的文檔去寫，不要一廂情愿的認為技術人員會去看這些內(nèi)容，我只想說：我！不！看！

我該怎么寫？

知道了寫什么之后，我們再談談怎么寫：

由于以前是搞安卓開發(fā)的，我對tablehost和viewpager情有獨鐘，于是就仿照做了一個Tab分頁，如上圖。

項目概述，顧名思義，就是要做到看完之后讓人大概對這個產(chǎn)品有一個初步的了解，并且心中對產(chǎn)品有一個雛形。那么目的明確了，怎么去實現(xiàn)：首先說明使用人群，使用人群明確之后，才好針對他們的需求，去設計和開發(fā)功能，也就是用戶需求，而用戶需求往往都是多而雜的，需要對其分類之后，再詳細描述，如下圖：

用戶需求大致可以分為以下三點來分類說明：基本需求、期望需求和興奮需求。

• 基本需求，便是我們產(chǎn)品初級開發(fā)階段要去滿足的內(nèi)容，也是用戶使用你產(chǎn)品的必要不充分條件。
• 期望需求，便是在基本功能可以實現(xiàn)的基礎之上，用戶希望你去添加的功能，也是開發(fā)中后期以及運營前期我們?nèi)ヒ獙崿F(xiàn)的功能。
• 興奮需求，便是用戶沒有想到，但是你不但做到了，而且用戶很需要，用戶使用之后會感到興奮，甚至推薦給他人使用。也是運營中后期要去做的事情。

但是在我過去開發(fā)經(jīng)歷中，并沒見到過什么另人眼前一亮的功能，這不得不算是一種遺憾，甚至有的時候PRD只看了開頭，便已經(jīng)猜到了結尾，這不得不說是業(yè)內(nèi)互相模仿的悲哀。

項目概述寫完之后，大概功能就已經(jīng)了然于心，那么我們就需要將它具體化，而實現(xiàn)這一目的最好的方式就是需求評估，如下圖：

圖中我只列舉了四個例子，當然實際開發(fā)中要實現(xiàn)的功能遠遠不只這些。這個表格有三列，分別是：需求等級、功能名稱和功能簡介。

我只說一下需求等級：生活中無論做什么事情，先后順序都是按輕重緩急去分的，開發(fā)亦是同理，所以你需要給產(chǎn)品的功能加上需求等級，讓技術人員清楚的知道開發(fā)的優(yōu)先級。做完這步之后，你就需要詳細的描述每一個功能，如圖中左側的畫圖功能和跳轉事件，這個我就不放圖了，大家根據(jù)具體情況去寫就可以了。

基本上寫完以上內(nèi)容，你的需求文檔就已經(jīng)成型了；如果技術人員看完之后還不知道要去做什么，那只能說明你的PRD不合格。但是真的不合格該怎么辦？你需要做的不是去改，畢竟連寫都寫不好，你又能改成什么樣子？你現(xiàn)在所需要的是補救！那么怎么去補救？你需要去寫一個階段規(guī)劃，如下圖：

所謂的階段規(guī)劃就是：將一個產(chǎn)品的開發(fā)過程一步一步的分解開，詳細的說明技術人員在接下來的這段時間具體要做些什么，如果用文字描述不清，那就借助工具：比如說大家用的最多的流程圖，你需要在圖中把你的產(chǎn)品邏輯順序畫清楚，既要簡潔，又要全面，這并不矛盾。除了流程圖，你也可以用N-S圖，PAD圖以及E-R圖等，你要記住，用工具不是目的，目的是用工具去解決問題?；旧想A段規(guī)劃寫完之后，PRD就可以結稿了，接下要做的事情就是隨著需求的變更而不斷的去修改內(nèi)容了。

本文到這里就即將結尾，如果閱讀本文之后，你還是無法寫出令技術人員滿意的文檔，導致技術人員無法理解你的意圖，那么不要擔心，請等待我下一篇文章的發(fā)表，在下一篇文章里，我會去教你們：如何用Axure中最簡單的功能去制作一個另人滿意的產(chǎn)品原型。

本文由 @Moxlis 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉載。