银行业系统集成人员构成分析
银行业是我国较早运用计算机技术，尤其是数据库等软件技术的行业。由于经济实力雄厚，业务发展迅速，所以是经常进行系统集成工作的行业；其业内技术人员软件水平较高，项目组织也较符合规范，是软件工程项目范例分析的良好样板。
银行业的系统集成项目大小不一，小至POS等端末小系统，大至支撑全国的核心业务系统都有。每年每家银行的科技投入都以亿计。当然，早期的项目组织虽无章法，但系统简单、人数少、管理容易，故问题也较少；也不可取法。现在的情况是：经过这些年的摸爬滚打，各银行都形成了一套不能算非常正规但有一定模式的人员、进度管理方式。
通常的方式是：首先，由业务管理部门根据日常工作中前端工作人员的反映，收集针对当前系统的意见，提出“需求”（不是软件工程意义上的需求）；然后，业务部门从本部门和前端抽调人员组成“业务人员”与技术部门协同做“需求分析”（不完全或不是软件工程意义上的需求分析，通常是走形式，对技术人员来说则是讨价还价，推掉他们不想做的）；完成后则技术人员进入开发阶段，业务人员作为业务支持从旁解释业务操作过程和相关业务关系；在测试阶段，业务人员变成测试人员，进行业务测试；新系统投产时，业务人员投入一线负责培训、指导其他前端工作人员并反馈问题。
这里应该指出的是，“需求” --这种意见的归纳和整理，可能经过了一个以上的层次，即多次提炼加工，可能会背离前端人员的真正意图；但是，值得一提的是这些需求的归纳者，即业务管理部门的人士有相当的水平和知识层次，能够切中大部分问题的核心，可是也有脱离实际一线工作，在细节问题上不仔细，想当然的问题。而在测试阶段，业务人员会从前端工作人员中抽调一些业务骨干补充测试力量，他们往往会带来许多需求修改—主要集中在界面、操作上，从修改量上可以看出原需求的质量。
可以看出：业务人员主要分两类：业务主管部门的代表（“主管”）和前端抽调的工作人员（“骨干”）。前者文化层次较高，分析问题切中要害，熟悉各种法规制度，对系统的认识全面，目标明确；可是在细节问题上不重视，有想当然的作风，与后者矛盾时，在压力大的情况下容易妥协；与技术人员容易有共同语言。而后者一般不了解业务的“实际过程”，求知欲不强，对系统的认知只能依靠原有系统，经常提出在技术人员看来“很过份”的需求；这种人有“话事权”的话，新系统极有可能变成原系统的翻版；但他们业务精熟，上手快，能快速在测试时找到错误，能干的还可以找到原因（有部分人有依赖性则不愿找原因），可以快速完成大量业务，整理清楚各种纷繁复杂的报表，厘清头绪。
现在，我们来看一下技术人员的构成。银行方一般由以下几种人构成：一、刚毕业分配来的大学生，数量极少，不具有任何或很少业务经验或技术知识，往往现学现用，程序质量不高，不小心就会捅漏子，但到项目结束时往往成为业务、技术高手，可称之为“幸运儿”；二、原系统维护、开发人员，这部分人较熟悉业务，有部分更可以算业务高手，了解业务的计算机内部流程，实际的业务流程便由他们决定。由于近年来银行系统开发外包较多，会有系统集成公司的程序员，一般称“公司方”，他们有部分是原银行业中的技术骨干，有些是某些领域内的高手，也有公司要培养的新毕业的大学生组成；他们技术水平一般较高，但往往参差不齐；即使熟悉业务但对业务流程也没有决定权。
可以很容易的想到：在开发中，较好的思路是：由“主管”拟订需求，“骨干”拟订界面；双方的“技术骨干”做需求分析，决定“内部业务流程”，带领新手编程；“主管”做业务支持，测试时再调“骨干”来参与。但能否如此理想，只能看运气了。
另外，由于公司方人员薪酬较高，可能影响银行方技术骨干的士气，项目结束时可能会有跳槽的，会影响系统后期维护工作。
(有不同意见，建议欢迎讨论huang_jien@msn.com)
