以往对项目总结的认识不够，很多时候也就是写写PPT或者开个会，很多经验没有能被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。
前段时间进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格，项目经理当然有能力水平的高低，当然有不同的价值体现。业主其实就是在说我们的项目实践必须积累。
在之前的博文《业主的改进意识让我惊讶，我们应该更加积极地看待和推进CMMi的改进！》中讲到，一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方项目经理肯定会将A做得好的地方来要求公司的另一个项目经理B。如果我们自己不传授这种经验，那才是傻子。
使用即将推行的CMMi的规程，重新Review一下2008年的各个项目，从中去分析各个项目组的强处以及弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度和弱项之间的关系，对于来年指导项目建设是非常有帮助的。今天在内审会议总结上，同事WN说得好，我们现在的项目经理花了很多时间在做事，其实缺少了时间思考如何去做事！管理不仅是规范、监督，还有教练一职。
故事一则：
在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还可以去现场实地体验加强感性认识（呵呵，GCD宣传的那一套都要学习用上）。上次说到项目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了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。采用两阶段的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！
我在旁边插了话，其实如果旧系统是其他公司承建的，可能同事们就能想到两阶段迁移的接口交互表方式，可是我们两个系统由于是同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。
责任编辑：小草
您现在的位置： 
