銀行業系統整合人員分析 (轉)[@more@]

銀行業整合人員構成分析

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

銀行業是我國較早運用技術，尤其是等技術的行業。由於經濟實力雄厚，業務發展迅速，所以是經常進行系統整合工作的行業；其業內技術人員軟體水平較高，專案組織也較符合規範，是軟體工程專案範例分析的良好樣板。

銀行業的系統整合專案大小不一，小至POS等端末小系統，大至支撐全國的核心業務系統都有。每年每家銀行的科技投入都以億計。當然，早期的專案組織雖無章法，但系統簡單、人數少、管理容易，故問題也較少；也不可取法。現在的情況是：經過這些年的摸爬滾打，各銀行都形成了一套不能算非常正規但有一定的人員、進度管理方式。

通常的方式是：首先，由業務管理部門根據日常工作中前端工作人員的反映，收集針對當前系統的意見，提出“需求”（不是軟體工程意義上的需求）；然後，業務部門從本部門和前端抽調人員組成“業務人員”與技術部門協同做“需求分析”（不完全或不是軟體工程意義上的需求分析，通常是走形式，對技術人員來說則是討價還價，推掉他們不想做的）；完成後則技術人員進入開發階段，業務人員作為業務支援從旁解釋業務操作過程和相關業務關係；在測試階段，業務人員變成測試人員，進行業務測試；新系統投產時，業務人員投入一線負責培訓、指導其他前端工作人員並反饋問題。

這裡應該指出的是，“需求” --這種意見的歸納和整理，可能經過了一個以上的層次，即多次提煉加工，可能會背離前端人員的真正意圖；但是，值得一提的是這些需求的歸納者，即業務管理部門的人士有相當的水平和知識層次，能夠切中大部分問題的核心，可是也有脫離實際一線工作，在細節問題上不仔細，想當然的問題。而在測試階段，業務人員會從前端工作人員中抽調一些業務骨幹補充測試力量，他們往往會帶來許多需求修改—主要集中在介面、操作上，從修改量上可以看出原需求的質量。

可以看出：業務人員主要分兩類：業務主管部門的代表（“主管”）和前端抽調的工作人員（“骨幹”）。前者文化層次較高，分析問題切中要害，熟悉各種法規制度，對系統的認識全面，目標明確；可是在細節問題上不重視，有想當然的作風，與後者矛盾時，在壓力大的情況下容易妥協；與技術人員容易有共同語言。而後者一般不瞭解業務的“實際過程”，求知慾不強，對系統的認知只能依靠原有系統，經常提出在技術人員看來“很過份”的需求；這種人有“話事權”的話，新系統極有可能變成原系統的翻版；但他們業務精熟，上手快，能在測試時找到錯誤，能幹的還可以找到原因（有部分人有依賴性則不願找原因），可以快速完成大量業務，整理清楚各種紛繁複雜的報表，釐清頭緒。

現在，我們來看一下技術人員的構成。銀行方一般由以下幾種人構成：一、剛畢業分配來的大學生，數量極少，不具有任何或很少業務或技術知識，往往現學現用，質量不高，不小心就會捅漏子，但到專案結束時往往成為業務、技術高手，可稱之為“幸運兒”；二、原、開發人員，這部分人較熟悉業務，有部分更可以算業務高手，瞭解業務的計算機內部流程，實際的業務流程便由他們決定。由於近年來銀行系統開發外包較多，會有系統整合公司的程式設計師，一般稱“公司方”，他們有部分是原銀行業中的技術骨幹，有些是某些領域內的高手，也有公司要培養的新畢業的大學生組成；他們技術水平一般較高，但往往參差不齊；即使熟悉業務但對業務流程也沒有決定權。

可以很容易的想到：在開發中，較好的思路是：由“主管”擬訂需求，“骨幹”擬訂介面；雙方的“技術骨幹”做需求分析，決定“內部業務流程”，帶領新手；“主管”做業務支援，測試時再調“骨幹”來參與。但能否如此理想，只能看運氣了。

另外，由於公司方人員薪酬較高，可能影響銀行方技術骨幹計程車氣，專案結束時可能會有跳槽的，會影響系統後期維護工作。

 (有不同意見，建議歡迎討論to:huang_jien@.com">huang_jien@msn.com)