编辑导语：产品需求文档的撰写是产品经理的日常业务之一。那么，考虑到具体业务的内容和难度差异，产品需求文档的撰写应该如何操作呢？在本文中，作者结合Axure原型，阐述了他对编写需求文档的思考，让我们来看看。
在工作中，我和领导就产品需求文档产生了分歧。基于之前快速迭代的小团队的工作习惯，我觉得只需要在交付到开发的时候标注交互原型就可以了，方便我写描述，方便开发人员查看，一举两得。
但是领导让我写文件，改变我的“危险”思想。没办法。虽然我从事产品工作也有几年了，但是我从一开始就整理了产品需求文档应该用什么形式交付。
首先，第1部分讨论了这个看似非常基本的问题。产品经理将习惯于分解问题和定义名词。很多时候，问题来源于不合理的提问。
那么首先，我们说的Axure原型是什么？Axure毕竟只是一个工具，不同的人会做不同的招数。所以首先我要说Axure原型产品原型。
产品原型是什么？下面有两个定义：
某事物的第一个、典型的或初步的模型。—— 《牛津字典》
将想法转化为可以传达给他人或与用户一起测试的形式，并有随着时间的推移改进想法的意图。—— 《原型设计》奥赖利
我大概明白意思了，但还是不太明白，是吧？让我们举几个例子。如果上面是项目的最终产品，下面是产品原型。
一个原型就是一个产品的原型，有些人会把它做得很精细，试图把最终的产品还原成自己想要的样子；有些人大概是完整的，这样观者才能到达他想表达的最重要的一点。
至于我们说的产品，其实下面这些形态都可以算是产品原型。
但这些只是想法的表达。刚才也是这个例子。最终还是要实现一个产品。对于大多数团队和项目来说，我们还是需要一个说明性的文档来进行构建，这样才能一起做这件事，否则一切只能靠自己。
继续深化和细化你对产品原型的解释，形成解释性文档，你就得到产品需求文档。抽象来说，需求文档只是比原型多了一些需求规格。
一般用文字、表格、流程图来说明软件的产品需求就足够了。随着行业的发展，建筑施工图形成了自己独特的标注体系。打开你的思维，好好想想。为什么产品需求文档不能有自己的标注体系？
所以接下来我会一口气得出三个结论：
产品需求文档=产品原型需求描述；产品需求文档不是绝对的Word文档；清晰标记的Axure原型是产品需求文档。
二。Part 2如果你接受了我上面的结论，那么接下来你实际上需要讨论的只是form、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文档会写所有的业务逻辑、功能逻辑、界面截图，可以单独作为最终的可交付成果。
基于这种方式，两者的含量比例必须进行一定程度的调整，所以我个人画了一张不成熟的调整比例图。
我们可能期待一个更好的产品需求文档工具，但在那之前，如果你的团队对纸质文档还有一定的需求，我想我们不妨先这样做。
本文由@ Gadam Xie原创发布。每个人都是产品经理。未经作者允许，禁止转载。
题目来自Unsplash，基于CC0协议。
暂无讨论，说说你的看法吧
