编辑导语：需求文档的撰写是产品经理的日常业务之一，那么，就具体业务的内容、难度差异等方面进行考虑，产品需求文档的撰写应该如何操作？本篇文章里，作者结合Axure原型，阐述了他对需求文档的撰写思考，一起来看一下。
工作中就产品需求文档的事情与领导发生了分歧， 基于之前快速迭代小团队的工作习惯，我认为给开发交付的时候只要在交互原型中做好标注就行了，既方便我去写描述，又方便开发人员去看，一举两得。
但领导让我一定要写文档，而且让我一定要从思想上改变这种“危险”的想法。没办法，虽然从事了几年产品工作，我还是从头梳理了一下该用什么形式交付产品需求文档这件事。
一、Part 1
讨论到这种看似非常基础的问题，产品经理会习惯去把问题做拆解，把名词做定义，往往疑问就来源于问题提得不那么合理。
所以首先我们所说的Axure原型到底是什么。Axure毕竟只是一个工具，在不同的人手里会做出不同的花样，那么首先我要说Axure原型≠产品原型。
那什么是产品原型呢？下面有两个定义：
某种东西的第一个、典型或初步的模型。 ——《牛津字典》
将想法转化为可传达给他人或者与用户一起测试的形式，并且有随着时间推移改进该想法的意图。 ——《原型设计》O＇Reilly
大概意思明白了，但还是不是很明白对吧？那就举几个例子，上面是项目最终交产品的话，下面就是产品原型。
产品原型就是产品的一个雏形，有的人会把它做得很精细，尽量还原最终产品想达到的样子；有的人就大概整整，让看的人能Get到他想表达的最主要的点就行了。
具体到我们所说的产品，其实以下几种形式都能算作是产品原型。
但这些都只是进行想法的表达。还是刚才的例子，最终要将一个产品实现出来，对于大多数团队和项目来说，我们还是需要一个用于施工的说明性文档，这样才能够大家一起把这件事情做成，否则就只能凡事靠自己了。
把原本你对产品原型的讲解继续深化、细化形成一个说明性的文档，就得到了产品需求文档。抽象来看，需求文档就仅仅比原型多了一些需求说明。
软件的产品需求文档一般就用文字、用表格、用流程图说明就够了。而建筑的施工图由于行业的发展，形成了自己的一套独特的标注体系。开个脑洞想一下，产品需求文档又何尝不能有自己的一套标注体系呢？
所以接下来我会一口气得出三个结论：
- 产品需求文档=产品原型+需求说明；
- 产品需求文档并不绝对就是Word版的文档；
- 标注清晰的Axure原型就是产品需求文档。
二、Part 2
如果接受了我上面的结论，那其实需要接着讨论的只是形式上面的问题，Axure和Word，哪个更适合写PRD呢？
似乎越来越多的人倾向于用Axure，也有专门叫教人怎么做个动态文档的，看起来很酷炫。但需求逻辑真的很多时，要想把需求说明全部都写进去变成“真”文档，排版就是门学问。
而Word文档看起来既老派，又经常动辄几百页，让人一看就头大。可以为它就要被淘汰了，每当老板要个“总”文档时，又不得不用到它。
其实我们都知道Axure和Word一开始都不是为了写产品需求文档而诞生的，由于其各自的功能形式的局限，就已经决定了他们在写PRD时候有优势又有劣势。
Axure所提供的是一张张单独的画布，你可以随意摆放文字和图像，并用引线将它们连接起来。这些图像你还可以让他们可以交互起来。
Word提供了一个连续的流式的内容区域，你可以一直往里面填充内容，定义好章节标题就永远不会乱。Word还有相比其他软件更为成熟和强大的修订及标记功能，能记录好每次修改的变更。
工具的不同，就导致了两者的输出物所针对的需求场景也是各有侧重。
我个人画了一个不太成熟的比例图，来体现他们之间的直观差异：Axure的PRD还是会更偏产品原型功能，需求说明功能会有瓶颈；Word的PRD需求说明功能很强大，几乎没有上限，但是对于原型的展示仅限于图片，比起能交互起来的原型，不在一个量级上。
三、Part 3
具体形式的选择上，还是要根据每个团队的实际情况来选择。
我目前在一个ToB的金融业务产品上，系统所需要支持的是很成熟的业务流程。所以很多时候都与之前的七八个人的小团队快速迭代产品去验证市场不一样了。
加上金融这边的业务逻辑较为复杂，功能细节的满足性要求比较高，随着业务的深入和团队规模的扩大，在仅使用Axure作为PRD交付的时候遇上了一些管理上的问题。
于是最后我得到了一个看起来比较废话但可能还是比较有价值的结论——Word+Axure一同完成这个PRD。
Axure文档作主要完成原型功能，会有一些注释，但不会对需求进行详细描述，Word文档会写上全部的业务逻辑、功能逻辑，也有界面截图，是可以单独作为最终交付物的。
基于这种方式，两者的内容占比上肯定要进行一定的调整，于是我个人又画了个不成熟的调整后的比例图。
我们或许期待着一个更好的产品需求文档工具出现，但在那之前，如果你所在的团队对纸质的文档还是有一定的要求，我觉得不妨就先按这样去做吧。