本文想說的事情是，那個(gè)叫PRD文檔的家伙只是個(gè)稱呼而已，PRD的問題不在于如何寫而在于如何被傳遞與執(zhí)行。這里簡單介紹一下我基于axure rp的一種新的PRD寫法。（友情提醒：從來不用axure，認(rèn)為他笨重?zé)o比的人請路過。）
從半只腳邁入產(chǎn)品經(jīng)理這個(gè)大門的那天起我就被2個(gè)文檔的名稱深深的糾纏著，他們是市場需求文檔（MRD）、產(chǎn)品需求文檔（PRD）。先不論你是什么方向的PM，這2個(gè)玩意一定會(huì)一直伴隨你的Title跟著你。這2個(gè)文檔在不同的團(tuán)隊(duì)中有不同的叫法和寫法，我也見過有團(tuán)隊(duì)的MRD其實(shí)就是PRD，不沾半點(diǎn)商業(yè)市場分析的邊的，當(dāng)然，這些不是本文探討的內(nèi)容。
長久以來，有個(gè)很有趣的現(xiàn)象：“有沒有PRD模板，PRD該咋寫”這個(gè)問題已經(jīng)成為新手入門經(jīng)典必問題目之一；如果1年以后這個(gè)家伙還在這行里混，他一定會(huì)抱怨，娘滴，我們的QA壓根就不看我的文檔、我們的交互（如果有這個(gè)職位的話）還是會(huì)問我一些我寫的很明白的問題、我們的測試拿著文檔問我該咋測試、……
Web頁面之間的關(guān)系是網(wǎng)狀的，而Word文檔只能樹狀的表述，這無疑是矛盾的；PRD文檔無法做到實(shí)時(shí)更新發(fā)布，我回顧了我第一年寫的PRD文檔，很多下面的修改欄都是空的，慚愧之至……；所謂一圖勝千言，萬言剛夠文檔標(biāo)準(zhǔn)，每個(gè)PRD都是臭長臭長的，這樣的東西別說交互設(shè)計(jì)師了，很多PM自己寫完了都不想看。所以，我武斷的認(rèn)為，撰寫某些PRD文檔實(shí)在是一個(gè)既耽誤時(shí)間又費(fèi)勁且不敏捷的事情（很多PRD都是一夜情，寫完了就不會(huì)修改更不會(huì)有人樂意看100P以上的文檔），是在讓產(chǎn)品經(jīng)理實(shí)現(xiàn)慢性自殺！
個(gè)人認(rèn)為，一個(gè)PRD文檔需要包含以下的內(nèi)容：
1、概述
1.1、名詞說明：文檔中涉及到的名詞
1.2、產(chǎn)品概述及目標(biāo)
1.3、產(chǎn)品風(fēng)險(xiǎn)預(yù)估
1.4、產(chǎn)品開發(fā)進(jìn)度：產(chǎn)品開發(fā)階段及責(zé)任人與時(shí)間節(jié)點(diǎn)
2、使用者需求
2.1、使用者需求描述：定義用戶是誰
2.2、管理員需求描述：后臺(tái)管理部分（很多人會(huì)忽略這個(gè)部分）
2.3、任務(wù)流程圖：從業(yè)務(wù)邏輯流程到產(chǎn)品邏輯流程轉(zhuǎn)化
3、功能需求
3.1、功能總覽
3.2功能需求分解：界面分解及交互說明和用例
4、非功能需求：與該產(chǎn)品相關(guān)聯(lián)的輔助產(chǎn)品等
5、上下線需求：產(chǎn)品的生命周期
6、運(yùn)營計(jì)劃：產(chǎn)品的上線后的反饋與改進(jìn)
整個(gè)文檔中，最大的部分其實(shí)是對功能需求的分解，但是最核心的部分是使用者需求與功能需求部分。使用Axure后，我發(fā)現(xiàn)Axure可以很好的承載我平常寫的這個(gè)產(chǎn)品需求文檔的全部內(nèi)容，最主要的問題是，Axure是可以網(wǎng)狀的展示的。下面是舉個(gè)例子：
在Axure的站點(diǎn)導(dǎo)航中，默認(rèn)的Home頁面承擔(dān)了PRD文檔的第一部分內(nèi)容；而使用者需求描述及任務(wù)流程圖也可以由Axure自帶的流程圖功能完成；任務(wù)流頁面的分解本來就是Axure中完成的；最后的非產(chǎn)品功能部分也可以由axure完成（文本塊組件）
同時(shí)，Axure支持多種格式的輸出，一般情況下我是發(fā)送給團(tuán)隊(duì)Html文件包，也可以是.chm格式的文件（團(tuán)隊(duì)協(xié)作目前還沒有嘗試）。該文件包打開后，左側(cè)是整個(gè)系統(tǒng)的導(dǎo)航菜單，右側(cè)是相應(yīng)的說明。最主要在于，原型中的頁面是可以相互跳轉(zhuǎn)的（得益與axure的強(qiáng)大交互功能），同時(shí)頁面有注釋功能。所以，整個(gè)產(chǎn)品需求文檔真正實(shí)現(xiàn)了基于產(chǎn)品的模擬，網(wǎng)狀的傳播，而不是Word式的樹狀閱讀。
1）見過不少新手使用Axure生成的原型有頁面是空白的，我問為什么，他說這個(gè)頁面不知道放什么，但是又不能不命名，否則邏輯上有些不通。實(shí)際上，這個(gè)空白頁面就可以用來放這個(gè)頁面的流程圖及整體的說明。
2）不建議做太復(fù)雜的Axure動(dòng)作，比如使用多個(gè)層、動(dòng)態(tài)面板等。因?yàn)樵诠こ處煹鹊难劾镌蛨D是不可以點(diǎn)擊的（基于viso等的慣性思維），所以，為了避免花很長時(shí)間去實(shí)現(xiàn)一個(gè)很炫的axure交互而最后被埋沒，建議把任務(wù)分解來畫。比如一個(gè)輸入框，需要畫：默認(rèn)狀態(tài)、獲得焦點(diǎn)狀態(tài)、輸入字符判定狀態(tài)、失去焦點(diǎn)狀態(tài)等，按照邏輯分步來展示。（在我特別蛋疼的時(shí)候我會(huì)先分步展示，然后搞個(gè)比較炫的交互放在上面自己玩或者用于演示）
3）在每個(gè)頁面的下方或者側(cè)邊（由頁面大小來定）要放一個(gè)功能詳解的文本塊來對本頁面的功能進(jìn)行詳細(xì)說明。也可以直接使用Axure自帶的注釋功能（組件注釋、頁面注釋）為什么不推薦用Axure的組件注釋功能？因?yàn)檫@個(gè)功能在生成的原型里是被隱藏的，有被人無視的可能。
4）使用axure的組件庫功能（可自制）和模塊功能既可以保證設(shè)計(jì)的統(tǒng)一性（設(shè)計(jì)規(guī)范），又可以提高原型制作的效率。圖中我采用了注冊模塊。
下面，QA時(shí)間（這個(gè)QA是問答，文中的QA是技術(shù)，呃，注意區(qū)分）
Q：為什么我看到有的書上說要寫N多文檔，帶RD的有：BRD、MRD、PRD、…。
A：是的，有這樣的定義。BRD（商業(yè)需求文檔）、MRD（市場需求文檔）、PRD（產(chǎn)品需求文檔）。每個(gè)公司的風(fēng)格不一樣，我個(gè)人傾向于把BRD與MRD整合，PRD單獨(dú)做。但是MRD與PRD中會(huì)有內(nèi)容重合，就是會(huì)同時(shí)提到用戶是誰？為什么要做？產(chǎn)品目標(biāo)是什么？等幾個(gè)問題
Q：Axure有個(gè)功能是可以導(dǎo)成Word格式，把做的原型導(dǎo)入后是歸類好的，包含了用例文檔，為什么不這么玩呢？
A：沒人說不可以這么玩。還是那句話，個(gè)人習(xí)慣。
Q：除了頁面原型之外你塞了這么多東西到Axure里，會(huì)不會(huì)導(dǎo)致源文件以及生成的文件體積巨大？
A：實(shí)際上塞進(jìn)去的東西都是文本，使用axure的文本組件完成的，體積并不會(huì)大。同時(shí)，請不要在用axure做原型的時(shí)候使用過多的圖片，盡量是用組件和模塊完成。我目前位置做的最大的一個(gè)原型是4.7M，這是一個(gè)完整的系統(tǒng)原型。
Q：按照你的寫法Axure好像是萬能的了？
A：沒有不好用的工具，只有用的不順手的人。人是活的，工具是死的，且Axure目前在mac平臺(tái)下功能并非很強(qiáng)大，也有很多人覺得axure很笨重，更加喜歡輕量級的原型功能。不過，這些都不是核心問題，核心問題是要讓你的團(tuán)隊(duì)能夠以最高的效率進(jìn)行合作。使用Axure的人不必鄙視Viso，用excel的人也不必羨慕OmniGraffle，拿Word的人也不必留戀firework。
既然提到了MRD也順便說下我寫這個(gè)文檔的習(xí)慣。一般情況下這個(gè)文檔是給老板看的，主要是對市場的分析、同類產(chǎn)品的競品分析、我們產(chǎn)品的盈利預(yù)測等等。所以，一般由PPT來完成。你的文檔越長老板越反感，你的文檔文字越多老板越?jīng)]興趣，所以，PPT是最好的方式。
文檔這個(gè)東西跟流程有類似的地方，大公司會(huì)相當(dāng)重視這個(gè)事情，因?yàn)橐?guī)避風(fēng)險(xiǎn)。流程與文檔的核心點(diǎn)在于如何高效傳遞如何快速執(zhí)行而不是他如何寫以什么形式寫。相對于小團(tuán)隊(duì)而言，流程之殤大可避免。當(dāng)然，如果大公司能夠以小團(tuán)隊(duì)的心態(tài)去做大產(chǎn)品的話，定會(huì)事半功倍！我更相信小團(tuán)隊(duì)大產(chǎn)品的力量，而不是大團(tuán)隊(duì)大產(chǎn)品的說法。
作者：kent.zhu
文章來源：幻風(fēng)閣
