IT研发人员都很忙,天天加班是常态,但是如果问他忙什么,可能会是搪塞一下手头的项目。
《凤凰项目》中主人公逐步被引导找出四种工作类型,才知道自己的职责并注意应该如何管理工作,因此这个问题是第一位的,对于每位IT研发人员来说,当然每个IT人不太一样,但角度类似,其实也不只是IT工作。其他工作也可以参照。
两大类四种工作,第一类是计划内工作,第二类是计划外,很简单有点像废话。第一类又分三种:业务项目、内部项目、变更发布工作。
业务项目一般来说来自于需求部门或者客户,主要从业务操作管理等角度提出,一般IT部门会列入年度计划并不断跟进,很多IT部门有专门的业务项目管理办公室(或者团队)管理,这个是最显现的也是公司比较关注的,主要来自外部(相对IT部门来说)。
内部项目是IT自发的技术升级、架构改进等主动或被动推进的,一般来说重要但不太紧急,而且用户或者业务部门并不太关心,但是这些项目关系到IT的可持续维护和IT能力建设,也就是内功。内功需要不断练习,不可荒废,当然有时候因为其他类项目太多疲于应付就会逐步荒废,最终欠下太多技术债务,各类问题不断进入恶性循环,凤凰项目主人公比尔一开始接过来就是这样一个烂摊子。
变更发布工作,这个IT人员最熟悉,完成开发后最终要发布启用,这也算是一种,非常重要,大项目十月怀胎一朝分娩,小升级也得最终上线,这是重要的里程碑,对于外部业务项目来说人家都盯着呢,而且立项之初甚至提出需求意向时就追着你问什么时候可以上线,相比大家感触很深。主人公其实主要是运维部门,因此一开始发布工作造成的各类问题让他应接不暇。当然大家如果看过这本书就会了解对于什么是变更文中还是专门讨论了的并给出了定义,这点很重要。
最后就是计划外工作了,凡是没有纳入计划的就算是计划外工作了,但这也是需要动态来看的。首先计划外工作对于计划内工作影响很大,不少人深有体会,IT人员经常上班时间处理其他事,额外时间做开发也是比较多的,因此对于计划外工作务必重视,并管理好非常重要。
对于上述四种工作来说,我们当时重要的一点首先是对号入座,大家可以手头所有工作归类,然后尽量减少计划外工作(怎么减少?对于计划外工作也要分类,对于常规计划外工作要尽量标准化流程化,对于部分关键岗位可能要限制流转到他那里),这样把计划外工作控制在一定影响范围内;腾出手来先对付变更发布工作,因为变更发布控制不好也会导致变成计划外工作,干扰甚至严重影响其他两种计划内工作,首先要变更流程化、尽量自动化,如有可能降低每次变更的范围快速发布;最后就是剩余的业务项目和内部项目了,这是左手和右手,我现在是两个列表,定期对照检查是否按照计划顺利开展。当然最后两类不是很容易几句话就可以搞定的,后续再说。
这也算是去年读了《凤凰项目》后第一位的感受,供大家批评。