标签:
只要有任务的移交就一定要有文档的输出,这个应该是大原则!
| 
 序号  | 
 交付件名称  | 
 是否必需品  | 
 交付件说明  | 
 交付件主要用途  | 
 如果不提供该交付件对项目的影响  | 
| 
 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、 缺少渠道,对于公司新的产物不了解。  | 
标签:
原文地址:http://www.cnblogs.com/a311300/p/4623441.html