返回目录：电脑怎么了
中小团队往往讲究快速迭代，所以产品需求文档最好也满足快速高效易沟通的特性。
越来越多的PM已经在使用Axure【Axure RP 能帮助网站需求设计者，快捷而简便的创建基于网站构架图的带注释页面示意图、操作流程图、以及交互设计，并可自动生成用于演示的网页文件和规格文件，以提供演示与开发。】“原型+注释”的方法，输出原型HTML作为产品需求文档。
但是每一个版本的产品需求文档该如何交付呢？直接用整个原型，还是单独输出一份。如果单独输出，如何输出呢，输出哪些页面呢？
总结了我这两年使用Axure写版本需求文档的经验，含有一些独特技巧。
一、版本大纲
一份版本需求文档至少包括以下部分：
版本需求对应的原型版本的相关信息修改记录需要做的新功能需优化的旧功能需修复的BUG需输出的视觉稿需要其他协助的事宜。
这些内容最终体现到Axure中的左上角-页面结构，效果图如下。
二、版本原型
将该版本需要用到的所有页面选中，输出原型html。
三、版本信息
我是用版本号【版本号(version number)是版本的标识号。】来命名页面的，比如V3.0。
然后把此次版本的目的，投入、以及重要资料放到一块。供其他人员查看。
3.1、重要网址
比如此次版本原型的地址，我会单独发布到内部gitlab【GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。】或者其他地方，然后把网址给到大家。以及其他版本的网址。
比如视觉稿的地址，也会放到内部gitlab供所有人查阅和撕逼。如果你的视觉稿是使用sketch的在线预览插件，甚至能够直接比对代码。
需要注意的是，上述重要网址最好保证仅内部用户可访问，比如通过限定hosts的方法。
3.2、排期表
这个的重要性就不细说了。你可以按照职能输出来一一排期。
也可以按照上线要求来倒推时间点。
3.3、人员规划
此次版本有哪些人员参与，扮演的角色是什么，各自工作什么时间完成。
3.4、修改记录
记录一些修改事宜，方便大家理解。
四、需求清单
不太建议使用需求列表这样落后的方式来呈现需求。建议使用Axure新建页面，然后用文字、页面快照、引用页面等功能快速展现。
最好结合旧文《高级PM如何规范化的管理产品文档》一起阅读比较好，很多知识是相关联的。
强调一点，按照我的方法来展现新功能、优化功能、修复BUG。看似没有需求列表舒服。但是用图文的方式，会让前端工程师和视觉设计师更容易理解需求。
并且原型往往需要经过多次修改，而你仅需修改原型，很少需要修改这3个页面。因为这里利用了Axure的引用这个牛逼的特性。其他文章中已多次阐述过。比如旧文PM如何快速完成并交付视觉需求和如何正确地画出页面流程图。
4.1、新功能
记录新增的功能，包含页面、各种组件、控件。
4.2、优化功能
记录优化的功能，包含页面、各种组件、控件。方法如上。
4.3、修复BUG
记录要修复的bug，方法如上。
五、原型视觉稿
不少PM认为画视觉稿是视觉设计师的事情，所以也不会整理一下此次版本中需要新增和优化哪些页面，新增和优化哪些视觉组件。
而事实上，从PM的角度，整理所有原型视觉稿交付给视觉设计师，能够保证不忘做一些页面，以及有助于全面了解PM思路。
详见我的文章《PM如何快速完成并交付视觉需求》以及直接查看演示。
六、需要其他部门配合的事宜
比如需要运营童鞋提前注册一些账号，充值一些测试费用。
比如需要客服童鞋联系一些铁粉，到时候需要内测。以及处理一些突发问题。
七、总结
按照上述的方法来输出每一次版本的需求，中小团队基本就够用了。
你也可以根据自己的需求去新增修改一些内容，欢迎共同探讨。