Feb 26

凤凰项目读后感 不指定

djangowang , 20:57 , 工作相关 » 学习笔记 , 评论(0) , 引用(0) , 阅读(1628) , Via 本站原创 | |
以下是转自我同事(dorisbhwang)的一片文章,凤凰项目读后感在发此博客前我本人还没有看,但在看了她读后感后更有兴趣来读一读这本书。



凤凰涅槃,浴火重生
正文之前,一个职场老司机的困惑…..
作为一个在职场上混迹长达14年的老司机,从制造业的咨询顾问转变为互联网行业运维质量管理人员(QA),对于我来说可谓是破釜沉舟,从零开始。理想是丰满的,现实是残酷的,投入到具体的运维质量管理工作后,发现我无法再以这么多年沉淀的方法论,以体系化、职业化的姿态来开展工作,尤其是对互联网行业运维体系的生疏,技术上的空白,简直就是致命的…
在困惑无助的瓶颈期,偶然机会运维界男神梁爷推荐看《凤凰项目》这本书,凤凰二字不禁让我想到了凤凰涅磐,浴火重生,自己此时需要的不就是重生吗?既然从零开始,放手一搏,学习吧!
言归正准,此书与各种介绍技术或方法论的书不同,以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程,浅显易懂,结合自己曾经经历的“难产”的项目(广东电信管线投资管理系统建设项目、HW配置器项目、HW PIA项目),仿佛身临其境,触动了身体上的多根神经,将触动我的几点总结下:

1、  变更管理
提到“变更”,我为之色变,变更无处不在,毫不夸张的说,我曾经被“变更”伤的很深,这是个忧伤的往事,此处省去一万字…首先为愿意正视在变更上存在的问题,并且愿意去为改变这种现状做出努力的管理者或决策者致敬,书中IT运维总裁比尔如是乎,接任总裁一职后,意识到IT变更中的问题,马上对变更流程做了梳理,
采取了如下的措施:
1)  梳理什么是变更,明确变更的范围(这与我想做的工作不谋而合)
附书中定义:变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作,并且这样的操作可能对相关服务产生影响。
2)  执行变更审核流程,加大变更门槛,适当控制变更节奏;
说到这点,不得不提任何流程及工具的推行都会遇到各种阻碍,有些员工乃至管理者甚至可能认为引入流程阻碍了效率,如果再碰到了不好用的工具,那简直炸天了,所以引入流程和推行工具之前必须根据实际情况做深入的调研,多方面平衡,力求流程简化,工作易用,当然这事说起来容易,做起来难,也只能是智者见智了。
3)  变更可视化
做好变更记录,明确变更计划的制定者、变更对象、变更内容;
做好变更计划安排,发布审批通过的变更执行的日程表。
这一点其实没什么好说的,既定的工作如果都不做好安排,随着性子想怎么玩就怎么玩,活该你一天到晚忙到死,还没干成几件事情。
总之,我们避免不了变更,但我们要想办法避免紧急变更。
说到此处,我脑中呈现了一个变更管理的框架:
点击在新窗口中浏览此图片
首先从业务层面要确定变更的痛点,想要如何管理,以上内容不需要面面俱到,可以根据痛点有重点的进行梳理,如果有条件,落地到工具中自然更好。

2、  工作类型梳理
记得我当初刚接手运维部门的QA工作之后,为深入了解运维工作,曾问过几个运维同事的日常工作分类和职责是什么,小伙伴们给的答案居然是含糊不清的,我不知道他们是真的不清楚,还是不善于总结说不出来,抑或是不想告诉我,囧…书中对IT运维部门的工作类型分为:业务项目、IT运维项目、变更及计划外的工作。人的精力是有限的,当各类工作一窝蜂的摆到眼前,谁也不能面面俱到,必要时必须要有取舍,确定不同时期的重心工作,正确的时间做正确的事情。结合实际的工作,身边运维同学对于业务项目和IT运维项目这两类一般能按照项目节奏按部就班的走,但一旦引入了变更和计划外的工作,往往会打乱既定的计划,承诺给业务部门的服务无法完成,所以工作的安排要留一定的buffer,以支持没完没了的变更和计划外的工作(如业务各种突发事件,各类运营系统的bug) 。希望这个工作类型的划分也能够触动身边运维同学的神经。

3、  开发运维模式下的实践
1)标准化
“IT工作不仅是无形的,因此更难追踪,而且可能出错的地方也要多得多。“
因此为了避免出错,需要更严格和守纪律,把运营环境标准化,并把这些标准应用于开发和运维的日常使用。写到这里,情不自禁叹口气,这是我目前的重点工作,曾经为这个目标迷茫过、困惑过,此书看完,坚定了我做运营标准化工作的决心。
2)持续优化
作为质量部过程改进中心的一员,持续优化天然是QA的职责,如何防止问题再次发生,一旦发生了问题如何更快的发现和修复问题,建立完善的问题管理机制的重要性由此可见。
3)营造一种工作文化
鼓励探索和尝试,从失败中吸取教训,反复实践,至于如何落实,我想是团队管理者仁者见仁智者见智了。  

4、  工作约束点
在书中,一个运维工程师是工作约束点,任何工作少了他都无法正常开展…我表示无语,居然会有这样的事发生!在我的经历中,某个人成为工作瓶颈的情况真不多见,不会说少了哪个人天能塌下来。我想团队分工、团队共享和人力储备这些是人员管理的根本吧(纯属个人意见)。 诚然,除了人这个因素,工作中会有各种障碍,反思下我们是否主动识别过约束点,如数据质量差、信息不同步、流程混乱等,识别到之后是否尝试去打破它?至于How,以后再深入学习探讨吧(偷个懒)。

Ok, 到这心得就完了,对于如何继续开展接下来的运营质量工作,我经历了从混沌状态到逐步清晰的过程,可谓是“凤凰浴火,涅槃重生”,路漫漫其修远兮,希望通过我的努力,能够看到质量上的不断的改进和优化,哪怕是一点点。



发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]