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

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

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

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

一、版本大綱

一份版本需求文檔至少包括以下部分：

• 版本需求對應(yīng)的原型
• 版本的相關(guān)信息
• 修改記錄
• 需要做的新功能
• 需優(yōu)化的舊功能
• 需修復(fù)的BUG
• 需輸出的視覺稿
• 需要其他協(xié)助的事宜。

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

二、版本原型

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

三、版本信息

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

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

3.1、重要網(wǎng)址

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

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

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

3.2、排期表

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

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

3.3、人員規(guī)劃

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

3.4、修改記錄

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

四、需求清單

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

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

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

并且原型往往需要經(jīng)過多次修改，而你僅需修改原型，很少需要修改這3個頁面。因為這里利用了Axure的引用這個牛逼的特性。其他文章中已多次闡述過。比如舊文PM如何快速完成并交付視覺需求和如何正確地畫出頁面流程圖。

4.1、新功能

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

4.2、優(yōu)化功能

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

4.3、修復(fù)BUG

記錄要修復(fù)的bug，方法如上。

五、原型視覺稿

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

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

詳見我的文章《PM如何快速完成并交付視覺需求》以及點擊直接查看演示。

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

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

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

七、總結(jié)

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

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

相關(guān)閱讀

PM如何快速完成并交付視覺需求

高級PM如何規(guī)范化的管理產(chǎn)品文檔

如何正確地畫出頁面流程圖

同一份PRD如何滿足不同受眾的查看需求

#專欄作家#

浪子，業(yè)務(wù)型PM，浪子PRD系列51prd.com，公眾號：langzisay。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。