干货 | 写产品需求文档的正确姿势

任何一个产品经理，都避免不了编写产品需求文档(Product Requirement Document，PRD)的命运。对于一个产品初学者来说，写作PRD更是一门必修课。一篇好的PRD都包含哪些内容呢?以及那些工具能帮助我们更顺利地写出PRD呢?

1、熟悉相关业务

言下之意，就是产品经理首先得明确，我们要做的是什么项目，公司主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。了解公司业务是规划产品的前提，好的开始是成功地一般，业务的重要性可见一斑。

简而言之，得要求产品面向业务(对象)，同时能够进行业务行为(设计)，这是需求的开始，

推荐工具：Rationrose ★★★★

说明：通过use case可以很容易，很清晰的将整个业务员系统直观、规范的表达出来。将整个项目拆解之后，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。这样一来，工程师看得明白、产品的同事们也看得明白，内部交流起来就顺畅得多。

2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一

笼统得说，就是流程问题。我们已经知道，规划产品之前，应该了解公司的业务。然后，就要对业务进行分析和梳理。每一项业务都有自己的逻辑，先做什么，后做什么，哪一部分是其他部分的前提，这些都是非常重要的。

流程就是逻辑，你只有制定合理的、符合业务实际情况。符合系统实现(可实现、容易或稳定实现)的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。在业务上，不管是进销存、还是SAP原理其实都是相通的，梳理流程的时候也应该能触类旁通。

推荐工具：Microsoft Visio ★★★★★

说明：Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio你可以直接的把整站流程框束在文档上。不论你开发怎么样的 系统，需求什么样的环境，都可以一一标明出来。你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。

应该强调一点，产品人员最好熟悉一下开发工作，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。

3、把项目条目化，条理化，目录结构具体规定好。

有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。将业务流程用产品的形式最好地表达出来，想一想怎么用功能去诠释业务，怎么设计出最符合操作逻辑的功能。功能怎么排列，设置更符合业务的使用逻辑，怎么样让使用者更容易、直观的入手，怎么样一个很好的B/S或C/S的功能界面呈现到前台。

推荐工具：Mind manager ★★★★

说明：mindmanager是一款可视化思维导图软件，它可以智能的建立各个模块，各个主、次、平级目录。同时也当便做调整、做对外的功能结构的报告演示。更值得一提的是通过它可以导出到word中，方便对word进行完善。

4、前台结构布局，合理规范的将系统脱去朦胧的华纱。

有的时候，开发者不知道这个地方应该有哪些功能，到了这一步了有哪些功能，数据提交失败有什么提示，不会使用有什么帮助或提示操作、入口，因为开发人员的注意力集中在了具体怎样实现一项功能，而不是应该有什么功能。

所以做为产品人员，我们要提前充分的考虑到上述到这些东西，对于从业人员来说这也是我们最基本的素要体现。很多人都说，要符合业务系统，要符合使用习惯，要符合浏览或人机传播，口碑，品牌形象习惯，总是就是人性化的去把这个东西设计的更合理，更易用，更有亲和。

推荐工具：Axure rp ★★★★★

说明： Axure是一款特别好用的产品模型设计软件，可视化操作，ajxa能直接生成页面需求，更独特的它可以实现：div onmouse onclick等很多交互事件，UI和工程师看到页面能直接看到你要设计的效果，而不是很头痛的看没完没了的文字描述了。

5、穿针织网，把需求综合起来，整理成最终的产品需求文档

该做的做了，然后开始做到一个文档里，写明项目名称，把CASE/l流程、目录放近去，把项目背景、需求的各个约束、规则的界定、文字的补充说明交代清 楚，同时把模块的字段，状态，对应该操作。所以模块设计的页面地址整理好，一份色香味齐全的文档就出炉了。

推荐工具：Microsoft Word ★★★★★

说明：没有word是件很可怕的事情，因为我觉得很多替代文档编辑软件都没有它来的让我喜欢，不知道大家有没有同样的感觉。