今天在hutter的博客上闲逛，发现一篇名为《产品开发文档》的文章，讲述在项目管理过程中如何进行流程协作。笔者对原文作者提出的10大产品开发文档深以为然，但是从实际操作出发，认为原文还有两点内容需要补充。其一是说明这些文档在项目管理流程中如何相互补充构成一个整体，其二是需要建立一个统一文档管理平台以达到团队合作的最佳状态。

   原文作者提到，在开发新产品的过程中，需要定义以下十类文档，分别是：   

       1.       产品概念文档(项目策划书)

       2.       用户调研报告

       3.       产品需求列表

       4.       产品说明书

       5.       交互设计说明书

       6.       交互设计规范

       7.       视觉设计规范

       8.       开发文档

       9.       测试用例

       10.    产品评估报告

          （详细内容请参照http://blog.sina.com.cn/u/1281304134）

   作者对这10大文档的定义做了说明，尤其提到了产品说明书、交互设计说明书、测试用例等几类文档

是一个项目中不可缺少的，是项目有效运行的核心文档。但是，文中缺乏对文档适用环境的解释，读者在想

要撰写这些文档时，可能会因为不知道产品文档的适用情境而无所适从，或者做了无用功。

   众所周之，在项目管理过程中，我们会把项目划分为一系列小的任务，不同任务都有具体的目标，并

要求在任务截止日期时提供相应的交付物（Deliverables）。通常交付物可以是产品文档或者原型或者最

终产品。我们的思路是：由于我们已经知道了10大文档，我们将反过来推导相关的任务阶段。从我前不久刚

刚参与的一个网站UE设计项目的经验来看，这10大文档至少可以归属到三个项目阶段，如下图所示：

   下面结合我们的实际工作，说说这10大文档的具体应用环境。

   在企业中，项目策划书通常由项目经理或者产品经理来撰写，产品需求列表和产品说明书则有专门的产

品人员撰写。如果涉及的产品是以前产品的改版，则通常只有产品需求列表而无产品说明书。在这一阶段，

用户调研报告是需要UE人员来撰写的。为了获得这些信息，我们的方式有焦点小组、入户访谈、问卷调查

等。有时候还会使用文献法，即在以前研究的基础上进行归纳和总结，来发掘用户需求。

   设计阶段也是UE小组参与比较多的时期。交互设计说明书目前我们采用线框图或者PS图的形式展现。线

框图的优点是制作简单，便于多人协作，像现在比较好的制作线框图的软件例如Visio或者Axure，都提供了

很多组件（例如文本输入框、单选按钮、复选按钮等），便于随时将需要的组件拖入工作区生成用户界面。

Visio的好处提供了很多windows风格的标准控件（废话，本来就是微软制造嘛），比较符合大多数人的习

惯。Axure能够生成原型（prototype），这个功能很好。我们现在基本都可以用它来开发低保真原型了。另

一种方式是利用PS制作交互设计说明。它的优点是直观形象，但缺点是难以进行多人编辑。

   至于交互设计规范，我觉得也非常重要。主要作用是让UE小组的成员明白各种通用的或者特殊的交互方

式，弥补交互设计说明的遗漏。虽然阅读交互设计规范有利于我们全面把握用户界面的各种交互行为，但是

从我们的经验来看，相对于交互设计说明书，研发人员往往不理解交互设计规范，因为后者更加抽象，脱离

具体的使用情境。因此我们在提交交互设计规范时，一定要对研发人员详细讲解，并让他们反馈意见。

   视觉设计规范通常也有UE人员参与。主要是确定屏幕元素的像素尺寸，颜色搭配，风格等等。在此过程

中，UE人员通常会和视觉设计师协同工作，一起制定视觉设计规范。  

   编码过程目前都讲究的是迭代式开发。关于迭代式开发我认为可以有两种方式，一种是在产品研发过程

中不断进行测试，比较前后测试的产品并给予改进。另一种是产品开发采用小步快跑的方式，即研发人员将

开发到一定程度的产品直接投放市场并收集反馈，在此基础上不断改变产品，实际上是由市场来决定一个产

品的好坏。在此过程中，UE人员要充分发挥了解用户心理，以用户为中心的优势，不断进行测试收集数据，

并形成可用性评估报告（属于产品评估报告的一部分）。

   以上段落大致说明了产品开发文档的使用环境，下面再简单讨论统一文档管理平台的重要性。

   现在很多企业都有了自己的WebOA系统，项目计划及交付物等都可以上传于此。更强大的WebOA甚至集成

了很多在线办公程序。但是我们仍然深感协同工作的不便。以我们的工作为例，UE小组首先需要开会讨论阶

段性的工作，有时还要和其他部门的同事一起开会。确定好任务后，小组成员内部会进行分工，不同人负责

产品一部分的交互文档的制作，这就产生了对文档制作的规范问题。制作好以后，不同的部分需要合并，往

往在这个时候，小组成员要通过口头交流的形式，告诉其他人自己上传的是哪部分，是不是最新版本等等，

以便确保没有遗漏。即使交付物已经上传，也存在向其他人解释的问题。视觉人员需要知道具体页面的尺

寸、页面元素大小等等；原型制作人员需要知道页面是如何分块的，以便编写html代码控制页面形式。有时

候页面形式还受到文字多少，图片大小的限制。写好的文档需要区分哪些文字（图片）是实际页面中的内

容，哪些仅代表占位，因为其他人并不清楚这些。所以我们建议没有确定的文字都用无意义音节来代替（例

如blablablablablablablabla...），没有确定的图片用小方块来占位（有时会在小方块内加文字“***图

片”来进一步说明）。

   以上只是实际工作的一个简单缩影。我们现在有一个统一的文档管理平台，大家可以上传自己的文档，

下载某些文件夹的文档，并查看文档变动的历史记录，实际上系统类似一个ftp。但是我认为，一个更好的

文档管理平台应该集成一些在线会议和在线文档协作功能，并允许小组成员实时通讯。同时，用户可以自定

义系统消息的提示方式，这样大家的工作就能更好地协同起来。