生活中，我们离不开银行，手里有余钱，我们可以放在银行；缺钱了，可以从银行贷款。还有一些生活缴费，比如水电费、煤气费、通讯费等。总之，银行成为我们生活中的一部分，不可或缺。

表面上，银行为我们提供了这么多的服务，那么在背后，是什么支撑了银行的这些服务呢？。答案是银行的IT系统和信息科技。那也就意味着，IT建设对银行来说，有着非常重要的作用，科技是第一生产力，是银行业务发展的强力后盾。

银行一般都有上百个IT系统，分别服务于银行的各种业务条线。然而，在系统建设和管理过程中，总会遇到各种各样的问题。下面我们就站在项目管理的角度来阐述IT系统建设过程中存在的一些问题和改进建议。

一、项目人员知识更新难

在和一些系统实施项目组进行交流的时候，项目人员反映最多的问题是知识更新的问题，由于项目人员长期驻守在一个项目组，分别负债不同的功能模块开发维护。使得他们的知识面局限在某一个点上，非常狭窄。对于行业最新的技术架构、产品体系、业务知识缺少获取的渠道和机会。

项目人员自己的知识得不到有效的更新，其项目实施能力就无法很好的提高，服务的效果和效率就会大打折扣。随着银行业务的不断发展变化，开发技术的不断更新换代，这种瓶颈越来越明显。

要解决这个问题，需要银行和IT服务厂商共同来讨论解决。对于银行来讲，不要一味的提高服务门槛，要给跟不上节奏的项目人员改进的机会。否则银行也会付出更多的成本，而且还会影响系统实施质量和进度；对于提供服务的厂商来说，企业应该制定有效的员工服务能力提升管理办法。针对每一个员工，合理制定其成长计划，记录员工成长轨迹。帮助自己的员工快速的成长，无论在业务层面还是技术层面都能很好的提升，进而提高员工自身的实施能力、服务能力，增强员工对公司的认同感。

二、人员频繁变动

在项目管理过程中，作为被服务方，银行最反感的是厂商服务人员的频繁撤换。对于银行来讲，这样会无形的提高银行的培训成本和时间成本，给IT系统的稳定性也带来巨大的隐患。

对于服务厂商，项目人员的更换一般是客观原因造成的，比如说员工离职，员工生活上的一些诉求等，不得不进行人员撤离。当然也有一些主观上的因素，比如考虑成本，或者其他项目急需人员支持。这些都会涉及到人员变动。

现在很多公司为了尽可能的使项目人员保持稳定，基本实行属地化管理，一方面提高员工的归属感，提高员工生活质量；另一方面公司也节约了成本。

建议服务厂商，可以从以下几个方面来完善了企业员工的项目服务流程：

项目人员进驻：厂商统一出具工作介绍函，由银行相关人员进行签收，有时候进驻人员要先经过面试。

项目人员撤离：在项目人员撤离时，厂商要把人员撤离函以书面或者邮件的方式发给银行相关人员，银行对撤离人员给出评价并进行撤离确认后，人员方可撤离。

对于派驻短期服务/支持人员，厂商统一制定服务/支持人员服务单，服务支持人员去银行现场服务前，领取该单据，在现场服务完毕后，由客户对该服务人员的服务情况进行评价并签字确认后，方可撤离银行服务现场。

人员在更换时，一定要认真做好交接工作，并可在事后追责，作为考核指标进行考核。以实际经验来看，项目人员在调整时，一般也都会做交接工作，但这种交接更多的时候沦落成了一种形式。 主要表现为两方面的问题，一是交接人员不是很认真的把自己的工作进行梳理，比如已经完成了哪些工作、哪些工作还没做完、做到了什么程度、哪些工作需要接手人员落实执行、需要注意什么地方等，而只是应付了事；二是接手人员不认真看交接的内容，对于交接中安排的工作不进行落实，不执行。这两个方面有一个方面做不好，工作就衔接不上，就会对项目成本、质量、进度等各个方面造成影响。

在对所有项目考察后，发现这种现象很普遍，做好人员的稳定工作是重中之重。

三、需求管理落实不到位

需求对于IT项目建设至关重要，对于需求要进行过程管理，要贯穿项目始终。

在实践中，需求管理方面主要存在以下问题

1、脱离需求开发

在项目开发的时候基本不看需求，而是凭着感觉在做，或者不完全按照需求开发，喜欢发挥自己的想象。这么做得后果是需求无法回溯，无法跟踪，质量也无法保证，找不到对应的测试案例而导致返工。

今年有一个项目就出现了这种情况，他们开发时完全脱离需求，只是根据业务人员提供的一个需求提纲在开发，没有详细的需求规格，开发过程中，不断的找业务人员讲需求，反反复复，使得业务人员不厌其烦。最后的结果是这个项目无法正常实施下去，被强行终止。给甲乙双方造成了严重损失。

还有一次例行检查中，发现一个项目，在需求执行上也出现了问题，这个项目是有详细的需求规格，需求分析的。在查看一个项目人员完成的任务时，发现需求有一个功能是画一个圆，结果他给画了个正方形。问这个项目人员为什么这么做，这位同学的回答是：“我觉得这样好看一点”。检查人员当场晕倒。

可以想象，这种现象是普遍存在的，IT系统之所以质量问题是个老大难的问题，与这种工作态度是密切相关的。

在这方面，我们应该有相应的解决方案，首先，从业务人员的角度讲，需求要尽可能的详细，明确，输出结果唯一，不给开发人员造成太大的困扰和理解上的歧义；其次，开发人员要养成良好的开发习惯，需求是开发的唯一依据，即使需求有一些问题，也应该是把问题拿出来进行讨论，看看是理解上的问题，还是需求确实有问题，切忌对于不确定的需求，自己凭空发挥；如果需求是明确的，那更是要完全按照需求进行开发，杜绝凭借个人想象，进行二次创造。

2、需求变更管理不到位

目前几乎所有的项目在需求变更控制上做的不是很规范。主要表现为需求变更随意、频繁。有时候只是口头变更，没有任何记录。导致的结果就是对项目的进度、质量、成本都造成非常严重的影响。需求无法跟踪和回溯。

需求变更，在项目实施过程中，是不可避免的。需求变更是需求管理过程中一项常规的内容。也就是需求变更是要进行管理的，包括需求的合理化分析，对项目进度造成的影响评估等。一个需求如果确定要变更，就要对变更的需求按照需求变更的管理流程严格执行。控制好需求版本。使得项目最新存挡的需求和实际开发的系统是一致。

3、需求分析和设计

调查中发现，现在很多厂商，很多项目，不太注重需求分析和设计，或者说在这个方面不太擅长。很多项目，尤其一些小项目，需求出来之后，由开发人员自行简单设计后，拿来就开发了。当甲方要求提供交付物时，临时根据系统，反向编写系统设计，来应付任务的完成。

退一步讲，项目实施人员能力不尽相同，一些不具备分析设计能力的开发人员，最后提交的工作质量就很难保证。而设计文档的缺失，给运营维护人员后续维护也会造成困惑。

文档编写确实是开发技术人员的一个难题。这就需要厂商要有自己的需求分析设计团队，或者专业的设计小组，进行统一的需求分析设计。经评审后，提供开发小组进行开发。

四、开发中的问题

1、补丁式开发

在项目实施过程中，尤其是人力外包型项目，这种项目周期长，项目人员变换频繁，而需求又相对零散，开发人员拿到需求后，缺乏全局考虑的意识，只是为了完成任务进行了开发，与系统整体的设计思路和开发习惯大相径庭，破坏了系统整体性和可维护性。时间长了，系统臃肿不堪，补丁上打着补丁，最终系统维护工作异常困难。

所以，在拿到需求后，先要把这个需求放到系统的全局上来分析，在功能设计上要通盘考虑，而不是满足单一功能的开发。做到无论项目人员如何变换，都不会给维护人员造成困难为宜。

2、内部测试不认真

内部测试是系统开发过程中重要一环，但是实践考察来看，现在的项目越来越不注重系统的内部测试。即使项目经理从职业素养上重视这个问题，但并不能保证开发人员会当回事。一线开发人员往往缺乏最基本的质量观念，导致交付后问题多多。最近我到一个项目现场检查项目开发情况，要求开发人员把已经完成，并可交付测试的功能提交，我来进行测试，结果发现除了功能和需求不一致外，还有很多低级的错误，几乎测不下去。试想，如果这样的成果提交业务人员进行UAT测试，会是一个什么样的后果。更为严重的是，该开发人员并不以为然。

这是个有关项目人员职业素养的问题，但确实需要逐步提高改善。

3、客户体验不佳

IT系统最终是要交付使用的，系统上线后是否能够获得用户认可，是一个项目是否实施成功的重要考量。作为项目各个环节的人员，一定要站在使用者的角度来思考问题并付诸实施。系统的可使用性、交互良好、便捷、灵活是我们一定要考虑的基本要素。但在项目实施过程中，却往往忽略了这一点，把本来简单的功能，复杂化。这也是IT系统上线初期，往往导致用户吐槽的重要原因。

当然，这个从产品设计上就要下功夫，需要较高的分析设计能力，但作为项目实施人员，至少不要人为的增加功能到达用户的最短路径。

五、质量没有引起足够重视

不管任何行业，质量都是放在第一位的，IT系统建设也不例外。

通过近半年，我们对上线后的系统质量情况分析，情况不容乐观。

解决这个问题，需要从项目经理做起，认识到质量管理的重要性，并掌握质量管理的方法和技术。

质量是计划出来的，不是检查出来的。这是质量管理的本质。

质量控制主要是监督项目的实施结果，将项目的结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目实施的全过程。

项目经理应该具有质量控制能力，特别是程序抽样检查和对实施资源实施水平的认知。

质量控制是一个过程的管理，在项目的实施过程中，作为项目经理，要根据质量控制计划，把质量管理作为一项常规内容来抓，经常检查开发人员的代码，检查是否有逻辑问题，编写是否符合相关管理规范等。

项目经理可以采取很多方法：比如计算每个人的代码差错率作为考核的依据，通过量化的指标让每个人从心理上对质量问题重视起来。

总结

IT系统建设是一项庞大的工程，在过程中总是会存在这样那样的问题，本文列举了一些常见性的问题。但还是有很多问题，有待解决。也相信在甲乙双方的共同努力之下，问题也会越来越少。系统无论从质量上，还是用户体验上，都将得到很大的提高。