项目背景：中国建设银行数据集中工程(简称DCC)于2002年7月份启动，目标是在全国建立南北两个数据中心。项目完成后，38个分行的数据将全部集中到总行数据中心，而部署在分行的是大前置系统(简称大前置)和网点前端系统(简称前端)。大前置是这次数据集中项目的核心，除了接入前端的柜面业务外，还整合龙卡、清算、重客、网银等二十余种重要业务系统。该项目中神州数码负责大前置和前端系统的开发、切换，IBM负责后台主机系统升级改造。自2002年10月起，神州数码投入了60余人的开发队伍在建行外高桥开发基地进行了为期10个月的封闭开发。至2003年8月24日，经过24小时的系统切换，DCC在首个试点行—上海分行成功上线。全行327个网点一次切换成功，目前整个系统运行稳定。

　　笔者在DCC项目中任神州数码的项目总监，统一管理大前置和前端两个项目。本篇文章将结合笔者在项目中的切身经历，谈谈大型软件项目管理中的一些实际体验。

　　发现问题

　　笔者是在中途被匆匆调入项目组的，之前只被告知项目遇到一些困难。进入项目组还不到一周即发现：尽管项目中聚集了神州数码各方面的骨干，但项目中存在的主要不是技术难题，而是管理的问题，主要包括三个方面：

　　在管理模式上，因神州数码与客户分别签定了分行大前置和网点前端两个项目，所以项目由两套几乎独立的团队分别管理，各组之间推诿、争执时有发生!这一方面造成项目组效率低下(客户反映总是面对两组人，沟通困难);另一方面，像系统切换这样一些在中间地带的重要工作却无人问津。在工作方法上，压力没有得到传递，项目骨干压力巨大，但组员却相对轻松;另外由于工作量严重不平衡，存在人浮于事的现象。

　　在客户沟通上，缺乏必要沟通技巧和客户意识，造成客户关系紧张;而对于这种情况，项目组一些成员却认为是客户在故意找茬。

　　分析和解决问题

　　经过分析，产生上述三个问题的原因主要有以下几点：一是缺乏一个统一的核心班子;二是缺乏有效的工作方法，特别是工作重点工作不突出;第三是缺乏与客户在正式场合之外的非正式沟通渠道。

　　在明确问题原因之后，陆续采取了以下一些措施：

　　调整了组织结构 不再按合同划分大前置和前端两个项目，而是按系统平台、应用开发、切换和推广划分为四个小组，并明确了各小组职能。

　　确定重点工作 核心组第一件要确定的事便是项目的重点工作。因资源有限，要确保上海分行按时上线，必须确定项目重点工作策略。当时确定的两个重点包括：

　　一是分行大前置系统。一旦出现问题将造成整个分行业务瘫痪，所以系统的性能、可靠性事关全局。因此，对于大前置系统的压力测试和性能优化是第一重点。

　　二是系统切换。切换工作必须由经验丰富、组织协调能力强的人员担负。因切换工作启动已经晚了，再从公司调集人员已经不可能，权衡再三决定让前端的项目经理负责切换小组。事后证明虽然这一定程度上削弱了前端组力量，但系统切换工作确实完成得非常出色。

　　两个非重点包括：

　　一是对于网点前端系统，因当时认为应用上变化不大，测试中发现的问题不多，所以比较放心。因为未作为一个工作重点，反而从该组调出了不少资源支持其他小组。但事后证明这个判断是错误的，一是当时测试密度低，暴露的问题少，才造成了系统缺陷少的假象;二是后期突然修改凭证，客观上大大增加了工作量;三是全行有近330个网点，多点版本管理的风险未引起足够重视。所以，在后期大量进行修改时不仅人员工作强度极大，还一度造成版本管理的漏洞。

　　二是分行推广。因推广工作有一定的时间缓冲，所以当时的策略就是在不从项目组抽人的情况下尽量满足分行支持的需求，同时优先从公司其他项目调集资源。事后证明，当时这个策略是非常正确的，对集中优势资源保证上海分行上线起到了不容忽视的作用。

　　明确各组的工作目标 通过会议落实各组的目标，如大前置性能必须通过的专门的压力测试;前端组必须24小时内对变更和缺陷修改做出反馈;切换组要求将切换方案细化到单个任务的命令清单和验证清单;分行推广组力保不从项目组抽取人员。

　　稳定队伍，严肃纪律和鼓舞士气 核心组任务明确后，下一步要完成的就是“带队伍”。首先，根据重点工作和目标要求，项目组减少了8个工作任务不明确的人员，这对留下的项目成员反而是种触动;其次，与个别不稳定的员工进行了谈话，在解决了具体问题后一些员工表现出的活力远远超出想象，

[1] [2]  下一页