项目（Explore）总结之项目概述

人都是有惰性的，总想着对几年前的这个项目（代号Explorer）做一个总结，但又总是给自己以各种各样忙的理由给耽误着，是懒亦是不堪回首当年的过程。

近段时间项目不多，闲来还可以学习点项目管理的理论知识，本着无事就写总结的思想，试着从理论的视觉重新审视一下这个项目。下面首先是对项目作一概述，然后接下来的几个章节，从项目管理的九大知识领域对此项目作一总结。

§1.1  项目概述

下面从项目背景、项目过程等方面对该项目作一概述。值得一提的是该项目代号为Explorer，寓意开拓，寄语技术有所创新，市场有所拓展。

§1.1.1背景

时间追溯到2004年，话说公司在某地市（下称D市）给某机关开发业务系统，项目销售经理（下称J）经常与当地政府部门的人打麻将，这其中有一个雀友正是客户信息部门的二把手（下称Y），闲聊过后，惺惺相惜，相见恨晚。自此建立联系后，在05、06年给客户做了一些不痛不痒的外围小项目，但一直未能深入接触到客户的核心业务系统。从客户信息部门了解到，业务系统是客户信息部门联合外部资源基于C/S开发的，后台数据库是Oracle，客户内部除了当时负责开发目前在负责维护的技术强人G工外，没有人熟悉这套系统，当时听起来感觉这G工还挺N的嘛：其他人都不懂就他能懂。

说起G工，有一次与J去拜访客户，正跟Y聊天，从机房出来一个人，不高不矮不胖不瘦，也就是通常所说的“其貌不扬”，Y给介绍说：这位就是G工，呵呵，原来这就是传说中的G工。经过后来的接触和交流，感觉G工是一个以自我为中心又十分自傲的人。首先，说起话来，总是说以前自己的科技论文写得如何如何、现在有什么技术问题又是如何如何自创方法解决，一副舍我其谁的气派；其次，对别人与他自己无关的谈话内容基本不感兴趣，插话的时候不太理会其他人的感受经常改变原来的话题。当时的反应嘛，既然你是客户，爱咋就咋地，基本上是附和着，偶尔还拍拍其MP。不过也在想，这么一个好像谁都不放在眼里的N人，做他的上级不是很难受？

随着一些小项目的开展实施，跟信息部门的人也逐渐熟络了，闲聊之余了解到除了G工的直接老板B外，G工对其他老板都不爽，当然，其他老板对G工也不爽，但迫于业务系统捏在G工手里，实在是有气无处出。当时在想：这样下去，G工迟早会下台，而恰恰正是我们的机会。果不其然，在不算太长的时间后，我们就在友好合作的情况下开始进场接手业务系统运维。当然，为了能够接手业务系统的运维，当时带了2个人，花了差不多5个月时间天天在啃业务系统的遗留代码，没有任何技术文档、没有详细代码注释，硬着把前后台之间的关系、后台数据库对象（如表、过程、函数等）之间的关系基本弄清楚。

旧系统运维不是长久之计，就这样，项目Explorer应运而生了。

§1.1.2实施过程概述

项目从签订合同到验收，耗费大概180个人月，前后历时将近2年时间，其中有1年多的时间天天在加班，两年的五一和国庆大多是在加班中度过，本人“有幸”作为这个项目的PM，亲历了这个过程，这样的一个过程对于每一个人来说都是一种煎熬。不过，值得欣慰和难能可贵的是团队成员离职率在项目过程中一直保持在10%以内，核心骨干成员基本没有离职。后来分析原因，有人笑称这是因为太忙，没有时间去思考，另外当年的自己都很年轻，都比较傻。

说回实施，项目中标后，大家都很高兴：可以做一套属于自己的核心业务系统，建立根据地了。但同时，大家也很担心：公司没有做过类似的项目（基于B/S的核心系统），没有任何的技术积累，没有足够多的高水平实施人员。项目风险很高，怎么办？当时想了个招，根据客户信息系统分散不统一的现状，建议客户分阶段分批上线，这样一方面可以很快的为客户创造价值，一方面是完成技术积累和建立核心团队，客户对此没提什么意见，稀里糊涂的也就同意了。

按此实施方案，开始制定计划，当时做这个计划基本是没谱的，没有工作分解结构、没有工作量估算、没有同行评审，大多凭着之前的经验，拍脑袋确定，于是一份初定在次年的7月份整体上线运行的计划摆在了客户和监理面前。计划里面，上线的时间点有6个，分别是：

1.12月：核心系统X1上线；

2.次年3月：核心系统X2上线；

3.次年6月：核心系统X3、X4上线

4.次年7月：核心系统X5上线

5.次年8月：核心系统X6上线

6.次年10月：外围系统上线

希望总是好的，现实总是残酷的。实际上，X1在12月磕磕碰碰上线了，Bug改了3个月后系统才稳定下来，还产生了著名的“星期五现象”（每周五发布程序，下一周周一系统都会出问题）；X2延迟到次年6月才上线；由于计划调整， X5在次年10月份上线，X6在次年11月上线，X3和X4则在次年的下年3月上线，外围系统由于客户需求变更，在验收后才完成。项目之所以出现这么大的计划偏差，根源在于项目团队无论是管理水平还是技术水平，都不足以满足拍脑袋制定出来的计划要求。

§1.1.3 组织资产积累

       资产积累需从过程和结果两方面分析。首先，过程上，失败的项目过程本身就是组织过程资产的一部分；其次，结果上，技术方面，研发了一套通用的前台开发架构、一套数十万行源代码的业务系统；人员方面，通过项目一批程序员、系统分析员成长为系统分析员和PM，此后的软件项目均受益于该项目的积累。

-------------------------- 本文可任意转载，但请注明作者和出处 ----------------------------

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-630361/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6906/viewspace-630361/