技术研发中心产品维护工作规范.docx

技术研发中心产品维护工作规范.docx

《技术研发中心产品维护工作规范.docx》由会员分享，可在线阅读，更多相关《技术研发中心产品维护工作规范.docx（8页珍藏版）》请在冰点文库上搜索。

技术研发中心产品维护工作规范

产品维护工作规范

2007-3-23

1.概述

1.1目的

制订统一的产品维护工作规范，确保维护工作的高效执行，保证客户能得到高质量的产品服务。

1.2维护范围

适用于公司已经发布并在运营的产品的维护工作。

这些产品相关的维护工作，可能由多个事业部或中心承担，本文只说明由技术研发中心承担的维护工作的要求。

产品，包括外部客户使用的产品（如E-Boss），也包括内部客户使用的系统（如CEMIS）。

本文不涉及网站上线后，技术研发中心为网站制作或改造栏目、修改页面等维护工作。

本文不涉及为客户订制的项目的维护工作。

2产品维护工作规范

2.1.对于维护团队的要求

2.1.1.维护团队的建立

产品发布/上线后，技术研发中心业务领域组建维护团队。

可以按照不同的产品组建不同的维护团队，也可以在业务领域内建立一个维护团队负责多个产品的维护；

1.维护团队包括：

维护工程师、维护组长。

维护工作的领导职责，由业务领域总监承担。

负责产品开发的项目经理，应对维护工作提供支持；

2.产品发布/上线后一周内，维护组长将维护团队的人员名单、通讯方式、维护工作内容与职责等通报给产品事业部相关人员（产品总监、产品经理、客服总监、客服经理、运营总监、运营经理等）、技术运营中心相关人员（运维总监、运维经理等），并抄送技术研发中心总经理和QA

工程师。

在定义维护工作内容与职责时，应与产品经理、客服经理、运维经理等共同协商后确定，并形成《技术研发中心维护团队工作内容与职责》文档。

如果可能的话，推动形成统一的文档，定义各个不同部门对于某个产品维护工作的具体职责、响应速度、问题反馈和升级流程等，以便提高整体的维护效率；

3.维护团队在接收产品/系统时，要检查研发团队提供的维护文档是否齐全、正确。

如果可能的话，应按照文档进行操作，以便及早发现文档中的问题，并要求研发团队更正。

另外，维护团队还可以要求研发团队提供培训手册、培训PPT，并进行专门的培训，以保证维护团队尽早熟悉待维护的产品/系统，便于提高维护能力；

4.维护工程师最好为专职人员。

如果维护量不大，由开发人员兼职维护，则应明确维护工作是其第一职责。

2.1.2.维护团队的变更

1.只要相关产品还有客户使用，维护团队就要保留；

2.为提高维护效率，维护团队应尽可能地稳定。

如调整维护工程师，维护组长应在调整的当天用邮件通知上述相关人员；

2.1.3.维护团队的工作性质

维护工作大致分为两类：

1.不涉及程序修改的日常维护，见第2.2部分；

2.涉及程序修改的应用维护，见第2.3部分。

2.2.日常维护工作规范

2.2.1.日常维护的内容

日常维护，指不修改程序的维护工作。

包括但不限于下述内容：

1.技术支持：

对于客服人员、运维人员不能解决的技术问题，提供支持、解决问题；

2.咨询服务：

提供产品相关方面的咨询服务；

3.技术配合：

协助技术运营中心完成系统升级前的评估，并协助升级等工作；

4.其它不修改程序的工作。

2.2.2.日常维护的级别

根据产品性质的不同，可以定义不同的维护级别（如：

5工作日*8小时、7天*24小时等）。

维护级别的定义，由维护组长与产品经理及其他相关人员讨论后，由产品总监、业务领域总监、运维总监等共同确定。

2.2.3.日常维护的问题来源

1.维护问题可能来源于客服、运营、运维、分公司等各个不同的环节。

各环节应根据《技术研发中心维护团队工作内容与职责》，初步判断问题是否属于研发中心维护团队的工作内容后再进行问题的分配，以便提高问题反馈和解决的效率；

2.来源渠道可能包括：

投诉系统、运营咨询平台、邮件、电话、即时通讯工具（QQ、MSN、IM等）等；

3.为提高综合效率并进行问题的汇总管理和分析，应尽量使用统一的平台（如投诉系统）进行问题报告。

在遇到紧急问题时，客户或分公司可直接与维护组进行电话或邮件沟通。

但问题处理完后，还应将问题补录到统一平台中以便查询。

如果没有统一平台，维护工程师需要在维护日志（见2.2.5中的《维护工作管理表》）中详细记录；

4.问题提出者，在描述问题时，应明确客户信息（如客户名称、联系方式、职务、FTP地址等）、问题详细信息（如产品名称、出问题的模块、问题现象等。

应尽量提供造成问题的操作

步骤，每一操作步骤出现的现象，并尽可能多地提供截图）、分公司信息（如分公司名称、联系人、联系方式等）。

这部分要求，需要维护团队不断地向相关环节灌输；

2.2.4.日常维护的处理要求

1.首问负责制：

无论问题的提出方式如何，第一个收到问题的维护工程师是问题分析、解决、跟踪和反馈的负责人；

2.及时响应：

维护工程师在问题提出后30分钟内，必须进行问题响应。

1）为此，要求维护工程师至少每30分钟登录一次系统平台（如：

投诉系统和咨询平台），以便及时发现新提出的问题，并在系统中响应；

2）对于用电话、邮件、或即时通讯工具等方式提出的问题，也应该在30分钟内进行响应。

其中，重要的问题，应该用邮件反馈；

3.问题分析与预计解决时间反馈

维护工程师根据《技术研发中心维护团队工作内容与职责》，分析问题是否在维护组的工作范围内。

如果不是，转给相关部门处理，并反馈给问题提出人员。

如果属于维护组的工作范围，判断问题的解决时间并反馈，然后再进行问题的解决；

1）如预计4小时内能解决，则维护工程师直接反馈给问题提出人员；

2）如预计处理时间超过4小时，则维护工程师还应向维护组长报告；

3）如预计处理时间超过8小时，则维护工程师应向维护组长、业务领域总监报告；

4）对于个别问题，可能难以很快地预计处理时间。

则在响应的时候，可以做一些特殊说明，并告知大约会在多少时间内给出解决时间；

注意：

1）处理某些特殊问题时（例如：

修改客户数据或者对客户数据库进行操作、或者需要禁用某个原有的功能），维护工程师应提出申请，由维护组长审批后进行。

必要时，提请业务领域总监、产品部门相关人员（产品经理、商务经理、客服经理等）审批后进行；

2）对于涉及到改动程序的问题（如：

程序Bug、需求变更/新增需求等），告知问题提出人员应执行“应用维护工作流程”，并将问题转给产品经理。

4.问题解决、解决结果反馈及问题升级

1）维护工程师负责问题的解决。

在解决过程中，如果需要各方面的支持和配合，则沟通、协调和跟进工作，由维护工程师负责。

如果存在配合问题，维护工程师应及时反馈给维护组长、配合人员的领导和QA工程师等相关人员；

2）如果在预定的时间内，问题得到解决，则维护工程师应在第一时间反馈给问题提出人；

3）如果在预定时间内没有解决，则维护工程师应在预定时间到来前，向维护组长报告，再次预计问题的解决时间，并反馈给问题提出人；

4）如果第二次问题仍没有按时解决，则维护工程师应在预定时间到来前，向维护组长、业务领域总监报告，再次预计问题的解决时间，并反馈给问题提出人；

5）如果第三次问题仍没有按时解决，则维护工程师除了向上述人员报告外，还应抄送研发中心总经理；

6）对于来源于投诉系统、咨询平台的问题，通过系统反馈给问题提出人，用邮件报告给维护组长、业务领域总监等人约；对于来源于其它渠道的问题，均用邮件反馈；

5.问题关闭

1）维护工程师反馈问题已经解决后，由问题提出人跟踪、验证问题的解决效果，并反馈；

2）如问题得到有效解决，则问题关闭；

6.问题检查

1）维护组长应每天检查投诉系统、咨询平台或维护工程师的维护日志（见下文中的《维护工作管理表》）。

如发现有延期未解决的问题，须立即进行处理；

2.2.5.日常维护记录的管理

1.维护日志：

1）维护工程师使用《维护工作管理表》做好维护日志。

《维护工作管理表》的基本内容包括：

问题描述、现象、原因、解决方法等，不同业务领域的表单可以自行定制；

2）维护工程师将处理的问题记录在《维护工作管理表》中，每天下班前更新到CVS库中；

2.维护日志分析报告和产品维护FAQ：

1）维护组长定期（每周/每月）组织对《维护工作管理表》的分析，形成分析报告。

以邮件的方式发送给产品经理、产品总监、项目经理、业务领域总监、运维经理等；

2）分析报告中，除了对问题的解决情况进行统计、分析外，还要说明常见问题、原因、目前的解决方案以及在未来版本中的改进建议等；

3）维护组长根据上述分析结果，更新CVS中的产品FAQ，并提交产品经理、运维经理、客服人员等；

3.QA工程师每月抽查《维护工作管理表》、维护日志分析报告和产品维护FAQ的更新情况。

2.3.应用维护工作规范

2.3.1.应用维护的内容

应用维护，指需要修改程序的维护工作。

包括但不限于下述内容：

1.产品本身的Bug修复；

2.产品本身的需求变更或新增需求的处理；

3.产品的外部接口开发或改造；

4.开发必要的产品维护工具，提供给运维人员或其他相关部门；

2.3.2.应用维护的管理要求

由于应用维护涉及到程序修改，为了保证软件系统的质量以及文档与最终系统的一致性，对于应用维护应该执行较严格的流程：

1）一般来说，应用维护工作应执行《产品作业流程》中规定的要求（从：

需求分析、设计、开发到测试、发布）

，但是部分工作可以简化或者裁减；

2）但是，对于工作量小于1个人月、且不涉及数据库或基础框架修改的应用维护工作，可以由产品经理使用《维护任务单》提出维护任务，由项目经理或维护组长确认后，即可执行。

项目经理或维护组长，应考虑代码质量保证的方法、需要提交的文档等，并确保代码、文档纳入配置库统一管理。

维护任务的验收，由产品经理负责组织。

QA工程师每月抽查《维护任务单》，查看代码、文档在配置库中的更新情况。

3）采用任务单方式，相对于完整的开发、测试来说，速度可能会提高，但是也存在质量风险，从长远来看综合效率不一定会提高，因此不宜大量使用。

3对配合部门的要求

技术研发中心维护团队在工作过程中，可能需要其他部门（如：

技术运营中心、客服中心等）的支持和配合。

如果他们的工作不到位，也可能会影响整个问题的解决时间，因此在此处简单提出对配合部门的要求：

1、及时响应：

对于维护团队提出的问题，应在半小时内响应。

告知：

（1）维护团队提出的问题，是否属于他们的工作范围？

（2）如果是，多长时间解决？

或者，多长时间能完成相关工作？

2、及时反馈：

如果按照计划完成相关工作，应及时反馈给相关人员。

如果不能按照原计划完成工作，则反馈还需要多长时间完成工作？

等等。

如果配合部门没有及时响应或及时反馈，技术研发中心维护团队应主动沟通。

当问题较大时，应提请业务领域总监、配合部门总监共同讨论解决方案。

4记录

1.《技术研发中心维护团队工作内容与职责》

2.《维护工作管理表》

3.《维护任务单》

部分没有采纳的意见

1.及时响应部分：

由于维护工程师工作的多样化，对问题的响应未必在规定具体时间段内，只是保证尽可能及时。

--原因：

维护人员如果不是全职的话，可能不太好保证；担心与考核挂钩；

2.问题解决中，无须多次重复预计时间及报告，这样会浪费好多宝贵的时间和精力；

3.维护工作还是建议有个专门的维护部门为好，这样工作职责清晰，避免了开发人员不愿意从事维护工作的问题。

4.首问负责制　不太符合公司目前的投诉处理流程，除非研发中心处理流程中先由维护组长划分投拆到个人身上。

5.维护上的人员应该建立第二责任人的制度，专人专岗不太适合我们目前的情况。

6.对于应用维护确实需要完善流程，目前的规范描述比较简单，最好能再详细一些。

--需要考虑。

【本文档内容可以自由复制内容或自由编辑修改内容期待你的好评和关注，我们将会做得更好】

感谢您的支持与配合，我们会努力把内容做得更好！