面对众多的产品设计需求，产品设计人员要想一一理清楚就已经是一件不容易的事，更何况要将这些需求清单全部都变成可演示的产品原型。
对于没有研发背景的产品经理来说，从需求检查清单到需求文档是一个较难理解的技术鸿沟，这里的研发背景是指参与过产品的需求分析、产品设计、产品开发、产品测试、产品运营这样完整的过程，特别是没有开发之前的产品阶段经验的，对产品的需求管理会比较模糊，没有一个清晰可视化的指引，产品经理在管理产品的时候会比较累，也比较的被动。
因此对于这类产品经理来说，有相对来讲比较贴近最终产品实际的原型，对产品的需求管理会容易很多。再者对产品设计人员来说，一个产品的原型并不是只有一个版本，且设计多个需求时，部分设计可以重用，也能提升产品设计的效率。
AxureRP经过这么长时间的使用，已经渐渐深入人心，不过很多人看到AxureRP的第一反应就是原型设计，其实AxureRP还可以做很多其他的事情。就像很多其他工具那样活用起来，虽然说术业有专攻，但在要求不高的时候，AxureRP绝对可以用来做产品的需求管理，首先其自带的共享协作功能，就是很好的将需求化整为零，又最终归集在一起的应用；其次是其站点地图管理模式可以清晰的反应出整个产品的结构，类似产品的需求检查清单，可以逐一确认；再者AxureRP可以用来做版本管理，每次改动都可以记录下来。
AxureRP的共享协作功能类似开发人员用的集成开发环境，可以将需求分成各个小项，由各个不同的产品设计人员设计，然后最终归集在一起做统一验证，当然这里有一个设计风格统一的问题，这个应该每个公司都有一套特定的设计规范的，至少某个产品的设计风格是有统一标准的。需求拆分后，首先要保证每个单独的需求都有完整的Story可描述，原型设计完成之后可做单独的演示验证；其次要保证每个拆分后的需求合而为一之后是一个整体，这里不讲求无缝对接，只求大体上没有问题即可，这样在做完整性验证的时候，就不会出现断层的情况，就要求在开始原型设计之前要确定好整个产品的需求检查清单，对每一条需求list指定对应人员进行设计。大家在共享任务里领走各自的所负责的部分，在设计完成后提交即可，且每次改动规定必须先签出到本地，这样可以不影响实际的原型整体。
AxureRP的站点地图面板可以很好的展现产品的层次结构，可以直接将需求检查清单按照产品的模块构成维护成树形的结构，每个需求对应一个节点，这样可以清晰的看出哪些做了哪些没有做，而且这样设置之后也有利于协作的时候分派，汇总之后也不会导致结构混乱。如果不能按照这样的方式进行设置，也可以在设置好对应的产品信息架构之后，将里面的节点和需求检查清单里面的list项进行关联，以便备查。这块功能的使用我在介绍AxureRP的时候讲到过，可参考《AxureRP介绍–站点地图面板》和《AxureRP介绍–架构图和流程图》。
产品的设计版本管理可以依托AxureRP的站点地图面板来进行，将每次相对较大的调整都复制出一个版本节点来记录，这里改动是否需要新建版本由各自的产品设计人员来把握，目的是为了对每个设计版本可以进行追溯，尽量减少改过来又改回去的返工情况。而且进行版本管理之后，也可以清晰的看出每个需求节点的需求变动情况，前前后后改动次数较多的就说明有问题了，要么是需求分析阶段的问题，要么就是产品设计人员没有理解需求的本质，总之可以针对性的进行分析和解决。
AxureRP还可以自动生成需求设计说明书，这个我想大家都知道了，只不过所生成的问题如果要实现图文并茂，一是在设计的时候就写好注释，本文所介绍的方法，在协作的时候就可以要求不同的设计人员将各自所设计的功能进行注释；二是手工的补写，对于较大的设计项目来说，这个比较困难，必须有一个人了解整体的设计细节。
AxureRP还有很多隐性的功能是可以发掘的，比如模板的重用、页面的说明等，个人感觉如果现行公司内没有很好的需求管理工具的话，AxureRP是一个不错的选择，可以在内网搭建一个小型服务，将产品原型的生成目录发布上去，就可实现在内部的访问，非常的便捷。
转载请注明：木卫艾欧网 » 如何用AxureRP做产品的需求管理
原创文章，作者：Tinadmin，如若转载，请注明出处：https://www.iamue.com/2464/
