ITPub博客

首页 > IT职业 > IT生活 > 银行业系统集成人员分析 (转)

银行业系统集成人员分析 (转)

原创 IT生活 作者:worldblog 时间:2007-12-12 11:10:56 0 删除 编辑
银行业系统集成人员分析 (转)[@more@]

银行业系统集成人员构成分析

 XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

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

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

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

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

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

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

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

另外,由于公司方人员薪酬较高,可能影响银行方技术骨干的士气,项目结束时可能会有跳槽的,会影响系统后期维护工作。

 (有不同意见,建议欢迎讨论Mailto:huang_jien@msn.com">huang_jien@msn.com)


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

请登录后发表评论 登录
全部评论
  • 博文量
    6241
  • 访问量
    2406174