编辑导语：需求文档的编写是产品经理的日常业务之一。那么，考虑到具体业务的内容和难度差异，如何编写产品需求文档呢？在本文中，作者结合Axure原型阐述了自己对需求文档编写的思考，让我们一起来看看。

在工作中，我和领导对产品需求文档有分歧。基于之前快速迭代小团队的工作习惯，我觉得交付开发的时候标注交互原型就足够了，方便我写描述，方便开发者阅读，一举两得。

但领导告诉我，一定要写文件，一定要从思想上改变这种“危险”的观念。我没办法。虽然我从事了几年的产品工作，但我从一开始就已经理清了以什么形式交付产品需求文档。

00-1010当讨论这个看似基本的问题时，产品经理会习惯于拆解问题，定义名词。通常，问题来自不合理的问题。

那么首先，我们说的Axure的原型到底是什么呢？毕竟Axure只是一个工具，不同的手会做出不同的花样。所以首先我想说说Axure原型产品原型。

什么是产品原型？有两种定义：

某物的第一个、典型的或初步的模型。—— 《牛津字典》

将想法转化为可以与他人交流或与用户一起测试的形式，并有随着时间的推移改进想法的意图。—— 《原型设计》奥赖利

我大概明白了意思，但还是不太明白，是吗？让我们举几个例子。如果上面是项目的最终产品，那么下面就是产品的原型。

产品的原型就是产品的原型，有些人会把它做得非常精细，试图把最终的产品还原成它想要达到的样子。有些人可能是完整的，这样观众就能抓住他想表达的最重要的一点。

至于我们说的产品，其实以下几种形式都可以算是产品原型。

但这些只是想法的表达。对于刚才的例子，最终会实现一个产品。对于大多数团队和项目来说，我们仍然需要一个描述性的文档来进行构建，这样我们就可以一起做，否则我们只能依靠自己。

继续深化和细化你对产品原型的解释，形成描述性文档，得到产品需求文档。从抽象的角度来看，需求文档只比原型有更多的需求。

一般用文字、表格、流程图来说明软件产品需求文档就足够了。然而，由于行业的发展，建筑施工图已经形成了自己独特的标注体系。想想看，为什么产品需求文档不能有自己的标签体系？

所以接下来，我将一口气得出三个结论：

产品需求文档=产品原型需求描述；产品需求文档绝对不是Word版本文档；一个清晰标记的Axure原型就是产品需求文档。

00-1010如果你接受我上面的结论，接下来真正需要讨论的只是形式的问题，写PRD、Axure和Word哪个更适合？

似乎越来越多的人倾向于使用Axure，还有人教人们如何制作动态文档。看起来很酷。但是，当需求逻辑很多的时候，要想把所有的需求描述都写成“真”文档，排版就是一门科学。

Word文档看起来老气横秋，而且经常长达数百页，让人一眼就看大了。因为很快就会被淘汰，每当老板想要一份“通用”的文件，他都要重新使用。

其实我们都知道，Axure和Word最初并不是为了写产品需求文档而诞生的。由于各自功能形式的限制，他们决定了在编写PRD时各有利弊。

Axure提供单独的画布。你可以随意放置文字和图像，并将其与线索联系起来。你也可以让他们与这些图像互动。

Word提供了一个连续的流式内容区域。你可以随时用内容填充，章节标题定义好了就再也不会乱了。Word也比其他软件有更成熟、更强大的改版、阅卷功能，可以记录每一次改版的变化。

不同的工具导致两者输出的不同需求场景。

就我个人而言，我画了一个不成熟的比例图来反映它们之间的直观差异：安素的珠三角也是如此

是会更偏产品原型功能，需求说明功能会有瓶颈；Word的PRD需求说明功能很强大，几乎没有上限，但是对于原型的展示仅限于图片，比起能交互起来的原型，不在一个量级上。

三、Part 3

具体形式的选择上，还是要根据每个团队的实际情况来选择。

我目前在一个ToB的金融业务产品上，系统所需要支持的是很成熟的业务流程。所以很多时候都与之前的七八个人的小团队快速迭代产品去验证市场不一样了。

加上金融这边的业务逻辑较为复杂，功能细节的满足性要求比较高，随着业务的深入和团队规模的扩大，在仅使用Axure作为PRD交付的时候遇上了一些管理上的问题。

于是最后我得到了一个看起来比较废话但可能还是比较有价值的结论——Word+Axure一同完成这个PRD。

Axure文档作主要完成原型功能，会有一些注释，但不会对需求进行详细描述，Word文档会写上全部的业务逻辑、功能逻辑，也有界面截图，是可以单独作为最终交付物的。

基于这种方式，两者的内容占比上肯定要进行一定的调整，于是我个人又画了个不成熟的调整后的比例图。

我们或许期待着一个更好的产品需求文档工具出现，但在那之前，如果你所在的团队对纸质的文档还是有一定的要求，我觉得不妨就先按这样去做吧。

本文由 @pydz发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。