原作者：浪子PRD? ? 來源：PMCAFF ? ?注：有刪改

原型預覽：http://51prd.com/demo/start.html#g=1&p=使用說明

一、版本大綱

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

二、版本信息

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

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

三、版本原型

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

3.1、重要網址

比如此次版本原型的地址，我會單獨發布到內部gitlab或者其他地方，然后把網址給到大家。以及其他版本的網址。

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

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

3.2、排期表

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

3.3、人員規劃

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

四、修改記錄

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

五、需求清單

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

最好結合舊文《高級PM如何規范化的管理產品文檔》一起閱讀比較好，很多知識是相關聯的。

強調一點，按照我的方法來展現新功能、優化功能、修復BUG。看似沒有需求列表舒服。但是用圖文的方式，會讓前端工程師和視覺設計師更容易理解需求。

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

5.1、新功能

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

5.2、優化功能

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

5.3、修復BUG

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

六、原型視覺稿

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

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

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

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

比如需要客服童鞋聯系一些鐵粉，到時候需要內測。以及處理一些突發問題。

八、總結

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

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