[4]_文档那么多，我该何去何从

[4]_文档那么多，我该何去何从

当了解了产品的方向和业务需求后，我们需学会将这些内容转变为纸上的内容，而在我们进行一款新产品的开发、维护到消亡的过程，也存在许多不同用途的文档，例如需求文档、产品说明书、测试文档、系统架构、网络拓扑、业务架构等等。但由于Web开发与我们传统软件的开发有些许不同的地方，所以有些文档也做了相应的精简，以便快速开发与快速迭代过程，下文就按照角色的不同，列出一些相关的文档说明。

产品经理相关的文档

BRD（Business Requirements Document） – 商业需求文档

内容：产品的市场方向、竞品分析、销售策略、盈利手段等，大致的制定了产品的发展方向，并不涉及详细的产品细节内容，但有时候会与下面的PRD文档整合在一起。
参与人：高级产品经理、公司高层、市场人员。
文档大小：一般2～5页，10页以内。
使用工具：Office
常见度：★★★☆☆
重要度：★★★★☆

MRD（Market Requirements Document） – 市场需求文档

内容：产品的市场方向、竞品分析等，大致的制定了产品的发展方向，相关的模块，以及优先级，同时会深入的考虑下解决方案的细节，很多中小型企业也会将市场需求文档整合进产品文档内。
参与人：高级产品经理、市场人员。
文档大小：一般5～10页以内。
使用工具：Office，思维导图
常见度：★★☆☆☆
重要度：★★★★☆

PRD（Product Requirements Document） – 产品需求文档

内容：具体的产品需求内容，实现的细节，以及用户的构成、UI描述用户的行为，整个产品的数据流程，以及相关的处理细节。此文档是作为产品经理最花时间的文档，同时也是开发人员了解产品的参考文档，包括许多细节的描述以及注意事项。是起着多方面开发、测试的关键参考文档。
参与人：产品经理、UI、开发人员、测试人员等。
文档大小：一般视项目而定。
使用工具：Office，思维导图，visio，禅道，Wiki百科等多种工具
常见度：★★★★★
重要度：★★★★★

以上的3个文档是作为产品经理而言，最后讲解需要输出的内容，但是随着公司规模，以及时间，会有选择的出现一个或多个不同的文档，一般PRD文档是必不可少的。当然，除此以外，为了更好的对某个细节或者功能描述清楚，有时候产品经理还会添加一些附件，这个需视具体的项目而定。比方说如电商中常见的对产品的分类数据库、地址区域的数据库等。

项目经理

Task List – 任务表

内容：对于项目经理的角色，我认为项目经理的主要工作在于3个部分，一个是项目开始时候的合理分解和任务的安排，二是每日或者每周的项目进展跟踪，三是项目到期时候的严格验收，当然有些公司会把项目管理的工作统一安排到产品经理那边，也有一些公司将项目经理的活安排到技术经理手里，科学的管理，肯定项目经理是独立的一个角色，他主要通过一些科学合理的方式，只关心项目的进展和如何保证质量的前提下，按时完成项目。但是在国内独立的项目经理很容易成为两边都受气的角色，所以经常产品经理或者技术经理担当这一角色。
文档大小：一般视项目而定。
使用工具：项目管理工具，如甘特图、Excel、禅道、Jira，后期还包括Bug的管理。当然每日项目进展的统计很重要。
常见度：★★★★★
重要度：★★★★★

技术人员

如果要做细分，我们又可以将文档分的更细，但是实战开发中我们一般都是大家共享相同的文档，既能够对技术进行整体的技术了解，又能够方便管理。

技术架构图（包括技术实现、网络拓扑、关键算法等）

内容：对使用技术的整体架构的描述，包括使用的技术，数据的大致流通方向，涉及的一些数据调取的方式等。
文档大小：一般视项目而定。
使用工具：Visio、XMind、Office等多种描述工作。
常见度：★★★☆☆
重要度：★★★★★

编码规范

内容：对开发人员在此项目（一般企业对特定语言都有规定的编码规则）中应该遵守的编码习惯，以保证整个代码的维护，及效率都有一定保障。
文档大小：一般视项目而定。
使用工具：Word。
常见度：★★★☆☆
重要度：★★★★☆

数据字典

内容：在一些用到数据库的应用中，数据字典也极其重要，能够让开发人员很清楚数据的存储和流动是如何实现的，一般数据库会有DBA或者架构师实现。
文档大小：一般视项目而定。
使用工具：Excel等。
常见度：★★★★★
重要度：★★★★★

功能详细说明书

内容：此处的功能说明书其实和上面产品经理的PRD类似，但两者的侧重点不一样，PRD更注重在产品的功能细节的描述，而详细说明书，主要是面向开发人员，会根据PRD文档，将我们的功能从技术实现的角度进行详细的说明。例如在我们功能详细说明书中，会对电子商务类型网站，将功能分为、用户模块、产品模块等等此类的描述，这样可以更好的进行代码级别的管理和底层功能的复用。
文档大小：一般视项目而定。
使用工具：Word等。
常见度：★★★☆☆
重要度：★★★★☆

基本上开发人员相关的文档如上，但是由于项目不同，可能有其他多种附属文档，如新技术的培训文档，相关实现技术的API文档，第三方功能的接口文档等。现在随着一些CMS、WIKI系统的成熟，也有很多公司使用部署在服务器的类似系统进行文档的管理，如现在的公司会使用wiki进行API的接口、产品经理的产品描述等。
工具其实是次要的，最主要是明白每个角色需要负责的内容才是最关键的。

测试人员

测试用例表

内容：看字义便知道我们的测试人员需要在之前了解产品的同时，进行测试用例的编写，这样才能在进行测试的时候，能够有条不紊，同时测试的覆盖率也较高一些。
文档大小：一般视项目而定。
使用工具：Excel、禅道等。
常见度：★★★☆☆
重要度：★★★★☆

Buglist

内容：Bug列表，也就是我们编写的代码在测试人员进行测试时发现问题的等级，一般都是有Bug状态的，通过Buglist系统，能够很好的对出现的问题进行跟踪、管理。
文档大小：一般视项目而定。
使用工具：禅道，Jira等。
常见度：★★★★★
重要度：★★★★★

文档角色关系

上面没有再列太多的角色，其实还有许多角色，如UI设计师、SEO专员、系统工程师、运维工程师等，但是相对那些角色的文档比较单一，归根到底还是需要了解到各自所处的角色需要履行什么样的责任，这样才能更好的让文档发挥出作用来。
比如，产品的产品需求书，不仅仅对上，让老板（当然有时候老板就是产品经理）了解到产品的功能描述，发展方向，也可以让开发人员了解到产品的需求。而Task List也很容易让项目经理对整个项目的进展了如指掌，同时也让各开发人员很清楚自己的工作任务与时间节点。

当然，最关键的还是执行

开头，就说到，我们很多时候文档的作用主要是为了进行沟通，所以如果文档写完之后，不进行有效沟通的情况下，文档的作用将会受到一定影响。我觉得写好文档的同时，最好及时的沟通，执行好计划，是对项目顺利进展的有力保障。