[[156712]]

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

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

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

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

我該寫什么？

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

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

然后看左側(cè)的列表，也就是目錄，只有三條，因?yàn)槲蚁矚g三這個(gè)數(shù)字，既簡約而又不簡單，使人看起來一目了然。每條都有四個(gè)字，因?yàn)槲矣悬c(diǎn)輕微強(qiáng)迫癥，如果不對齊就會(huì)渾身難受，而且用過五筆的都知道，無論是兩字詞組還是四字成語，都只需要敲擊四下鍵盤就能輸入。

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

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

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

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

我該怎么寫？

知道了寫什么之后，我們再談?wù)勗趺磳懀?/p>

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

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

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

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

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

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

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

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

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

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

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