最近在思考项目中应该是怎样一个协作流程时，想到了一些关于项目文档建设的一些问题，总结以前的项目经验，通过与朋友的沟通、讨论，最后整理了这么一个结论：开发新产品所需要十类文档，欢迎大家更加深入的讨论。
1、产品概念文档(项目策划书)
主要是对市场需求进行合理的科学的推导，得出新产品机遇，并对产品定位以及未来的发展方向进行概念性阐述。产品概念文档主要用来对新产品进行宣讲，让项目团队对将要开发的产品有一个概念上的理解，在思想上达成一致。
2、用户调研报告
主要有两类，一类是产品概念形成之初，研究人员进行的需求调研而输出的报告。主要是为产品概念的提出提供科学的依据，为需求的推导寻找佐证。另外一类是项目开发过程中，对设计中不确定以及有分歧的地方进行用户测试，得出结果并输出用户测试报告。
3、产品需求列表
这个列表并不一定是文档，但是他非常重要。它是将新产品拆分成几个大的模块，并将这几个大模块再细拆分成各个功能点后形成的功能列表。它的用途是将整个产品的工作量化，利于设计师、开发人员、测试人员评估自己的工作量，利于开发过程中对各个功能点进行跟踪，不遗漏，利于产品测试时对产品进行全面覆盖。
4、产品说明书
产品说明书是目前很多公司中最常见，他主要包括产品功能的详细描述，产品所需要的开发、运行环境，性能要求等等。准确的讲，这份文档并不应该包含具体的交互内容。这个文档面向的是项目的全体成员。
5、交互设计说明书
交互设计说明书对整个产品的界面结构、交互流程进行详细的描述。它一般包括需求分解、竞争产品分析、流程说明、页面布局说明等内容。交互设计说明书的格式众多，灵活性也相当高，但目的都是将产品的结构和及流程形象化。交互设计说明书主要面向开发人员和测试人员。
很多公司将交互设计说明书和产品说明书结合在一起进行撰写，其实这种做法并不是十分合理。通常情况下，产品和设计结合的文档结构非常庞大，非常不利于查阅，也不利于撰写，而且这种结合文档的很多内容对特定人员是无用的。
6、交互设计规范
交互设计规范主要是用来规范新产品中常规的功能、操作等内容，比如页面的标题规范、界面快捷键操作的规范、提示反馈信息的规范等等。
7、视觉设计规范
视觉设计规范主要是规范新产品中一些视觉元件的样式、页面边距相对边距、通用界面的页面框架等等，开发人员根据规范就可以自行开发一些通用界面。
8、开发文档
开发文档包括一些需求分析、系统架构分析、数据库分析、开发日志等等内容。开发文档主要用来作为开发团队的技术沉淀。
9、测试用例
测试用例指对新产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
10、产品评估报告
产品开发完成后，应由测试人员撰写一份评估报告，对产品功能的实现情况、性能情况、bug解决率等问题进行综合说明和评估，来确定新产品是否符合发布标准。
上面的这十类文档是非常理想化的项目中才具备的，也并不是适用于所有的项目开发，但是，产品说明书、交互设计说明书、测试用例等几类文档是一个项目中不可能缺少的，他们是一个项目有效运行的核心文档。
1,982次浏览，本文来自: 开发新产品所需要的十类文档
2007年10月26日 星期五 15:57
对我正在做的东西有点用。但他与敏捷开发模式是否有本质上的区别？
[回复此评论]
2007年10月26日 星期五 15:57
沙发
[回复此评论]
2007年10月26日 星期五 16:01
@空格
这不是一种开发模式。而是与开发模式独立的另外一种思路。
这些文档对于各种开发模式都有用，对敏捷开发来说，一个迭代阶段可能不会有那么多的文档，但是多个迭代后，这些文档应该齐全。
[回复此评论]
2007年10月26日 星期五 16:01
《Communicating Design》里面也有10种~
Personas 角色设计文档
Usability Test Plan 可用性测试计划
Usability Reports 可用性报告
Competitive Analysis 竞争分析
Concept Model 概念模型（概念图）
Content Inventory 内容清单
Site Maps 站点地图
Flow Charts 流程图（交互流程图）
Wireframes 线框图
Screen Designs 视觉设计、原型设计等
[回复此评论]
2007年10月26日 星期五 16:03
@小甲
这十种我都给归类到了用户研究报告和交互设计说明书两类中去了。。。
[回复此评论]
2007年10月26日 星期五 18:32
你需要的是进行多少中目标驱动的工作，而不是写多少个文档。
所谓对各种模式都有用的说法是没经过思考的，比如视觉设计规范在很多情况下就完全不需要，以至于某些时候产品需求列表都不需要存在。
[回复此评论]
2007年10月26日 星期五 18:43
@ozzzzzz
我很负责任地告诉你，你这是很狭隘的开发思维。
我承认你说的目标驱动工作的重要性，而文档却是载体，口头的即时聊天的内容都不能驱动。
另外，如果很多情况下不需要视觉规范，会带来产品设计的不精致，最终倒霉的是产品。
[回复此评论]
2007年10月26日 星期五 22:40
虽然在实际运作中不是每一个文档都非要不可，但有些还是必须的：）这对整个项目的掌控和项目完成后的一些工作都有利。
[回复此评论]
2007年10月28日 星期日 14:06
5、6、7可以合成一个为：交互设计文档
可以增加：低、高保真交互原型 AND 原型评估文档 再生成交互设计文档，用于指导开发。
程序设计可以走CMM流程、可用性可以走UCD流程，将两者结合即可。
[回复此评论]
2007年10月29日 星期一 09:51
我觉得还是蛮受用的，不过根据具体情况肯定会有变化。比如视觉规范和交互规范，可以写在交互文档或者产品说明里面；一些情况下用户调研文档可能会被省略……
[回复此评论]
2007年10月29日 星期一 10:13
@shiJun zhang
5、6、7可以在小型项目中结合，大型的项目中还是要适当分开。
交互原型可以以交互设计说明书的附件形式存在
@Ami
其实很多文档不是必须的，需要根据实际情况来权衡使用。
ps，能受用就是对我最大的鼓励，哈哈。
[回复此评论]
2007年11月06日 星期二 07:55
@Banlon
我也很负责的告诉你，你的说法很无知。
很多产品根本就没有外观，你搞啥视觉规范。比如你搞一个嵌入式的算法，你视觉个啥。
文档可以做目标的载体，也可以做干扰目标的载体。其起的作用关键不在于你是不是有这些文档，而在于你是否能够在合理的成本下维护好这些文档。别的不说，保持文档的统一性就不是个小课题，而文档转化和跟踪也难度不小。
而实际上产品说明书在有些时候都可能不是必须的，更何况是交互设计说明书了。唯一在存在编码的项目中（你别否认有些时候项目根本就进入不了编码建造这个过程而仅仅是在风险评估阶段就被砍掉了）必须存在的是test case，而这个test case是不是必须形成一种所谓的正规化文档，则完全是项目组织自己的选择。至少在大多数敏捷团队中，是根本不需要把test case形成这样一个文档的，普遍的情况是把这些test case和需求以及验收和测试在一个合适的工具的支持下（比如wiki），建立起一个有机的联系体。
既然你这么喜欢文档，等我开文档写作课的时候，你可以来交学费。
[回复此评论]
2007年11月06日 星期二 09:56
@ozzzzzz
我很想知道你是做什么的？怎么会这么无视文档的存在。
我在上面的评论中都说及并不是每一个文档都是必须的，要根据不同的项目来确定，请你看清楚再评论。
另外，希望你以后评论注意言辞，下次我就会删评论了。
[回复此评论]
2007年11月06日 星期二 22:41
你可以当我就是找茬打架的。我觉得一个人的观点不应该受其身份和地位的限制。
其实在你改过帖子之后，我就懒得发言了。只不过不喜欢你教训的口气，更不喜欢别人说我思维狭隘。
你随便删你的，这里是你的地盘。我要不是查资料一时高兴，我才懒得在你这里发言。因为我确实再没有兴趣和cmm拥趸讨论任何问题。
[回复此评论]
2007年11月10日 星期六 22:05
ozzzzzz 可能是工程师，或者项目经理。
在项目管理的角度，对产品不需要这么细致的操心。没有user case前提的test case可能做的很好，前提是工程师经验丰富，足够以用户为中心，可惜我没有碰到过。
在项目主导产品的思路下，完全没有“产品管理”的余地。
[回复此评论]
2007年11月16日 星期五 09:57
归纳得很详细，其实，如果认同以用户为中心的产品设计和管理理念的人应该是觉得不错，不认同就难说了，这不是要不要文档的争论，而是理念上的分歧，一时半会还难以解决，就跟这些文档计划一时半会还难以实施一样。
一些小项目小团队不可能做到，但是，对大的软件产品文档是必须的，文档本身不能解决问题，但文档是工作成果的载体，有助于过程控制和成员沟通。
[回复此评论]
2007年12月21日 星期五 16:28
总归很全面，但大家不要机械的做！先搞明白写每个文档的目的，形式是次要的。载体却是必须的，千鸟好像说过，别一不小心成了炮灰。交流的平台（体现的载体）是必须的。
[回复此评论]
2008年03月26日 星期三 16:08
汗，在工作中竟然查资料竟然查到师兄弟个人博客。
赞一个。。。。
[回复此评论]
2008年03月27日 星期四 17:23
@lingche
呵呵，希望对你有用。
[回复此评论]