|
• 对接收的故障进行分析、定位、修复、验证和发布。
• 记录发布各地产品的版本信息。项目管理者联盟
值得注意的是：维护梯队各层角色都需要项目管理者联盟
• 收集、分析、共享各自发现的故障blog.mypm.net
• 各自都需向外层进行培训。项目管理者联盟
因为只有共享各层发现的故障和故障的分析结果才能将信息完整地传递到各层，使各层根据每层的实际情况做好解决并杜绝同类问题的发生。项目管理者联盟
每层对外层的培训一方面可以最快速度地去解决问题，不使问题扩大化;另一方面也可以有效减轻本层的工作压力。最外层可以对用户进行培训，以减少因为误操作或是不理解产品而造成不必要的问题或投诉。
另外：我们还应在各层角色职责中关注一些词汇，这些词汇要有明确的定义，有些最好可以量化的判断，比如：项目经理圈子
• 什么叫常见故障?这些常见故障可以记录到维护手册中，所以我们要关注产品故障手册的更新。项目管理者联盟
• 什么叫成熟的工具?维护的工具有时是可购买的，有时需要自己研发。维护工具的使用可以大大降低维护成本。现在的互联网公司就非常重视这方面的研发。项目管理者联盟
•
对于各层角色来讲，什么是不可解决的故障?因为只有及时确定在本层是不可解决的故障才能尽快通知内层来解决，不要耽误故障解决时间。这个最好有量化的标准，比如：从时间上，或是重大故障的定义。项目管理者联盟
• 什么是及时通知?多长时间内是及时通知，以什么形式通知，如果特殊情况(如节假日等)如何处理，什么情况下算是通知到了等等。PgMp.mypm.net
• 各层接口人是谁?每层都应有固定定义的接口人，以便培养这些接口人的应急能力和故障信息传递的即时性和准确性。项目管理者联盟
•
版本信息是什么?现运营版本信息、修复补丁版本信息以及前一个稳定版本的信息(可能会回退)。如果产品发布到各地市的版本不统一，还要及时获取故障点产品的版本的信息等等。项目管理者联盟文章
那么这三层维护角色如何运转，如何能很好的衔接呢?请各位接下来了解一下维护的流程。项目管理者联盟
项目管理者联盟
图 二
图二是三层架构工作的简单流图。从这张图可以看出，问题由现场工程师-〉技术支持工程师-〉产品(线)技术人员依次进行流转。 项目管理者联盟
图 三
图三是传统三层角色进行维护工作的详细流程图。流程图中红色三角标识的是这个点应有量化的判断依据。比如：什么叫解决或不能解决?什么时候必须要到现场解决等等。有了这些可量化判定的依据，才好准确判断下一步应该如何走。项目管理者联盟
那么对产品开发和产品维护两个团队的工作如何区分呢?图四是某些公司两个团队工作界面的区分。项目管理者联盟
项目管理者联盟
图 四
在图四这个流程中，有一个预发布环境。这个环境是在开发完成之后，正式发布前的一个中间环节。这个预发布环境是有维护团队管理，由开发团队将开发完成的产品交付维护团队，维护团队根据实际发布环境进行部署、测试。测试、验证通过后才发布到发布(运营)环境。这个预发布环境就是维护团队与开发团队的一个切分界面。blog.mypm.net
那么对于互联网公司，又该如何进行产品的维护工作呢?大家可以参考图五进行了解。 项目管理者联盟
图 五
大型成熟的互联网企业往往更加重视发布、维护、运营自动化平台，这可以提升产品质量和需求、问题的响应速度以及大大降低人工成本。每发布一个产品版本时都会在发布任务单中记录待发布版本和上一个发布的版本(这个主要是便于回滚到原来的版本)。在运营中产品出现问题，将自动对这些问题的严重程度进行判断，如果达到回滚标准就会发信息给指定人员处理，并有专人进行确认和执行回滚操作。这其中明确的回滚判定标准是非常关键的，直接影响问题解决的准确性。项目管理者联盟
对于产品在运营中的监控、判断系统不仅在互联网公司比较完善，在传统的大型成熟企业，比如：电力、电信、银行等也是如此。图六就是某个企业监控系统的示意图。项目管理者联盟
项目经理博客
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
