以往对项目总结的认识不够,很多时候也就是写写PPT或者开个会,很多经验没有能被辨识出来成为案例,也就不能给大家分享。特别是很多教训,人性的问题,没有被说出来,毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富,因此前人吃亏,后人无法继承到有效的经验。
前段时间进行2008年度总结的时候,业主提出接触我们这么多项目,我们每个项目经理的风格都不一样,项目的成功与否太依赖于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格,项目经理当然有能力水平的高低,当然有不同的价值体现。业主其实就是在说我们的项目实践必须积累。
在之前的博文《业主的改进意识让我惊讶,我们应该更加积极地看待和推进CMMi的改进!》中讲到,一个业主的项目经理对口我们几个项目经理,A项目经理做得好的,业主方项目经理肯定会将A做得好的地方来要求公司的另一个项目经理B。如果我们自己不传授这种经验,那才是傻子。
使用即将推行的CMMi的规程,重新Review一下2008年的各个项目,从中去分析各个项目组的强处以及弱项,从规程中扫漏洞,审视项目组的那些活动执行的力度和弱项之间的关系,对于来年指导项目建设是非常有帮助的。今天在内审会议总结上,同事WN说得好,我们现在的项目经理花了很多时间在做事,其实缺少了时间思考如何去做事!管理不仅是规范、监督,还有教练一职。
故事一则:
在组织间跨项目组加强推广学习优秀经验,除了会议交流、专题培训,还可以去现场实地体验加强感性认识(呵呵,共产党宣传的那一套都要学习用上)。上次说到项目O和项目C整合上线,整个上线持续了近三天时间,有很多地方值得总结。今天刚好有项目T正在组织部署上线,项目T的技术经理CC做为培训讲师以往培训过两次有关部署的工作,项目C的经理C当时也听过CC的课程,在没有和CC打招呼的前提,带上项目O和项目C的两位同事L和C到现场去抽查观摩,能够更加有感触其他同事的优秀实践。
到了现场,才知道项目T晚上6点才开始部署,因此安排两个项目的项目经理/技术经理进行现场的交流。在简单介绍了此行的目的后,CC首先发言,询问C上次部署的过程中计划和实际工作最大的出入在那些地方?通过近一个小时的访谈,同事C和L认识他们有不少改进的问题,这里讲最重点一点:项目组C和项目组O在系统的正式部署前,缺少完整的演练。虽然有部分的演练,但是没有通过演练将可能的问题辨识出来。也因为如此,吃亏最多的迁移方案中的校验问题,没有能够提前暴露。
涉及到新旧两个系统的迁移,数据需要从系统O迁移到系统C,采用的方案是C直接访问O的数据方式,表面看这种方式最简单最直接,但是编写迁移和校验程序的同事都必须必须清晰了解C系统和系统O的业务逻辑,而实际由于逻辑覆盖不全面,导致校验的工作不完整,只使用抽样的方式即花了大量的人力(校验一个抽样数据,需要花20分钟人力),也导致有大量的迁移漏洞需要补救。
同事CC告诉C,应该采用接口交互表的方式,约定好规格,系统O的同事熟悉O的业务逻辑,负责将数据迁移到接口表,再由他们进行业务逻辑的检查,因为他们熟悉旧系统的逻辑啊!检查完毕后,才由C负责从接口交互表中提取数据,C了解新系统的新业务逻辑,对接口交互表进行逻辑检查后,提取数据转换到新的系统。采用两阶段的迁移,由熟悉旧系统的同事做应该做的事,让新系统的同事做他该做的事、熟练的事,看似复杂反而简单!
我在旁边插了话,其实如果旧系统是其他公司承建的,可能同事们就能想到两阶段迁移的接口交互表方式,可是我们两个系统由于是同一个部门承建,我们把部门边界和系统边界给混淆了,反而欲速而不达。