中小團隊往往講究快速迭代，所以產(chǎn)品需求文檔最好也滿足快速高效易溝通的特性。

越來越多的PM已經(jīng)在使用Axure“原型+注釋”的方法，輸出原型HTML作為產(chǎn)品需求文檔。

但是每一個版本的產(chǎn)品需求文檔該如何交付呢？直接用整個原型，還是單獨輸出一份。如果單獨輸出，如何輸出呢，輸出哪些頁面呢？

總結(jié)了我這兩年使用Axure寫版本需求文檔的經(jīng)驗，含有一些獨特的運用技巧，提前預覽點擊版本需求文檔 。

一、版本大綱

一份版本需求文檔至少包括以下部分：①版本需求對應的原型②版本的相關信息③修改記錄④需要做的新功能⑤需優(yōu)化的舊功能⑥需修復的BUG⑦需輸出的視覺稿⑧需要其他協(xié)助的事宜。

這些內(nèi)容最終體現(xiàn)到Axure中的左上角-頁面結(jié)構(gòu)，效果圖如下。

二、版本信息

我是用版本號來命名頁面的，比如V3.0。

然后把此次版本的目的，投入、以及重要資料放到一塊。供其他人員查看。

三、版本原型

將該版本需要用到的所有頁面選中，輸出原型html。

3.1、重要網(wǎng)址

比如此次版本原型的地址，我會單獨發(fā)布到內(nèi)部gitlab或者其他地方，然后把網(wǎng)址給到大家。以及其他版本的網(wǎng)址。

比如視覺稿的地址，也會放到內(nèi)部gitlab供所有人查閱和撕逼。如果你的視覺稿是使用sketch的在線預覽插件，甚至能夠直接比對代碼。

需要注意的是，上述重要網(wǎng)址最好保證僅內(nèi)部用戶可訪問，比如通過限定hosts的方法。

3.2、排期表

這個的重要性就不細說了。你可以按照職能輸出來一一排期。

也可以按照上線要求來倒推時間點。

3.3、人員規(guī)劃

此次版本有哪些人員參與，扮演的角色是什么，各自工作什么時間完成。

四、修改記錄

記錄一些修改事宜，方便大家理解。

五、需求清單

不太建議使用需求列表這樣落后的方式來呈現(xiàn)需求。建議使用Axure新建頁面，然后用文字、頁面快照、引用頁面等功能快速展現(xiàn)。

最好結(jié)合舊文高級PM如何規(guī)范化的管理產(chǎn)品文檔一起閱讀比較好，很多知識是相關聯(lián)的。

強調(diào)一點，按照我的方法來展現(xiàn)新功能、優(yōu)化功能、修復BUG?？此茮]有需求列表舒服。但是用圖文的方式，會讓前端工程師和視覺設計師更容易理解需求。

并且原型往往需要經(jīng)過多次修改，而你僅需修改原型，很少需要修改這3個頁面。因為這里利用了Axure的引用這個牛逼的特性。其他文章中已多次闡述過。

5.1、新功能

記錄新增的功能，包含頁面、各種組件、控件。

5.2、優(yōu)化功能

記錄優(yōu)化的功能，包含頁面、各種組件、控件。方法如上。

5.3、修復BUG

記錄要修復的bug，方法如上。

六、原型視覺稿

不少PM認為畫視覺稿是視覺設計師的事情，所以也不會整理一下此次版本中需要新增和優(yōu)化哪些頁面，新增和優(yōu)化哪些視覺組件。

而事實上，從PM的角度，整理所有原型視覺稿交付給視覺設計師，能夠保證不忘做一些頁面，以及有助于全面了解PM思路。

詳見我的文章PM如何快速完成并交付視覺需求以及點擊網(wǎng)址直接查看演示。

七、需要其他部門配合的事宜

比如需要運營童鞋提前注冊一些賬號，充值一些測試費用。

比如需要客服童鞋聯(lián)系一些鐵粉，到時候需要內(nèi)測。以及處理一些突發(fā)問題。

八、總結(jié)

按照上述的方法來輸出每一次版本的需求，中小團隊基本就夠用了。

你也可以根據(jù)自己的需求去新增修改一些內(nèi)容，歡迎共同探討。