标签：
背景描述：目前在一家网站公司工作，2015年初研发中心部门改革，小组重组，被分配到了网站平台的维护组。下面内容是对近期维护工作的一个总结：
个人感受：以前也在老东家的团队也做线上系统的维护和新产品的研发，由于大家的认真负责，Leader的管理也很到位，线上的系统很少有bug反馈，不管是UI上迭代，还是系统逻辑的升级都很顺畅。
目前负责的平台运行了3年多，可能由于当时逻辑设计问题，也可能是执行问题，发现近期反馈的问题多是逻辑问题，在此对这些问题的原因不做探讨和深究，只是想讲讲面对线上问题的维护工作如何做，以及如何优化：
1， 对问题反馈流程的完善：面对客服、销售、营销中心不同部门的反馈，一定要建立反馈流程，不然5个人的支撑小组工作会很繁忙，并且接口人只有一个人。
没有流程就没有规范，也就没有后期调整的数据来源。
对流程的建立，起初可能会让以前没有走流程的人心理上有点不舒服，但长期看对工作效率是有帮助的；
2，对线上问题的优化级的判断规则与逻辑：
每个部门反馈来的问题，都说时间很急，想立马解决，可是小组的资源有限，不能让问题牵着鼻子走，要对bug的严重性、解决方案做预估，做工期整理；
由于小组职责的定位不清晰，导致现在对很多问题反馈都做处理，本来应该客服去解决的问题，小组成员在解决。
3，对线上系统维护工作和新产品研发任务的时间平衡：
众所周知，大家都喜欢做新产品，不喜欢维护旧有的系统，原因不言而喻，呵呵。
可是，线上系统的bug不修复，就是对用户的不负责。1个月4周的时间，至多2周的时间、资源、精力解决线上bug，保证至少有2周的时间来对新产品的研发。
~~~~~~~~~~~ 华丽的分割线 ~~~~~~~~~~~~~~~~~~
今天刚好看了一本书：《网站可用性测试及优化指南》，虽然是讲可用性测试的内容，但是读了2章发现对于线上系统的bug修复工作也有指导意义，下面摘录了几条观点：
1，对问题做优先级判断，优先解决最糟糕的问题；
方法：开小组会议，在问题清单中找出最严重的10个问题，然后提出解决方案并执行；
2，越少越好：修复问题时，投入越少越好；在快速修复和完美修复之间做取舍，目前针对我们小组的情况，我选择快速修复。
方法：1，微调，而不是重新设计；2，做减法；
写这篇帖子，用了30分钟，以后争取多写些帖子，针对技术、工作、生活，记录自己的成长！
标签：
原文地址：http://www.cnblogs.com/jimcsharp/p/4230615.html
