瞭解一下銀行科技信息崗

瞭解一下銀行科技信息崗

組織架構

規劃部門

規劃中心按照工作範疇大致劃分爲：項目規劃管理、需求規劃管理、系統規劃管理、預算管理、合同管理、PMO；

1. 項目規劃管理

這是從項目角度來進行規劃管理；通常會在自然年的年末或其他時間節點，相關人員和業務部門進行對接，就項目信息進行收集統計，瞭解是否有起IT項目的打算，同時瞭解對於項目的大致想法和要求，並納入年度科技類項目總體規劃中，以此作爲項目預算、計劃安排、資源分配的依據；隨後結合信息科技部的資源分配情況、現有項目情況進行可行性評估，並明確大致的里程碑節點，同時初步明確項目所屬中心及人員。

2. 需求規劃管理

這是從需求角度來進行規劃管理；主要是對需求的整個生命週期進行管理監控，包括從提出直至上線；隨着銀行事業部制的改革，同時也爲了便於對需求進行管理，需求規劃人員會各司其職，分別與對應事業部條線的部門進行對接，例如有負責對接零售條線部門的，有負責對接公司條線部門的，以此類推；首先會和需求提出部門進行對接訪談，收集業務需求並做大致瞭解，然後和對應的科技人員進行初步溝通，從IT角度評估是否能實現，明確實現方案及相應的週期、成本、排期等情況；如果都已明確並進入開發階段，則定期跟進需求狀態。

3. 系統規劃管理

這是從系統角度來進行規劃管理；一是對IT系統進行整體管理，明確系統的相關屬性，包括人員、部門、狀態、平臺情況、供應商等，如果後續在項目建設或系統搭建過程中，需提供系統信息作爲參考的，原則上以系統規劃人員提供的數據爲準；二是系統規劃人員對銀行IT系統的整體情況比較瞭解，所以某個系統在建設過程中，系統規劃人員可以從整體宏觀角度給予建議和意見；三是系統規劃人員還需要制定相關的標準和規範，後續IT系統在建設過程中需遵循這些標準和規範；

4. 預算管理

這主要從預算角度進行規劃管理；這裏按照預算涉及的對象可分爲對公、對私；對公部分主要涉及項目建設、需求開發、系統建設、合同簽署、驗收付款等過程中涉及科技預算費用的整體管理；對私部分主要涉及信息科技部員工的日常報銷費用的整體管理。

5. 合同管理

這主要是從合同角度進行規劃管理；由於銀行內IT事務的開展很大程度上是需要和供應商合作的，這就免不了涉及採購和合同簽署，合同簽署需要注意的事項很多，科技人員對此不可能都瞭解明白，合同管理人員對此可以給予一定的指導幫助，同時合同管理人員也是銀行採購中心和信息科技部的連接人，這樣就可以幫助科技人員節省一定的時間經歷，同時也可以使得合同簽署工作更規範也更有效率。

6. PMO

主要涉及對在建的項目、需求及相關IT事務進行管控，主要針對進度、風險、完成情況的管控，對於一些已經呈現出不良狀態的事務，對負責人提出警示並進行相應的跟進、跟催工作；同時定期收集項目週報，製作出項目簡報和報表給有關領導彙報；另外還需要對外包人員進行登記管理。但銀行科技的PMO並不負責項目資源的協調和優先級的排定，也不涉及對項目組之間的爭端進行衝裁。

開發部門

開發中心主要是根據系統所屬的業務條線或事業部條線進行劃分的；如果按照業務條線或所屬領域劃分的話，大致可以分爲：核心應用開發中心、電子銀行開發中心、中間業務開發中心、管理信息類開發中心等。

1. 核心應用開發中心

主要涉及銀行核心交易系統的開發管理；由於銀行普遍對早期的大核心繫統進行瘦身，所以原先隸屬於核心系統中的部分交易和業務操作被剝離出來成爲單獨的系統，核心系統只保留存貸款等基本的交易，所以核心應用開發中心涉及的系統一般包括：核心系統、理財系統、資金管理類系統、國結系統等。核心應用開發中心涉及的都是銀行IT系統體系中最核心的部分。

2. 電子銀行開發中心

主要涉及銀行渠道類系統的開發管理；之所以命名爲電子銀行開發中心，是因爲相關係統對應的業務領域主要是電子渠道領域的，外部用戶可以通過這些渠道直接進行交易操作，涉及的系統一般包括：個人網銀、企業網銀、手機銀行、微信銀行、自助終端類等。

3. 中間業務開發中心

主要涉及銀行傳統業務以外的中間業務系統的開發管理；此類系統很大的特點是包含子系統較多，涉及的關聯繫統、第三方系統較多，不論是投產上線還是生產問題排查，涉及的干係方也多。

4. 管理信息類開發中心

主要涉及數據類系統以及企業信息化系統的開發管理；其中數據類系統主要涉及數據倉庫以及需要以數據倉庫提供的數據作爲系統支撐的下游系統，例如監管報送類系統、CRM、績效考覈系統等；另外還有一部分是企業信息化系統，這類系統並不涉及對外提供交易服務，只是企業內部使用，是獨立的一個體系，主要包括OA、門戶網站、HR、財務報賬系統、項目管理系統、協同辦公系統等。

另外開發中心也會按照事業部條線進行劃分，這樣做能夠更有針對性開展工作，和業務部門的結合更加緊密，一般會劃分爲：零售銀行開發中心、公司銀行開發中心、金融市場開發中心、其他事業部條線開發中心(例如數字銀行開發中心)等，同時隨着熱門技術或領域的推廣，例如大數據、移動互聯網、智慧銀行、金融創新等，開發中心爲了更好的在這些領域進行深耕，在中心劃分上也會體現這一點，例如會劃分出大數據應用開發中心、智慧銀行開發中心、金融創新開發中心等。

測試部門

測試中心的工作內容大致可以分爲：測試管理工作、測試資源的管理、版本管控等。

1. 測試管理工作

與開發中心的劃分原則大致相同，原先是採用業務條線劃分的方法，分爲核心、電子銀行、中間業務、管理信息等，後續也相應改爲以事業部條線進行劃分，分爲：零售銀行、公司銀行、金融市場銀行、數字銀行等，這也是爲了和業務、開發結合更緊密，更有利於測試工作的開展；銀行系統的測試環節一般包括SIT測試、UAT測試、性能測試；其中SIT測試一般情況下是由開發中心來具體執行，測試中心制定標準和規範，評估測試結果是否符合出口標準，UAT測試則視情況而定，如果測試內容不多，且只是偏向於驗收通過性測試，則UAT測試工作主要由業務人員或需求提出人員來進行，測試中心同樣也是制定標準和規範，如果測試內容較多，單純由業務人員來測試可能時間和精力不夠，且對測試專業性有一定要求，則測試中心使用測試外包資源來進行測試，這些測試外包資源來自與銀行簽訂框架合同的供應商，長期駐場進行測試工作。

2. 測試資源的管理

這裏所說的資源，主要包括人、物兩方面，人的層面主要是指測試外包人員，測試中心根據情況就外包資源進行協調和分配；物的層面主要是指與測試相關的環境、設備等，環境部分測試中心主要涉及管理，具體搭建工作並不是由測試中心本身來做，而是由主機人員來做，設備部分測試中心在做管理的同時，還負責設備的發放和回收，包括移動設備和臺式設備等。

3. 版本管控

對於版本管控主要是兩方面，一方面是各系統在開發、測試、上線中涉及的版本號進行管控，這既包括主系統本身的版本號，同時也涉及配套系統的對應版本號；另一方面是通過自動化版本發佈系統進行版本發佈，測試中心付負責制定版本規範，以及相關版本發佈人員的權限。

運營部門

科技運營按照運營對象所屬領域可以劃分爲：基礎架構中心、機房管理中心、運維中心。

1. 基礎架構中心

主要包括主機、網絡等IT基礎類資源；主機部分涉及服務器、數據庫方面的管理以及具體實施工作；網絡部分則主要保障網絡、線路的連通性，網絡訪問策略的可用性等；所以基礎架構中心負責的是整個IT體系中較爲底層的一些事務；

2. 機房管理中心

銀行中都會有存放大量服務器的數據中心和機房，機房管理中心負責的對象包括與機房有關的人、物；人的層面主要是對與機房有接觸的人員的管理，物的層面主要是針對機房設備的管理，包括設備的擺放、遷移、維護等。

3. 運維中心

運維中心做的事情比較雜，一類是負責IT系統故障、生產問題的跟進解決，運維人員需要對故障問題及時響應，如果自身無法及時解決的則需要及時分派給相應的開發人員；另一類是負責提供IT服務和資源的，例如需要申請賬號、設備或者開通權限的，還有一類是負責系統生產環境版本發佈的，但這裏的發佈是指運維人員有往生產環境發版本的權限，只負責執行版本發佈這一動作，具體版本的打包工作還是由測試人員、開發人員來做；

安全部門

銀行早期的信息科技部由於系統較少，整個IT體系結構還比較簡單，對於安全方面還沒有足夠的重視，也沒有足夠的人力來執行，隨着信息科技部人員的逐漸壯大，以及對於IT安全意識的逐漸提高，信息科技部中會單獨劃分出負責信息安全的中心；安全中心主要關注IT信息的安全性和保密性，同時負責收集相關補丁來抵禦病毒對銀行IT系統的侵害；銀行是個對客戶信息安全、系統信息安全特別重視的機構，所以安全中心的重要性也與日俱增。

工作模式

銀行內IT項目的人員組成情況通常如下圖所示

銀行IT項目實行的是項目經理負責制，會任命一名行內科技人員作爲項目經理，對項目整個生命週期負責；具體由誰來擔任，則具體看這個項目屬於哪個範疇，比如，自動化發佈系統，屬於測試中心範疇，則項目經理由測試中心的人員來擔任；銀行安全過濾系統，屬於安全中心範疇，則項目經理由安全中心的人員來擔任；自動化運維繫統，屬於運維中心範疇，則項目經理由運維中心的人員來擔任；其餘大多數項目屬於開發中心範疇，則項目經理由開發中心的人員來擔任；但銀行內的項目經理的職責和權利是不對等的，給了你最大職責，你需要全權負責，你需要對結果負首要責任，你甚至需要背鍋，但是你作爲項目經理並沒有與職責對等的權利，無法調動資源同時也無法體現出自己的想法，這種情況很大程度上是由於銀行信息科技部的組織架構是以職能維度進行劃分的，而不是以爲項目爲維度，項目中的干係人，包括業務、測試、運維等都是來自不同的職能部門，是聽命於自己職能經理的要求，而不是聽命於項目經理，他們從自己的KPI或者部門立場出發，那就肯定會做出這樣的舉動。

項目中的干係人主要包括業務人員、測試人員、運營人員，這些人員都是行內人員，另外還包括公司方團隊，則主要包括公司方項目經理、開發人員、實施人員、UIUE人員、測試人員等；

1. 行內業務人員

首先提下業務部門，所謂業務部門就是提出業務需求，相比於信息科技部自身不具備IT能力，也不擁有IT資源，希望通過IT項目的方式來滿足自己的要求，同時需要明確項目的預算費用，同時業務部門也是最終享用項目結果，使用對應系統的部門，大多數情況下業務部門是除信息科技部以外的部門，當然有些項目由於自身的業務屬性比較特殊，則對應的業務部門就來自於信息科技部本身，比如自動化運維繫統、版本發佈系統、IT運維繫統等；業務人員就是來自這些部門的人員，他們負責和科技人員進行對接，對需求，整體建設方案進行把控，力求項目的最終落地成果是自己想要的，可以滿足自己的要求。

由於業務部門是出錢，提需求的部門，信息科技部是花錢，實現需求的部門，由於這種角色定位就決定了他們之間的關係，誰出錢誰就相對有話語權，說白了更像是“爺”,業務部門的要求，信息科技部要儘量滿足，通過使用科技手段來實現業務部門的要求，滿足業務部門的需求，之間關係有點類似銀行內部甲方乙方的關係，業務部門是銀行內的甲方，信息科技部是銀行內的乙方，當然業務部門還是會和信息科技部搞好關係的，這其實也是爲了項目能夠順利的推進，自己的要求能夠不打折扣的得到滿足，如果關係搞不好，項目就會受影響，最終受影響的還是自己。

現在隨着科技力量在全社會的大力發展，科技的發展確實在很大程度上是可以幫助業務的推廣，所以科技在銀行內的重要性得到了重視，信息科技部在銀行內的地位也有提升，銀行也提出了類似“科技引領”等一些聽起來很高大上的口號，確實這些口號的提出也說明科技的被重視程度越來越高，但需要認清的是，至少從部門之間的博弈角度、話語權角度來看，科技還是偏弱勢方，因爲銀行中的科技力量再怎麼強大，那也只是“擁有雄厚IT實力，龐大IT團隊的銀行”，不管形容詞再怎麼多，最終還是銀行，而不是“擁有銀行業務能力的IT公司”，所以體現到表象上看，如果業務人員和科技人員對某一事情由於資源有限或者觀點不一致，銀行內採用的是前者“壓”後者，而互聯網公司或者泛IT公司採用的是前者“求”後者。

2. 行內測試人員

銀行信息科技部的測試人員，由於時間、精力有限，工作內容主要偏測試管理，本身不會從事具體的測試工作，具體的事情會分配給測試外包人員來做，這些測試外包人員來自與銀行簽訂框架協議的供應商，是長期駐場工作的；從項目角度來看，行內測試人員主要負責的是UAT測試、性能測試等，首先根據需求情況安排測試外包人員編寫測試案例，然後組織行方項目經理、公司方項目經理、業務人員、開發人員等項目干係人進行測試案例評審，然後根據項目計劃和測試計劃進行測試工作，按照測試結果和缺陷情況，督促開發人員進行修復，最終根據修復情況從測試角度給出是否可以投產上線的建議；

3. 行內運營人員

如果以環境類型作爲分水嶺的話，測試人員主要負責測試環境的工作，運營人員則主要負責生產環境的工作；在項目執行過程中，參與的運營人員主要是基礎架構中心人員，包括主機人員、網絡人員、數據庫人員等，主機人員負責生產環境服務器、系統環境的搭建等；網絡人員負責網絡地址、端口、線路、訪問策略的連通性和可用性；數據庫人員主要是DBA，負責數據庫的搭建，同時保證數據庫正常穩定的運行；有些大型項目或者重要程度較高的項目，對服務器主機要求較高的，可能還會涉及到機房管理人員的介入，等項目結項後，則進入運營階段，細化到系統層面則是IT運維階段，這階段運維中心的人員會介入，主要是負責保證生產環境系統能夠正常穩定的運行，同時對於故障和問題及時跟進，需要及時發現問題，響應問題，並及時反饋問題解決進展，由於運維人員對於系統的瞭解程度不如開發人員那麼全面和深入，所以一些淺層次的簡單問題可以自己來解決，但遇到較爲複雜的問題，則需要及時將問題轉派給開發人員並跟進解決進度；

4. 公司方項目經理

銀行內IT類項目主要是以外包的方式來做，那麼從供應商的角度來看，自身需要任命項目經理對項目全權負責，公司方項目經理對銀行，需要全面、仔細的獲取需求，進行需求分析，制定方案，特別是產品以外需要定製化的部分，需瞭解清楚，否則路線跑偏了，不能滿足甲方的要求，造成項目無法驗收，而且也意味着資源的浪費，對公司也是一種損失，同時公司方項目經理還需瞭解行方的相關規章制度和管理要求，這樣便於項目的順利開展；當然公司方項目經理對於甲方的態度，需滿足要求，但也不能一味的無條件接受，畢竟做項目是涉及成本、資源、週期的，同時方案的制定也是需要結合產品本身特性，如果脫離產品本身一味地滿足甲方需求，則代表後續需要花大量的時間、經歷、成本來履行你的承諾，所在方案制訂過程中，公司方項目經理需要把自己的想法傳遞給行方，說明自身產品的特性，同時結合同業的經驗給出建議方案；那麼最終行方人員是否會接受，這其實是甲乙雙方博弈的過程，在一定程度上還取決於甲方是否強勢，如果甲方強勢，堅持自己的要求，那對於公司方來說，意味着這將會是一個痛苦的過程，所以對於很多供應商來說，和銀行做項目，特別是一期項目，都不指望能夠掙錢，一般性都會賠錢，只是希望能夠少賠點，目的在於和銀行搞好關係，達成良好的合作關係，給領導留個好映像，後續二期、三期的項目可以想到自己，自身則是可以通過這些二期三期項目逐漸盈利；公司方項目經理對本公司，需要根據甲方的要求以及制定好的方案，在公司內部進行討論，決定是否可以做，如果可行則協調包括開發、測試、UIUE、實施等在內的項目資源，推進項目的最終落地。

5. 公司方開發人員

不同於公司方項目經理從前期交流階段就需要駐場全程參與，公司方開發人員基本上等項目經理需求調研完成，最終方案已經輸出並且得到行方確認後，纔開始介入進來，主要負責的是產品本身以外的定製化部分以及和關聯繫統進行對接的開發工作；有些項目的公司方開發人員從進入到開發階段，甚至是前期的方案交流階段就駐場參與進來了，這樣做的好處是可以便於溝通交流，特別是涉及和關聯繫統對接、聯調測試的，可以更有利於開發工作的順利推進，同時行方人員也可以隨時瞭解開發進度已經和需求方案的吻合度是都符合要求，以防出現偏差，可以降低風險；但多數供應商出於成本考慮，不會安排開發人員長期駐場，頂多涉及到和關聯繫統進行聯調測試的時候纔會安排開發人員駐場工作。

6. 公司方實施人員

實施人員負責將產品以及對應的實施方案在系統層面部署落地，如果公司方的開發人員是進行遠程開發的，則會將開發好並通過測試的版本包發給實施人員，實施人員負責將版本包部署到系統中去。由於實施人員能否正確部署實施，決定了項目產出是否和預期的需求相符合，所以這就要求實施人員爲了能夠很好的瞭解需求，因此有些項目的公司方實施人員會和項目經理一起從前期交流階段就駐場參與需求調研。

7. 公司方UIUE人員

由於供應商提供的產品都是默認的版本，其風格樣式都是帶有公司特性的，比如logo、色彩、樣式等，所以需要根據銀行的要求對UIUE進行修改，也就是系統一打開就可以從風格樣式上知道是哪家銀行的；那麼公司方的UIUE人員就會根據要求進行設計，如果方案認可，則交由前端開發人員進行開發；當然UIUE其實也是產品特性的一部分，如果無條件修改，則意味着成本的巨大投入甚至是系統的面目全非，所以基本上UIUE的修改都是針對一些關鍵部位，例如登陸頁面、主頁Title等；

8. 公司方測試人員

在公司方開發人員完成開發後，首先會由公司方的測試人員進行測試，測試類型主要是SIT測試，測試範圍主要是針對定製化部分，產品本身由於已經通過嚴格的測試，所以沒有必要再納入測試範圍；通過測試後會將該版本交由實施人員，並由實施人員進行部署；當然公司方測試人員測試完還無法達到最終投產上線的要求，因爲行方測試中心針對項目會有自己的測試要求，一般情況下產品部分不會再去測試，主要是針對定製化部分以及關聯繫統對接部分進行測試。

招聘

1. 應屆畢業生招聘

應屆畢業生進入銀行信息科技部是較好的一次機會，和社會招聘不同的是，對於應屆畢業生的從業經驗和職業技能要求沒那麼高，用人部門也清楚應屆畢業生一般情況下不可能一進來就能獨立的幹活；所以銀行信息科技部在應屆畢業生招聘時主要看重這幾點：

一是學歷，基本上是要求本科畢業，而且越來越多的銀行是要求碩士畢業，值得一提的是，對應屆畢業生招聘來說，這裏的碩士一般情況下是指全日制的雙證碩士，既需要有學位證書，也需要有學歷證書，而不是隻有學位證書而沒有學歷證書的單證碩士，如果是單證碩士的話，銀行可能不會認可。

二是畢業院校，如果是985院校最好，不是985院校退而求其次也得是個211院校，而且有些城市商業銀行還比較偏向於總行所在城市的211院校，帶有一定的地域性；所以很多銀行的信息科技部在招聘啓事上都會註明985、211院校優先考慮。

三是筆試面試表現，以上所說的其實是簡歷篩選的條件，銀行的HR一般會把包括學校、學歷在內的信息作爲關鍵字進行搜索篩選，通過簡歷篩選，則進入筆試面試環節。筆試考察內容主要涉及數字、邏輯、文字、圖形等，這和公務員行測考試類似，如果是IT崗位則還會額外考察計算機方面的相關知識。筆試通過後，就會通知去參加面試，面試的方式主要爲無領導小組羣面，5、6個應聘者爲一組，每人分發一份材料，上面就某個話題進行描述，以及提出一些問題，每人花費大概5分鐘左右的時間閱讀材料，閱讀完後每人輪流花費大概2分鐘左右的時間簡要闡述下自己的觀點，然後花費大概30分鐘左右的時間進行相互討論，達成共識形成最後的觀點，最有由大家推舉一名成員進行總結髮言。面試官在整個過程中主要考察每名成員的思考問題、解決問題的能力，對信息的抽象概括能力，以及語言的表達組織能力，還有就是團隊協作能力；

所以銀行信息科技部對於應屆畢業生計算機專業知識是考察的一方面，但並不是決定性的，主要看重的還是學歷、畢業院校、綜合素質等方面，這點和互聯網企業、IT企業的招人要求還是有所不同的，有些銀行信息科技部可能會招一些非計算機專業大的畢業生。

應屆畢業生入職後，有些銀行可能不會讓入職者直接去信息科技部工作，而是會安排先去做銀行櫃員，工作時間基本上是至少半年(也有可能少於半年的，比如2、3個月，也有可能多於半年，甚至一年多的，但大多數是6-8個月)，目的是讓應屆畢業生熟悉銀行業務知識，而銀行櫃檯是一個理想的工作學習的平臺，工作滿一定期限後，如果有意願想轉崗去信息科技部工作的，再通過內部招聘轉崗的方式，調到信息科技部工作，當然不排除少數人原先想去科技部，後來在櫃檯工作一段時候後，覺得做櫃員其實也是一種不錯的選擇。當然這種培養方式也有其弊端，原因主要有兩方面：一方面，銀行櫃檯學習業務知識3-4個月基本都可以接觸到，剩下的時間只是在原有業務知識體系的範圍內不斷重複的過程，本身並不包含技術含量，對於業務知識學習本身也不會有什麼提高，相反隨着時間的推移，長時間不接觸IT領域的知識，可能會導致對IT領域的知識和技能逐漸荒廢，這對於需要去信息科技部工作的人來說是不利的；另一方面，應屆畢業生從分支行的櫃檯轉崗至信息科技部工作，這點也並不是完全由自己意願控制的，銀行會尊重你的想法和意願，但並不是自己想走就能走的，還需要原先所在分支行放人才行，如果遇到原先分支行以種種理由(比如目前缺人手，需等新人入職後頂替你的位置，你才能離開)扣人不放的，那也是很無奈的，對自己今後的發展也是不利的。

2. 社會招聘

社會招聘的人員來源一般有兩種類別，一種是原先與銀行合作的供應商人員，被銀行挖過去成爲銀行員工的，也就是從乙方人員變成了甲方人員，這類人員一般是原先供應商中項目的核心人員，對項目、系統的情況都比較熟悉，工作能力和個人情況行內員工也比較熟悉，從銀行的角度來看，如果這類人員一旦流失，對於項目本身來說無疑是一種損失和衝擊，同時這類人員由於之前在銀行長期駐場做項目，對銀行內部的項目情況，規章制度，流程要求，人員組成都很熟悉，跳槽到銀行的話不需要適應過程，直接就可以投入工作，所以銀行要通過社會招聘找人的話，這類人員是比較好的選擇。還有一種就是其他銀行或公司跳槽過來的人員，有相關的工作經驗和工作能力，這裏就不再贅述了。

這裏想描述一種奇怪的現象，一般會發生在從原先乙方公司跳槽到銀行的人員，他們在對於老東家時的態度有時候會發生微妙的變化。由於甲方乙方這種合作模式的原因，甲方一般會扮演管理者，提要求者的身份，而乙方則會扮演執行者的角色，由於人性層面的原因，都希望自己能給對方提要求，讓對方滿足自己的想法，同時自己又不願意聽別人發號施令，由於這種心態的存在，導致角色一旦發生轉變，做事情的方式和態度也會發生轉變，這些從原先供應商那裏跳槽過來的員工，有時候可能會失去原有的“階級感情”，曾經的同事此時在他們看來只不過是自己管理、命令幹活的對象而已，甚至把對方視爲自己的馬仔，舉個可能不太恰當的例子，這些人好比農民進了城成爲居民，卻又對原來一個村的老鄉充滿鄙視。他們的這種態度和方式我個人還是不認可的，我對於供應商的態度一向是“既要鬥爭又要團結”，要鬥爭是因爲銀行作爲甲方畢竟是付錢購買產品和服務的，需要完成項目任務的，站在銀行的立場和角度需要謹防供應商的偷工減料和人爲因素的延期，要團結是因爲儘管是乙方，但也和我們一起是一個項目組的，人的層面本身沒有高低貴賤之分，不能一味的以敵對和壓迫的態度對待對方。

收入、工作與發展

薪資福利

銀行信息科技部的薪資可能不及互聯網公司或者IT公司的薪資高，在整個IT行業處於中上等的地位；具體給多少薪資還是看入職後給自己定的職級是多少，職級定了薪資也就定了，所以有些剛入職的應屆畢業生會遇到這樣的情況，爲什麼自己是碩士學歷，薪資怎麼和同一部門的本科畢業生一樣，那就是因爲兩者定的職級一樣；銀行信息科技部的應屆畢業生的薪資起點屬於中上等，但後續的加薪頻率較慢且漲幅較小，不會像互聯網公司那樣每年甚至每個季度都會漲；年終獎則根據年度KPI考覈情況來看，一般情況下只要考覈結果不是很差，年終獎一般大概2、3萬的樣子，如果你的考覈結果很好，年終獎對應會多些。

銀行信息科技部的福利情況還是不錯的，一方面五險都是足額繳納，特別是住房公積金這塊比例較高，而且會提供住房補貼，舉某城市商業銀行的例子，一般企業住房公積金個人繳納比例爲8%，公司繳納比例爲8%，銀行個人繳納比例爲12%，公司繳納比例爲12%，另外還有15%的補貼比例；另一方面，還會定期發放過節費，購物卡、汽油報銷費用，過節禮品等，舉例來說，過節費分別是勞動節2000元，國慶節2000元，元旦節2000元，還有一次年度旅遊費2000元，另外每月發放500元超市購物卡，500元汽油報銷費額度，同時還有一些兒童報銷費用等。

工作強度

銀行信息科技部原則上不強制加班，主要看自己手頭項目情況或者事情多不多，如果手頭事情不多，那就正常下班，到點就可以走了，也不用擔心領導沒走自己能否走，如果多的話只能留下來加班，而且如果項目比較急，那加班的頻率會比較高，而且都要加到很晚，同時如果遇上需要投產上線的版本日，那肯定要加班，如果負責上線的是對外提供交易服務的系統那得等到交易量少的時候才能開始，一般都是凌晨。另外也有特殊情況的，例如遇上銀行重大項目的，需舉全行之力來做，那就需要強制加班了，可能是886(8點上班，8點下班，一週上6天，甚至7天)，週末上班必須來，不來領導會找你，當然會算你加班費，當然這是少數情況。對於加班這件事情，需要辯證的來看，一方面確實幸苦，佔用自己大量的時間，另一方面也要看到，如果自己一直很清閒，到點就走，則意味着自己做的事情並不被重點關注，自己有可能被邊緣化，加班其實也蘊含着學習成長甚至晉升的機會。

銀行信息科技部由於是後臺部門，不直接面對客戶，所以一般不出差；但由於銀行也正受到各方面的挑戰和衝擊，爲了會更好的發展和盈利，銀行的角色也在改變，由傳統的甲方逐漸在某些方面變爲乙方，例如有些項目是給政府部門或者事業單位做的，爲了更好的獲取需求或者提供服務，需要伴隨一定的出差，但時間不會很長，少則幾天，多則一個月。

所以加班出差這種事情也沒有絕對的，還是看項目情況，而且看待的態度也需要辨證性。

晉升機會

職級

銀行信息科技部的職業序列，從行政角度來看一般會有如下職級，如下圖所示。

1. 分管行領導(副行長)

銀行中會有若干名副行長，每名副行長分管若干個部門或者事業部，例如有分管零售銀行總部的行領導，有分管公司銀行總部的行領導，有分管計劃財務部、法律合規部的行領導等，這其中就包括分管信息科技部的副行長，即信息科技部的分管行領導。

2. 總經理

總經理是一個部門的老大，隨着銀行事業部制的改革，信息科技部總經理也會被稱爲CTO。

3. 副總經理/總經理助理

總經理之下會有若干個副總經理或者總經理助理，任命總經理助理是因爲副總經理的名額是有限的，一個部門內的副總經理名額就那麼2、3個，某些人員已經符合升爲副總經理的條件，由於名額原因，先任命爲總經理助理，總經理助理相當於副總經理級別；副總經理或者總經理助理會分管若干個中心，例如有分管開發中心的，有分管運維中心的，有分管測試中心的等等。

4. 中心經理

中心是信息科技部的最小行政單位，中心經理就是每個中心的負責人。某些中心人員較多的，同時還會設置中心副經理。

5. 員工

基礎辦事員。有些中心內部，爲方便梯隊化管理，會劃分小組，每個小組會設置組長，雖然同樣是員工，但從級別上會分三六九等，需要看你入職定的是什麼級別，可能身邊的同事和你同一個崗位，但人家可能是社招進來的，水平能力都比較高，那入職定的級別也就高。

所以銀行信息科技部的行政職級的晉升路線就是按照以上級別來進行的，但銀行裏的職位是一個蘿蔔一個坑的，想要晉升不容易，並不是工作能力強成績好就可以晉升，還需要參考其他諸多方面的因素，一名應屆畢業生在銀行裏幹個幾年，如果能升到中心副經理已經很不錯了，而且一般情況下，銀行裏的領導都不是本銀行一步步升上來的，而是從其他銀行或是企業跳槽空降過來的，有時候空降來個大領導，那麼這個大領導原先所在公司的嫡系人員，也會一起過來成爲各級別上的領導，而且都身居要職，後續如果遇到晉升機會，也是優先會考慮這些人員，畢竟從人的角度來看，還是會優先考慮自己人，對於應屆畢業生來說，屬於沒有“派系”的人員，想要在銀行裏一步一步往上晉升難度着實不小。
另外，現在有些銀行專門針對信息科技人員建立了IT職業序列，一種區別於傳統行政序列的獨立職級序列晉升路線，這似乎讓專心想從事技術工作的科技人員看到了希望，但有人算過一筆賬，從一名普通員工通過IT職級序列晉升至副總經理，理論上需要18年，而且這種管理方式也剛起步，沒有建立起成熟的體系，是否可以開闢出一條新的路線還有待考證。

自身成長

對於很多應屆畢業生來說，選擇銀行信息科技部時會考慮能否學到東西，這就要看想學到哪方面的東西。首先來看下銀行信息科技部的工作模式，主要採取的是和乙方供應商合作的模式，採購供應商提供的成熟的產品，然後在此基礎上再做定製化改造，這樣看來銀行與供應商之間就是傳統意義上的甲方乙方的關係，銀行提出需求，花錢購買產品和服務，屬於甲方，供應商提供產品和服務，賺取費用，屬於乙方；這樣做的原因有三方面：第一，供應商都是在某些領域內比較專業的廠家，他們的專業性、爲同業服務的經驗可以爲銀行所用，這其實也是銀行規避風險的一種方式；第二，如果銀行完全從零開始研發建設系統，那麼投入的時間、經歷、預算都是巨大的，週期也是漫長的，在一定程度上也存在風險，肯定不如現成產品來的穩定；第三，除少數幾家國有大銀行的IT團隊規模較大，實力較雄厚，具備能夠獨立研發複雜系統的能力，其餘大多數銀行的IT團隊的實力還不足以從零開始研發複雜系統的能力，頂多可以研發一些規模較小的內部管理系統；

所以信息科技部的日常很多工作，都是建立在供應商產品以及對應服務支持的基礎上的；雖然行方人員在項目、系統建設過程中會對產品逐漸熟悉起來，但是一旦出現問題需要解決，很大程度上還是需要依靠供應商的力量來支持。行方人員主要是明確需求、實施建設方案，更加偏向於管理，同時要求供應商根據行方管理要求和方案要求執行具體工作，包括開發，實施等。有些計算機畢業的同學，想好好學習技術能力，特別是開發方面的能力，相對來說這不是好的選擇，開發工作主要會讓外包人員來做，畢竟他們在一些系統細節方面要比行方人員要熟悉，而且有些產品供應商不對提供源碼，當然銀行信息科技部也逐漸要求需要有自主開發能力，能夠自己寫代碼，但畢竟承接的代碼開發工作都是些優化修改的工作，並不涉及系統核心模塊的改動，而且行方人員的主要精力還要放在其他諸多的例如方案制訂、項目管理中去，你無法全身心去做一名安靜寫代碼的美男子。同時銀行使用的都是些比較成熟穩定的技術手段，不會使用剛興起的熱門技術，就算使用到了也已經在其他公司使用過很長一段時間了。

另外同爲信息科技部的子中心，但彼此之間的話語權還是有高低的，這可以體現到今後工作開展是否能夠順利，預期能否如自己所想，人家能夠買你的帳等。那麼還是從上文列舉的幾個中心來看：

1. 規劃中心。

規劃中心負責IT體系的建設規劃，計劃制定，定標準定規範，所以很有話語權，畢竟人家是制定計劃和規範的，後續工作的開展都必須符合這些要求。而且銀行中的IT工作的開展，比較重需求，重方案，重計劃，重預算，這些要素都與規劃中心相關，可見其重要程度。

2. 科技運營部

科技運營部話語權也較高，因爲他們定製度、定標準、管資源、管權限；首先從基礎架構角度來看，負責的都是主機、網絡、數據庫等底層基礎的建設，尤其重要，自身也會根據管理要求提出IT體系的相應規範，制定行內標準，後續系統建設過程中都必須要符合這些標準，否則視爲不達標；另外系統在建設過程中，涉及的主機、網絡操作還需要在他們制定的變更日才能執行；其次從於運維角度來看，銀行信息科技部在重規劃的同時也注重運維，畢竟保障生產系統安全穩定的運行是首要任務，所以會建立相關的規範、標準和機制，項目建設和系統搭建過程中需滿足這些要求，同時對權限也進行嚴格管理，如果需要觸碰生產環境，則需要進行權限申請；同時爲了保證生產環境的穩定有序，避免由於頻繁變更對生產環境帶來的衝擊，運維中心還會制定版本日，例行的投產上線工作只能在版本日進行，所以版本日在一定程度上已然成爲IT系統建設過程中一個非常重要的時間節點。

3. 測試中心

由於測試中心負責對於版本的管控，測試資源的管理，以及對於測試過程制定標準和規範，所以也具有一定的話語權。

4. 開發中心

開發中心相比於以上中心，話語權屬於較輕的，因爲開發中心負責具體事務的執行，並不負責管理資源或者制定規範標準，開發中心負責將方案落地成爲現實，但這還沒完，還要看是否滿足制定的要求和標準。互聯網公司或者IT公司對待開發人員的態度是“求”,但在銀行中對待開發人員的態度則是“壓”。而且銀行信息科技部的開發中心人員處在一個較爲尷尬的地位，首先任何銀行系統的建設都是爲了滿足業務的，是業務驅動，所以要求對於需求、業務比較熟悉，這樣有利於系統更好的落地，但對於需求本身的熟悉程度不及業務人員；其次，從技術角度來看，銀行系統建設是建立在供應商產品的基礎上，技術手段的開展又受制於此。