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