只要有任务的移交就一定要有文档的输出，这个应该是大原则！
|
序号 |
交付件名称 |
是否必需品 |
交付件说明 |
交付件主要用途 |
如果不提供该交付件对项目的影响 |
|
1 |
产品设计文档 |
是 |
1. 功能设计文档 |
1. 需求评估时，查看相关功能设计 |
1. 需求容易出现遗漏，特别是一些变化较大产品 |
|
2. 数据库设计文档（枚举类型的需要每个值所代表的意义） |
2. 数据库取数或者BUG查证时，便于进行数据核对 |
2. 开发效率低，需要不停的咨询他人 |
|||
|
2 |
报表设计器，新工作流操作手册等 |
是 |
1. 基本的配置和操作指引 |
1. 报表快速开发 |
遇到问题，只能靠自己摸索和寻求他人，效率极低 |
|
2. 工作流站点的快速配置，遇到问题时可以查找 |
|||||
|
3 |
业务解决方案 |
是 |
1、 功能的由来。（比如计划系统的会议管理模块，是基于什么原因增加的） |
1、 学习新系统时，快速掌握客户实际业务 |
1、 不清楚功能加了有什么用。 |
|
2、 业务流程图 |
2、 如果项目上需要对功能进行调整，不清楚在业务上有何影响。 |
||||
|
3、 CP点说明 |
|
||||
|
4、 管理价值 |
|
||||
|
4 |
功能规格设计书 |
是 |
1、 必须是按新功能进行描述，不能像之前那样增量描述。 |
1、 评估新版本需求时，能通过该文档查询现有功能的具体情况，减少直接的代码阅读工作。（对于标准版的，可以不用看代码，直接以该文档为准） |
1、 只能通过代码去理解现有系统是什么样的，效率低。 |
|
2、 描述清楚数据流向 |
2、 学习新系统 |
||||
|
3、 描述清楚业务逻辑 |
|
||||
|
4、 描述清楚系统流程图 |
|
||||
|
5 |
数据结构 |
是 |
1、 表关系。 |
1、 学习新系统时，梳理数据关系。 |
1、 只能通过代码去理解现有系统是什么样的，效率低。 |
|
2、 数据字典。 |
2、 评估需求时，梳理数据关系。 |
||||
|
3、 存储过程。 |
|
||||
|
4、 视图 |
|
||||
|
6 |
Bug修复清单 |
是 |
1、 新版本修复Bug清单 |
1、 快速解决旧版本已知Bug |
1、 针对已知的Bug如果没有统一的、经过验证的解决方案，各项目团队修复时可能会产生因修复方案错误或不完整导致次生Bug |
|
2、 每个Bug针对各版本老产品代码级修复方案 |
2、 项目团队根据清单对旧产品Bug进行主动修复 |
2、 不知道老版本还有多少Bug，没有清单支撑主动修复 |
|||
|
7 |
可供客户直接更新的补丁包 |
是 |
针对大版本的补丁包发布时，需要产品团队制作一个可供客户直接更新的补丁包，而不是丢一堆文件放到服务器上(306 SP1) |
1、 对于未做过开发的新客户，可以直接使用补丁包升级，不需要项目再做一次升级包 |
1、 每个项目团队都要自己做一个更新包，重复劳动 |
|
2、 产品提供的补丁包目录存在大量的空文件夹和多余文件，删除有风险，不删除更新包过大 |
|||||
|
8 |
移动产品及相关文档 |
是 |
1、 微助手等移动产品随ERP一起发布，放到各版本下面 |
1、 方便找到ERP对应版本的移动产品，便于项目团队学习和客户上线开发 |
1、 现在微助手与标准产品分开发布，不清楚哪个版本对应 |
|
2、 移动操作手册、环境部署等相关的资料。 |
2、 新版本产品客户已经在用了，与之对应的移动产品未发布导致客户用不了 |
||||
|
3、 采用的框架及技术及相关资料 |
3、 缺少渠道，对于公司新的产物不了解。 |
