中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文想說的事情是，那個叫PRD文檔的家伙只是個稱呼而已，PRD的問題不在于如何寫而在于如何被傳遞與執行。這里簡單介紹一下我基于axure-rp的一種新的PRD寫法。（友情提醒：從來不用axure，認為他笨重無比的人請路過。）

從半只腳邁入產品經理這個大門的那天起我就被2個文檔的名稱深深的糾纏著，他們是市場需求文檔（MRD）、產品需求文檔（PRD）。先不論你是什么方向的PM，這2個玩意一定會一直伴隨你的Title跟著你。這2個文檔在不同的團隊中有不同的叫法和寫法，我也見過有團隊的MRD其實就是PRD，不沾半點商業市場分析的邊的，當然，這些不是本文探討的內容。

長久以來，有個很有趣的現象：“有沒有PRD模板，PRD該咋寫”這個問題已經成為新手入門經典必問題目之一；如果1年以后這個家伙還在這行里混，他一定會抱怨，娘滴，我們的QA壓根就不看我的文檔、我們的交互（如果有這個職位的話）還是會問我一些我寫的很明白的問題、我們的測試拿著文檔問我該咋測試、….

Web頁面之間的關系是網狀的，而Word文檔只能樹狀的表述，這無疑是矛盾的；PRD文檔無法做到實時更新發布，我回顧了我第一年寫的PRD文檔，很多下面的修改欄都是空的，慚愧之至….；所謂一圖勝千言，萬言剛夠文檔標準，每個PRD都是臭長臭長的，這樣的東西別說交互設計師了，很多PM自己寫完了都不想看。所以，我武斷的認為，撰寫某些PRD文檔實在是一個既耽誤時間又費勁且不敏捷的事情（寫完了就不會修改更不會有人樂意看100P以上的文檔），是在讓產品經理實現慢性自殺！

個人認為，一個PRD文檔需要包含以下的內容：

1、概述
1.1、名詞說明：文檔中涉及到的名詞
1.2、產品概述及目標
1.3、產品風險預估
1.4、產品開發進度：產品開發階段及責任人與時間節點
2、使用者需求
2.1、使用者需求描述：定義用戶是誰
2.2、管理員需求描述：后臺管理部分（很多人會忽略這個部分）
2.3、任務流程圖：從業務邏輯流程到產品邏輯流程轉化
3、功能需求
3.1、功能總覽
3.2功能需求分解：界面分解及交互說明和用例
4、非功能需求：與該產品相關聯的輔助產品等
5、上下線需求：產品的生命周期
6、運營計劃：產品的上線后的反饋與改進

整個文檔中，最大的部分其實是對功能需求的分解，但是最核心的部分是使用者需求與功能需求部分。使用Axure后，我發現Axure可以很好的承載我平常寫的這個產品需求文檔的全部內容，最主要的問題是，Axure是可以網狀的展示的。下面是舉個例子：

在Axure的站點導航中，默認的Home頁面承擔了PRD文檔的第一部分內容；而使用者需求描述及任務流程圖也可以由Axure自帶的流程圖功能完成；任務流頁面的分解本來就是Axure中完成的；最后的非產品功能部分也可以由axure完成（文本塊組件）

同時，Axure支持多種格式的輸出，一般情況下我是發送給團隊Html文件包，也可以是.chm格式的文件（團隊協作目前還沒有嘗試）。該文件包打開后，左側是整個系統的導航菜單，右側是相應的說明。最主要在于，原型中的頁面是可以相互跳轉的（得益與axure的強大交互功能），同時頁面有注釋功能。所以，整個產品需求文檔真正實現了基于產品的模擬，網狀的傳播，而不是Word式的樹狀閱讀。

1）見過不少新手使用Axure生成的原型有頁面是空白的，我問為什么，他說這個頁面不知道放什么，但是又不能不命名，否則邏輯上有些不通。實際上，這個空白頁面就可以用來放這個頁面的流程圖及整體的說明。

2）不建議做太復雜的Axure動作，比如使用多個層、動態面板等。因為在工程師等的眼里原型圖是不可以點擊的（基于viso等的慣性思維），所以，為了避免花很長時間去實現一個很炫的axure交互而最后被埋沒，建議把任務分解來畫。比如一個輸入框，需要畫：默認狀態、獲得焦點狀態、輸入字符判定狀態、失去焦點狀態等，按照邏輯分步來展示。（在我特別蛋疼的時候我會先分步展示，然后搞個比較炫的交互放在上面自己玩或者用于演示）

3）在每個頁面的下方或者側邊（由頁面大小來定）要放一個功能詳解的文本塊來對本頁面的功能進行詳細說明。也可以直接使用Axure自帶的注釋功能（組件注釋、頁面注釋）為什么不推薦用Axure的組件注釋功能？因為這個功能在生成的原型里是被隱藏的，有被人無視的可能。

4）使用axure的組件庫功能（可自制）和模塊功能既可以保證設計的統一性（設計規范），又可以提高原型制作的效率。圖中我采用了注冊模塊。

下面，QA時間（這個QA是問答，文中的QA是技術，呃，注意區分）

Q：為什么我看到有的書上說要寫N多文檔，帶RD的有：BRD、MRD、PRD、….
A：是的，有這樣的定義。BRD（商業需求文檔）、MRD（市場需求文檔）、PRD（產品需求文檔）。每個公司的風格不一樣，我個人傾向于把BRD與MRD整合，PRD單獨做。但是MRD與PRD中會有內容重合，就是會同時提到用戶是誰？為什么要做？產品目標是什么？等幾個問題

Q：Axure有個功能是可以導成Word格式，把做的原型導入后是歸類好的，包含了用例文檔，為什么不這么玩呢？
A:沒人說不可以這么玩。還是那句話，個人習慣。

Q：除了頁面原型之外你塞了這么多東西到Axure里，會不會導致源文件以及生成的文件體積巨大？
A：實際上塞進去的東西都是文本，使用axure的文本組件完成的，體積并不會大。同時，請不要在用axure做原型的時候使用過多的圖片，盡量是用組件和模塊完成。我目前位置做的最大的一個原型是4.7M，這是一個完整的系統原型。

Q：按照你的寫法Axure好像是萬能的了？
A：沒有不好用的工具，只有用的不順手的人。人是活的，工具是死的，且Axure目前在mac平臺下功能并非很強大，也有很多人覺得axure很笨重，更加喜歡輕量級的原型功能。不過，這些都不是核心問題，核心問題是要讓你的團隊能夠以最高的效率進行合作。使用Axure的人不必鄙視Viso，用excel的人也不必羨慕OmniGraffle，拿Word的人也不必留戀firework。

既然提到了MRD也順便說下我寫這個文檔的習慣。一般情況下這個文檔是給老板看的，主要是對市場的分析、同類產品的競品分析、我們產品的盈利預測等等。所以，一般由PPT來完成。你的文檔越長老板越反感，你的文檔文字越多老板越沒興趣，所以，PPT是最好的方式。

文檔這個東西跟流程有類似的地方，大公司會相當重視這個事情，因為要規避風險。流程與文檔的核心點在于如何高效傳遞如何快速執行而不是他如何寫以什么形式寫。相對于小團隊而言，流程之殤大可避免。當然，如果大公司能夠以小團隊的心態去做大產品的話，定會事半功倍！我更相信小團隊大產品的力量，而不是大團隊大產品的說法。

Read more:?http://www.ikent.me/blog/3042#ixzz0w7P4nDNs