产品发布文档清单


产品发版时需要哪些文档,用来做什么用?

我们的新产品要发版了,产品的发版除了软件功能本身之外,我们还是需要有一系列配套的文档去支撑我们的售前、交付、服务、项目开发,毕竟只有前期的文档准备到位了之后,我们的下游团队才能做到具体项目上才会能说“心中有数”!

目前项目开发、 实施&服务团队初步梳理了一下文档的内容,发现这这个清单还是很长,这么长的一个清单,如何让我们的产品能够快速迭代,如何做到敏捷呢?这对于我们目前的产品团队也是一个非常犯难的事情。

在这个问题上,建议进一步思考:按照不同的产品生命周期做管理。如果对于孵化期产品可以不要求这些文档,因为这个时候产品还不成熟,且也没有太多的业务积累可以提供这些文档,唯一的方法就是产品团队直接进入到项目中和实施团队共同面对客户需求进行完善,这个时候还算是在产品的“实验室”中,还需要产品团队主刀做完善的,因此可以不需要讲究这些,要的就是产品做快速迭代与完善;如果是成长期的产品,应该一些关键文档是需要提供给到区域、项目开发了,因为这个时候产品团队参与的项目主要是业务方案的部分,实际业务交付、项目开发都已经给到其它团队了,只要有任务的移交就一定要有文档的输出,这个应该是大原则!


序号


交付件名称


是否必需品


交付件说明


交付件主要用途


如果不提供该交付件对项目的影响


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



核心业务模板(例如主项计划模板、成本控制科目模板等)


售前演示、系统功能学习


只有空库,需要花费很大精力做演示数据,效率低,演示效果无法保障

       
时间: 2024-10-07 05:55:24

产品发布文档清单的相关文章

【产品】好的产品需求文档(PRD)怎么写?

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚. 通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识.如何才能写出好的PRD,让产品研发团队成员,开发.测试.运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题.也有人可能认为PRD只要中心思想

产品需求文档(PRD)到底怎么写?

做产品经常会写PRD,但是如果没有一套完整的写作思路和框架,写出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发.前端.测试吐槽.趁这个周末有空,来梳理下一下写PRD的逻辑. 一.什么是PRD? PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档.该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档.当然,这个定义针对的是一个全新的产品.广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位.目标市

产品需求文档(PRD)的写作方法

无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前四篇文章进行整体的摘要介绍,帮助大家快速了解写作流程. 产品需求文档(PRD)的写作 四篇章:1.写前准备(信息结构图)2.梳理需求(产品结构图和用户流程图)3.原型设计(手绘原型,灰模原型,交互原型)4.撰写文档(PRD文档)5.用例文档(UML用例图.流程图) 1.写前准备(信息结构图):http://tangjie.me/blog/52.h

顶级产品经理是如何写产品需求文档(PRD)的

产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现,作用是"对市场需求文档(MRD)中的内容进行指标化和技术化",PRD质量的好坏直接影响到研发部门是否能够明确产品的功能和性能,是否能够研发出符合预期的产品,所以PRD也是体现产品经理专业程度的一个重要指标. 可以理解为,PRD是产品经理关于产品功能的宣导和传达,它通过清晰扼要的表述将产品意图呈现给阅读者,PRD的阅读者一般包括开发人员,设计

产品需求文档的学习记录(一)

PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google.PRD文档是基于BRD.MRD的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员.在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员.相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是

PRD产品需求文档

什么是PRD? PRD是Product Requirement Document的英文缩写,即产品需求文档的意思.PRD昰产品流程中的最后一步工作,是将原型中的功能.界面具象化描述,是提交给设计(UI).技术和测试部门的执行标准.一般由产品经理亲自完成,如果有产品专员(助理)的话,由他们主要完成其实更好. PRD应包括哪些内容? PRD的标准很难衡量,因团队而异,只要能够明确传达产品需求的文档都是合格的.但一般需要包含以下四个部分: 1.产品概要:说明产品目标.需求来源.主要项目负责人和产品整体

产品需求文档的学习记录(四)

前三篇文章我们逐步梳理了产品的信息结构.框架结构.界面结构(原型),这一步我们就要根据之前完成的工作,开始正式撰写产品需求文档了(PRD文档). 通过之前的准备工作,我们更加清楚了产品的需求,并细致的考虑了方案的可行性,从而减少与避免了撰写文档时容易忽略的细节黑洞. PRD文档没有标准的规范,也没有统一的模板,每个公司都不一样,并且每个人也不一样,这个取决于个人习惯和团队要求.虽然PRD文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录.文档在撰写过程中,我们可以自行不断的修改

程序员爱看的产品需求文档,转给你的产品经理

假如产品需求文档(PRD)是一个产品,如何做出一个拥有良好用户体验的PRD? 让我们先来考察下PRD的用户群体(User Persona):主要是开发人员,在繁忙的开发任务中最希望看到"简洁易懂"的产品需求文档. 梳理下PRD的功能:传达出产品需求:管理记录产品迭代过程:各部门共享产品信息,以促进沟通: 因此一个好的PRD的原则是:结构清晰:语言简洁易懂:实时共享. 我们具体如何制作? 一个PRD文档即可 现在,越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式,因为之前

如何写好产品需求文档?

常常有人问我怎么写prd,在深受市面上流行的功能需求模板“残害”之后,我现在一般不会向别人推荐任何所谓的“模板”. 需求文档是产品需求的表达方式,而其中需要描述什么内容取决于产品经理想要描述什么,即产品经理的需求.如果产品经理的需求是明确的,而且产品经理脑中有物,那么需求文档自然而然就出来了.最可怕的是产品经理自己都不知道自己要描述的是什么内容,这个时候即使有模板,写出来的东西也是一团糟. 互联网产品以用户为中心,所以prd也应该站在用户的角度来描述,如果不知道自己要写什么,在写文档之前产品经理