银行业系统集成人员分析

2008-04-09 04:06:26来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

银行业是我国较早运用计算机技术,尤其是数据库等软件技术的行业。由于经济实力雄厚,业务发展迅速,所以是经常进行系统集成工作的行业;其业内技术人员软件水平较高,项目组织也较符合规范,是软件工程项目范例分析的良好样板。


银行业的系统集成项目大小不一,小至
POS等端末小系统,大至支撑全国的核心业务系统都有。每年每家银行的科技投入都以亿计。当然,早期的项目组织虽无章法,但系统简单、人数少、管理容易,故问题也较少;也不可取法。现在的情况是:经过这些年的摸爬滚打,各银行都形成了一套不能算非常正规但有一定模式的人员、进度管理方式。


通常的方式是:首先,由业务管理部门根据日常工作中前端工作人员的反映,收集针对当前系统的意见,提出“需求”(不是软件工程意义上的需求);然后,业务部门从本部门和前端抽调人员组成“业务人员”与技术部门协同做“需求分析”(不完全或不是软件工程意义上的需求分析,通常是走形式,对技术人员来说则是讨价还价,推掉他们不想做的);完成后则技术人员进入开发阶段,业务人员作为业务支持从旁解释业务操作过程和相关业务关系;在测试阶段,业务人员变成测试人员,进行业务测试;新系统投产时,业务人员投入一线负责培训、指导其他前端工作人员并反馈问题。


这里应该指出的是,“需求”
--这种意见的归纳和整理,可能经过了一个以上的层次,即多次提炼加工,可能会背离前端人员的真正意图;但是,值得一提的是这些需求的归纳者,即业务管理部门的人士有相当的水平和知识层次,能够切中大部分问题的核心,可是也有脱离实际一线工作,在细节问题上不仔细,想当然的问题。而在测试阶段,业务人员会从前端工作人员中抽调一些业务骨干补充测试力量,他们往往会带来许多需求修改主要集中在界面、操作上,从修改量上可以看出原需求的质量。


可以看出:业务人员主要分两类:业务主管部门的代表(“主管”)和前端抽调的工作人员(“骨干”)。前者文化层次较高,分析问题切中要害,熟悉各种法规制度,对系统的认识全面,目标明确;可是在细节问题上不重视,有想当然的作风,与后者矛盾时,在压力大的情况下容易妥协;与技术人员容易有共同语言。而后者一般不了解业务的“实际过程”,求知欲不强,对系统的认知只能依靠原有系统,经常提出在技术人员看来“很过份”的需求;这种人有“话事权”的话,新系统极有可能变成原系统的翻版;但他们业务精熟,上手快,能快速在测试时找到错误,能干的还可以找到原因(有部分人有依赖性则不愿找原因),可以快速完成大量业务,整理清楚各种纷繁复杂的报表,厘清头绪。


现在,我们来看一下技术人员的构成。银行方一般由以下几种人构成:一、刚毕业分配来的大学生,数量极少,不具有任何或很少业务经验或技术知识,往往现学现用,程序质量不高,不小心就会捅漏子,但到项目结束时往往成为业务、技术高手,可称之为“幸运儿”;二、原系统维护、开发人员,这部分人较熟悉业务,有部分更可以算业务高手,了解业务的计算机内部流程,实际的业务流程便由他们决定。由于近年来银行系统开发外包较多,会有系统集成公司的程序员,一般称“公司方”,他们有部分是原银行业中的技术骨干,有些是某些领域内的高手,也有公司要培养的新毕业的大学生组成;他们技术水平一般较高,但往往参差不齐;即使熟悉业务但对业务流程也没有决定权。


可以很容易的想到:在开发中,较好的思路是:由“主管”拟订需求,“骨干”拟订界面;双方的“技术骨干”做需求分析,决定“内部业务流程”,带领新手编程;“主管”做业务支持,测试时再调“骨干”来参与。但能否如此理想,只能看运气了。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:基于序列的规范过程

下一篇:尽信书则不如无书