|
产品发版时需要哪些文档，用来做什么用？
我们的新产品要发版了，产品的发版除了软件功能本身之外，我们还是需要有一系列配套的文档去支撑我们的售前、交付、服务、项目开发，毕竟只有前期的文档准备到位了之后，我们的下游团队才能做到具体项目上才会能说“心中有数”！
目前项目开发、 实施&服务团队初步梳理了一下文档的内容，发现这这个清单还是很长，这么长的一个清单，如何让我们的产品能够快速迭代，如何做到敏捷呢？这对于我们目前的产品团队也是一个非常犯难的事情。
在这个问题上，建议进一步思考：按照不同的产品生命周期做管理。如果对于孵化期产品可以不要求这些文档，因为这个时候产品还不成熟，且也没有太多的业务积累可以提供这些文档，唯一的方法就是产品团队直接进入到项目中和实施团队共同面对客户需求进行完善，这个时候还算是在产品的“实验室”中，还需要产品团队主刀做完善的，因此可以不需要讲究这些，要的就是产品做快速迭代与完善；如果是成长期的产品，应该一些关键文档是需要提供给到区域、项目开发了，因为这个时候产品团队参与的项目主要是业务方案的部分，实际业务交付、项目开发都已经给到其它团队了，只要有任务的移交就一定要有文档的输出，这个应该是大原则！
|
序号
|
交付件名称
|
是否必需品
|
交付件说明
|
交付件主要用途
|
如果不提供该交付件对项目的影响
|
|
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、 缺少渠道，对于公司新的产物不了解。
|
|
序号
|
交付件名称
|
是否
必需品
|
交付件说明
（具体内容建议定时间派代表与产品人员一同协商）
|
交付件主要用途
|
如果不提供该交付件对一线的影响
|
|
1
|
发布及升级公告
|
是
|
|
了解最新版本信息，及更新内容
|
无法获取升级与旧版的差异
|
|
2
|
产品功能清单
|
是
|
|
合同附件附带
|
合同附件与交付产品不一致。
|
|
3
|
产品更新说明
|
是
|
与上一版本的差异点，主要更新点，业务上及软件上都要
|
了解最新版本的更新信息
|
无法获取升级与旧版的差异
|
|
4
|
产品理念PPT
|
是
|
售前介绍PPT，介绍产品的亮点功能
|
1、新功能的业务背景了解；
2、产品实施环节给客户做产品理念宣讲用到；
|
1、无法推广新产品，一线不理解新产品理念；
2、无法了解产品亮点以及产品功能业务背景；
|
|
5
|
测试报告
|
否
|
包含性能测试报告
|
1、客户要求；
2、售前用得到，客户IT高层会有要求；
|
1、如客户无要求无影响，可考虑不与产品一起交付，但需要时能够及时提供；
2、无法消除客户对于产品平稳运行的担忧；
|
|
6
|
否
|
功能测试报告
|
|
7
|
否
|
系统安全资质认证
|
|
8
|
否
|
压力测试报告
|
|
9
|
产品操作手册
|
是
|
要包含新版本功能说明
|
新功能操作说明
|
无法了解新功能操作，需要各自摸索
|
|
10
|
问题集
|
否
|
包含各子系统
|
1、碰到问题查询解决办法；
2、快速定位问题，提升问题处理效率；
|
1、非必选，遇到问题需要找人咨询，处理问题流程会增长；
2、无影响，目前一线也会自己积累问题集；
|
|
11
|
实施交付运维服务配套文档
|
是
|
交付指引
|
1、新人培训，系统功能交付标准参考；
2、指导新产品实施交付；
|
一线交付难度大，尤其对于不理解的新产品，交付难度非常大，模式可参考采招258发布时的交付指引。
|
|
12
|
建议有
|
产品培训PPT&录像
|
1、标准操作，可提供客户；
2、给一线作为参考，形成客户自己的培训资料；
|
如没有，客户要求则要顾问自行录制。
|
|
13
|
是
|
测试用例场景
|
客户要求，系统上线完成功能验证，需要安排场景的测试用例。
|
建议提供，客户要求还是比较普遍。如无会造成客户对新产品不信任。
|
|
14
|
是
|
数据结构
|
制作报表查询
|
降低报表制作效率，尤其是涉及新功能报表
|
|
15
|
Demo数据库
|
是
|
演示数据库
|
售前演示、系统功能学习
|
只有空库，需要花费很大精力做演示数据，效率低，演示效果无法保障
|
|
16
|
是
|
核心业务模板（例如主项计划模板、成本控制科目模板等）
|
售前演示、系统功能学习
|
只有空库，需要花费很大精力做演示数据，效率低，演示效果无法保障
|
|
| |
|
|
|
原文：http://www.cnblogs.com/a311300/p/4623443.html
