Word產品需求文檔，已通過時了【轉】

　　簡單來談一下，爲何軟件開發項目中，須要需求文檔這麼個東西?

　 　在稍微大一點的開發團隊中，產品經理未必能向全部開發人員，傳達具體的產品開發需求。這時就須要一份文檔來供全部的項目參與人員閱讀。而產品經理又經常 愛拍腦殼、容易變卦，因此文檔也是開發人員約束產品經理的一項武器。在產品上線前的測試環節，測試人員也一樣會拿產品需求文檔來驗收產品質量。當團隊進入 新人時，文檔也可讓新人更快地瞭解產品。

　　總的來講，產品需求文檔有三個核心做用：

　　一、傳達產品開發需求;

　　二、保證各部門溝通有理有據

　　三、產品質量控制有具體標準

　　因而可知，產品需求文檔是必不可少的。那一份好的需求文檔，就應該能準確傳達出產品的開發需求。那麼產品需求文檔該用什麼方式寫，才能更好地傳達出產品開發需求呢?

　 　就我所見，行業大多產品經理都是用Word+Axure原型的方式組成產品需求文檔。那這種方式，是否真的能方便地表達出產品需求?我問了不少程序猿， 他們在開發時，通常都是看着效果圖和原型圖寫代碼，只有在遇到問題時，纔會查看word文檔。也就是說，開發須要一邊寫代碼，一邊看效果圖，一邊看原型， 還要時不時查看文檔。並且，大多數程序猿都不會逐字逐句去讀產品經理的長篇大論。那產品經理寫word真的合適嗎?這樣的用戶體驗真的好嗎?花費大量時間 寫word真的有價值嗎?在Axure畫原型的同時，咱們爲何不能直接在旁邊標註呢?這樣豈不是方便快捷不少嗎?

　　其實，當下流行一種直接在原型圖上標註的需求文檔撰寫方式。在新版的Axure8中，也已經推薦了原型加標註的需求文檔樣式。Axure8新增了一組部件—不幹貼，就是方便產品設計人員進行功能標註。

　　重視用戶體驗的產品需求文檔該怎麼寫?

　　下面我就不講思路了，先展現個人產品需求文檔的歷史版本和最新版本對比。

　　產品需求文檔V1.0 版 這是我一年前的原型加標註，只有很粗糙的標註，如今看來真的是很low啊

　　產品需求文檔v2.0版本 這個是第二個大改版，作成了網頁的形式，有一級導航，二級導航，還有版本號。左邊的站點地圖也進行了清晰的邏輯分組。

　　產品需求文檔v3.0 這是如今我用的版本，導航欄變得精緻了有沒有。全部標註都進行了像素級排版，全部的間距都用準確的像素測量，而後佈局。

　　隨着每一個版本的調整修改，其實都伴隨着視覺效果提高、邏輯架構更清楚，也更加提高了用戶體驗。

　　下面繼續來展現更多頁面

　　產品簡介 我將PPT作的商業需求文檔貼在了裏面，真可謂時時刻刻不忘商業目標啊

　　版本說明 是很是重要的版塊，整個版本全部的需求都列在這裏，而且已經寫好了版本升級的提示內容，市場同窗能夠直接拿去用。開發同窗一般都是參考這裏來進行工做分配，點擊詳情按鈕，能夠直接跳轉到原型圖頁面，那裏有詳細的需求描述

　　開發週期 此頁面我沒有進行詳細豐富，其實還能夠寫具體什麼功能，由誰負責，工期多久等內容

　　版本歷史 這個頁面也是很重要的頁面，全部的版本迭代均可以展現在此表格，能夠清晰地看到大家團隊的版本迭代週期

　　修訂歷史 此頁面是很是重要的頁面，雖然他是排在最後一個位置，可是，每次打開Axure文檔都會先顯示此頁面。就拿需求文檔來講，我還沒遇到哪一個版本不用進行修改的，因此產品經理必定要把每次文檔調整的地方在這裏清晰地寫出來，方便文檔讀者觀看，也方便本身記錄

　　思惟導圖 這個版塊下，全是產品相關的圖表，好比產品結構圖、信息結構圖、流程圖等。我曾經嘗試用Axure自帶的流程圖部件來畫流程圖和思惟導圖，但得出的結論是，太耗時間，並且佈局很費力。因此，這裏我都是用mindmanager導出圖片

　　全局說明 這個頁面實際上是展現整個產品的設計規範，一些不少頁面通用的規則均可以在這裏展現

　　交互原型 此頁面就是全部的原型+標註頁面了，在這裏，我會將這個頁面全部的功能與跳轉邏輯標註清楚，而且用紅色將重要按鈕凸顯出來，用藍色標記可點擊的連接。而功能標註的佈局我是仿照sketch的風格設計的，但比sketch更優秀的地方在於，不少地方是能夠點擊的，具備交互的

　　用例文檔 其實，這個用例文檔的頁面，是我閒的無聊時作的，並無什麼卵用，測試人員也不會使用此表，更加方便的仍是Excel

　　需求卡片 這個頁面到如今也已經放棄了，由於對需求的整理，最好仍是在Excel中

　　結尾

　 　到這裏，個人產品需求文檔就講完了。從最粗糙的原型到如今精細的原型，歷時一年。我能從表象的產品需求文檔中看出，本身自己的能力也在逐步提升。其實， 文檔也是幫助產品經理梳理思路的一種手段。忽然想到，什麼是產品思惟?不斷髮現問題，解決問題就是產品思惟。只有不斷思考，不斷髮現問題，不斷總結，才能 優化出更優秀的產品。