了解一下银行科技信息岗
- 了解一下银行科技信息岗
- 组织架构
- 规划部门
- 开发部门
- 测试部门
- 运营部门
- 安全部门
- 工作模式
- 招聘
- 收入、工作与发展
- 薪资福利
- 工作强度
- 晋升机会
- 职级
- 自身成长
了解一下银行科技信息岗
组织架构
规划部门
规划中心按照工作范畴大致划分为：项目规划管理、需求规划管理、系统规划管理、预算管理、合同管理、PMO；
- 项目规划管理
这是从项目角度来进行规划管理；通常会在自然年的年末或其他时间节点，相关人员和业务部门进行对接，就项目信息进行收集统计，了解是否有起IT项目的打算，同时了解对于项目的大致想法和要求，并纳入年度科技类项目总体规划中，以此作为项目预算、计划安排、资源分配的依据；随后结合信息科技部的资源分配情况、现有项目情况进行可行性评估，并明确大致的里程碑节点，同时初步明确项目所属中心及人员。
- 需求规划管理
这是从需求角度来进行规划管理；主要是对需求的整个生命周期进行管理监控，包括从提出直至上线；随着银行事业部制的改革，同时也为了便于对需求进行管理，需求规划人员会各司其职，分别与对应事业部条线的部门进行对接，例如有负责对接零售条线部门的，有负责对接公司条线部门的，以此类推；首先会和需求提出部门进行对接访谈，收集业务需求并做大致了解，然后和对应的科技人员进行初步沟通，从IT角度评估是否能实现，明确实现方案及相应的周期、成本、排期等情况；如果都已明确并进入开发阶段，则定期跟进需求状态。
- 系统规划管理
这是从系统角度来进行规划管理；一是对IT系统进行整体管理，明确系统的相关属性，包括人员、部门、状态、平台情况、供应商等，如果后续在项目建设或系统搭建过程中，需提供系统信息作为参考的，原则上以系统规划人员提供的数据为准；二是系统规划人员对银行IT系统的整体情况比较了解，所以某个系统在建设过程中，系统规划人员可以从整体宏观角度给予建议和意见；三是系统规划人员还需要制定相关的标准和规范，后续IT系统在建设过程中需遵循这些标准和规范；
- 预算管理
这主要从预算角度进行规划管理；这里按照预算涉及的对象可分为对公、对私；对公部分主要涉及项目建设、需求开发、系统建设、合同签署、验收付款等过程中涉及科技预算费用的整体管理；对私部分主要涉及信息科技部员工的日常报销费用的整体管理。
- 合同管理
这主要是从合同角度进行规划管理；由于银行内IT事务的开展很大程度上是需要和供应商合作的，这就免不了涉及采购和合同签署，合同签署需要注意的事项很多，科技人员对此不可能都了解明白，合同管理人员对此可以给予一定的指导帮助，同时合同管理人员也是银行采购中心和信息科技部的连接人，这样就可以帮助科技人员节省一定的时间经历，同时也可以使得合同签署工作更规范也更有效率。
- PMO
主要涉及对在建的项目、需求及相关IT事务进行管控，主要针对进度、风险、完成情况的管控，对于一些已经呈现出不良状态的事务，对负责人提出警示并进行相应的跟进、跟催工作；同时定期收集项目周报，制作出项目简报和报表给有关领导汇报；另外还需要对外包人员进行登记管理。但银行科技的PMO并不负责项目资源的协调和优先级的排定，也不涉及对项目组之间的争端进行冲裁。
开发部门
开发中心主要是根据系统所属的业务条线或事业部条线进行划分的；如果按照业务条线或所属领域划分的话，大致可以分为：核心应用开发中心、电子银行开发中心、中间业务开发中心、管理信息类开发中心等。
- 核心应用开发中心
主要涉及银行核心交易系统的开发管理；由于银行普遍对早期的大核心系统进行瘦身，所以原先隶属于核心系统中的部分交易和业务操作被剥离出来成为单独的系统，核心系统只保留存贷款等基本的交易，所以核心应用开发中心涉及的系统一般包括：核心系统、理财系统、资金管理类系统、国结系统等。核心应用开发中心涉及的都是银行IT系统体系中最核心的部分。
- 电子银行开发中心
主要涉及银行渠道类系统的开发管理；之所以命名为电子银行开发中心，是因为相关系统对应的业务领域主要是电子渠道领域的，外部用户可以通过这些渠道直接进行交易操作，涉及的系统一般包括：个人网银、企业网银、手机银行、微信银行、自助终端类等。
- 中间业务开发中心
主要涉及银行传统业务以外的中间业务系统的开发管理；此类系统很大的特点是包含子系统较多，涉及的关联系统、第三方系统较多，不论是投产上线还是生产问题排查，涉及的干系方也多。
- 管理信息类开发中心
主要涉及数据类系统以及企业信息化系统的开发管理；其中数据类系统主要涉及数据仓库以及需要以数据仓库提供的数据作为系统支撑的下游系统，例如监管报送类系统、CRM、绩效考核系统等；另外还有一部分是企业信息化系统，这类系统并不涉及对外提供交易服务，只是企业内部使用，是独立的一个体系，主要包括OA、门户网站、HR、财务报账系统、项目管理系统、协同办公系统等。
另外开发中心也会按照事业部条线进行划分，这样做能够更有针对性开展工作，和业务部门的结合更加紧密，一般会划分为：零售银行开发中心、公司银行开发中心、金融市场开发中心、其他事业部条线开发中心(例如数字银行开发中心)等，同时随着热门技术或领域的推广，例如大数据、移动互联网、智慧银行、金融创新等，开发中心为了更好的在这些领域进行深耕，在中心划分上也会体现这一点，例如会划分出大数据应用开发中心、智慧银行开发中心、金融创新开发中心等。
测试部门
测试中心的工作内容大致可以分为：测试管理工作、测试资源的管理、版本管控等。
- 测试管理工作
与开发中心的划分原则大致相同，原先是采用业务条线划分的方法，分为核心、电子银行、中间业务、管理信息等，后续也相应改为以事业部条线进行划分，分为：零售银行、公司银行、金融市场银行、数字银行等，这也是为了和业务、开发结合更紧密，更有利于测试工作的开展；银行系统的测试环节一般包括SIT测试、UAT测试、性能测试；其中SIT测试一般情况下是由开发中心来具体执行，测试中心制定标准和规范，评估测试结果是否符合出口标准，UAT测试则视情况而定，如果测试内容不多，且只是偏向于验收通过性测试，则UAT测试工作主要由业务人员或需求提出人员来进行，测试中心同样也是制定标准和规范，如果测试内容较多，单纯由业务人员来测试可能时间和精力不够，且对测试专业性有一定要求，则测试中心使用测试外包资源来进行测试，这些测试外包资源来自与银行签订框架合同的供应商，长期驻场进行测试工作。
- 测试资源的管理
这里所说的资源，主要包括人、物两方面，人的层面主要是指测试外包人员，测试中心根据情况就外包资源进行协调和分配；物的层面主要是指与测试相关的环境、设备等，环境部分测试中心主要涉及管理，具体搭建工作并不是由测试中心本身来做，而是由主机人员来做，设备部分测试中心在做管理的同时，还负责设备的发放和回收，包括移动设备和台式设备等。
- 版本管控
对于版本管控主要是两方面，一方面是各系统在开发、测试、上线中涉及的版本号进行管控，这既包括主系统本身的版本号，同时也涉及配套系统的对应版本号；另一方面是通过自动化版本发布系统进行版本发布，测试中心付负责制定版本规范，以及相关版本发布人员的权限。
运营部门
科技运营按照运营对象所属领域可以划分为：基础架构中心、机房管理中心、运维中心。
- 基础架构中心
主要包括主机、网络等IT基础类资源；主机部分涉及服务器、数据库方面的管理以及具体实施工作；网络部分则主要保障网络、线路的连通性，网络访问策略的可用性等；所以基础架构中心负责的是整个IT体系中较为底层的一些事务；
- 机房管理中心
银行中都会有存放大量服务器的数据中心和机房，机房管理中心负责的对象包括与机房有关的人、物；人的层面主要是对与机房有接触的人员的管理，物的层面主要是针对机房设备的管理，包括设备的摆放、迁移、维护等。
- 运维中心
运维中心做的事情比较杂，一类是负责IT系统故障、生产问题的跟进解决，运维人员需要对故障问题及时响应，如果自身无法及时解决的则需要及时分派给相应的开发人员；另一类是负责提供IT服务和资源的，例如需要申请账号、设备或者开通权限的，还有一类是负责系统生产环境版本发布的，但这里的发布是指运维人员有往生产环境发版本的权限，只负责执行版本发布这一动作，具体版本的打包工作还是由测试人员、开发人员来做；
安全部门
银行早期的信息科技部由于系统较少，整个IT体系结构还比较简单，对于安全方面还没有足够的重视，也没有足够的人力来执行，随着信息科技部人员的逐渐壮大，以及对于IT安全意识的逐渐提高，信息科技部中会单独划分出负责信息安全的中心；安全中心主要关注IT信息的安全性和保密性，同时负责收集相关补丁来抵御病毒对银行IT系统的侵害；银行是个对客户信息安全、系统信息安全特别重视的机构，所以安全中心的重要性也与日俱增。
工作模式
银行内IT项目的人员组成情况通常如下图所示
银行IT项目实行的是项目经理负责制，会任命一名行内科技人员作为项目经理，对项目整个生命周期负责；具体由谁来担任，则具体看这个项目属于哪个范畴，比如，自动化发布系统，属于测试中心范畴，则项目经理由测试中心的人员来担任；银行安全过滤系统，属于安全中心范畴，则项目经理由安全中心的人员来担任；自动化运维系统，属于运维中心范畴，则项目经理由运维中心的人员来担任；其余大多数项目属于开发中心范畴，则项目经理由开发中心的人员来担任；但银行内的项目经理的职责和权利是不对等的，给了你最大职责，你需要全权负责，你需要对结果负首要责任，你甚至需要背锅，但是你作为项目经理并没有与职责对等的权利，无法调动资源同时也无法体现出自己的想法，这种情况很大程度上是由于银行信息科技部的组织架构是以职能维度进行划分的，而不是以为项目为维度，项目中的干系人，包括业务、测试、运维等都是来自不同的职能部门，是听命于自己职能经理的要求，而不是听命于项目经理，他们从自己的KPI或者部门立场出发，那就肯定会做出这样的举动。
项目中的干系人主要包括业务人员、测试人员、运营人员，这些人员都是行内人员，另外还包括公司方团队，则主要包括公司方项目经理、开发人员、实施人员、UIUE人员、测试人员等；
- 行内业务人员
首先提下业务部门，所谓业务部门就是提出业务需求，相比于信息科技部自身不具备IT能力，也不拥有IT资源，希望通过IT项目的方式来满足自己的要求，同时需要明确项目的预算费用，同时业务部门也是最终享用项目结果，使用对应系统的部门，大多数情况下业务部门是除信息科技部以外的部门，当然有些项目由于自身的业务属性比较特殊，则对应的业务部门就来自于信息科技部本身，比如自动化运维系统、版本发布系统、IT运维系统等；业务人员就是来自这些部门的人员，他们负责和科技人员进行对接，对需求，整体建设方案进行把控，力求项目的最终落地成果是自己想要的，可以满足自己的要求。
由于业务部门是出钱，提需求的部门，信息科技部是花钱，实现需求的部门，由于这种角色定位就决定了他们之间的关系，谁出钱谁就相对有话语权，说白了更像是“爷”,业务部门的要求，信息科技部要尽量满足，通过使用科技手段来实现业务部门的要求，满足业务部门的需求，之间关系有点类似银行内部甲方乙方的关系，业务部门是银行内的甲方，信息科技部是银行内的乙方，当然业务部门还是会和信息科技部搞好关系的，这其实也是为了项目能够顺利的推进，自己的要求能够不打折扣的得到满足，如果关系搞不好，项目就会受影响，最终受影响的还是自己。
现在随着科技力量在全社会的大力发展，科技的发展确实在很大程度上是可以帮助业务的推广，所以科技在银行内的重要性得到了重视，信息科技部在银行内的地位也有提升，银行也提出了类似“科技引领”等一些听起来很高大上的口号，确实这些口号的提出也说明科技的被重视程度越来越高，但需要认清的是，至少从部门之间的博弈角度、话语权角度来看，科技还是偏弱势方，因为银行中的科技力量再怎么强大，那也只是“拥有雄厚IT实力，庞大IT团队的银行”，不管形容词再怎么多，最终还是银行，而不是“拥有银行业务能力的IT公司”，所以体现到表象上看，如果业务人员和科技人员对某一事情由于资源有限或者观点不一致，银行内采用的是前者“压”后者，而互联网公司或者泛IT公司采用的是前者“求”后者。
- 行内测试人员
银行信息科技部的测试人员，由于时间、精力有限，工作内容主要偏测试管理，本身不会从事具体的测试工作，具体的事情会分配给测试外包人员来做，这些测试外包人员来自与银行签订框架协议的供应商，是长期驻场工作的；从项目角度来看，行内测试人员主要负责的是UAT测试、性能测试等，首先根据需求情况安排测试外包人员编写测试案例，然后组织行方项目经理、公司方项目经理、业务人员、开发人员等项目干系人进行测试案例评审，然后根据项目计划和测试计划进行测试工作，按照测试结果和缺陷情况，督促开发人员进行修复，最终根据修复情况从测试角度给出是否可以投产上线的建议；
- 行内运营人员
如果以环境类型作为分水岭的话，测试人员主要负责测试环境的工作，运营人员则主要负责生产环境的工作；在项目执行过程中，参与的运营人员主要是基础架构中心人员，包括主机人员、网络人员、数据库人员等，主机人员负责生产环境服务器、系统环境的搭建等；网络人员负责网络地址、端口、线路、访问策略的连通性和可用性；数据库人员主要是DBA，负责数据库的搭建，同时保证数据库正常稳定的运行；有些大型项目或者重要程度较高的项目，对服务器主机要求较高的，可能还会涉及到机房管理人员的介入，等项目结项后，则进入运营阶段，细化到系统层面则是IT运维阶段，这阶段运维中心的人员会介入，主要是负责保证生产环境系统能够正常稳定的运行，同时对于故障和问题及时跟进，需要及时发现问题，响应问题，并及时反馈问题解决进展，由于运维人员对于系统的了解程度不如开发人员那么全面和深入，所以一些浅层次的简单问题可以自己来解决，但遇到较为复杂的问题，则需要及时将问题转派给开发人员并跟进解决进度；
- 公司方项目经理
银行内IT类项目主要是以外包的方式来做，那么从供应商的角度来看，自身需要任命项目经理对项目全权负责，公司方项目经理对银行，需要全面、仔细的获取需求，进行需求分析，制定方案，特别是产品以外需要定制化的部分，需了解清楚，否则路线跑偏了，不能满足甲方的要求，造成项目无法验收，而且也意味着资源的浪费，对公司也是一种损失，同时公司方项目经理还需了解行方的相关规章制度和管理要求，这样便于项目的顺利开展；当然公司方项目经理对于甲方的态度，需满足要求，但也不能一味的无条件接受，毕竟做项目是涉及成本、资源、周期的，同时方案的制定也是需要结合产品本身特性，如果脱离产品本身一味地满足甲方需求，则代表后续需要花大量的时间、经历、成本来履行你的承诺，所在方案制订过程中，公司方项目经理需要把自己的想法传递给行方，说明自身产品的特性，同时结合同业的经验给出建议方案；那么最终行方人员是否会接受，这其实是甲乙双方博弈的过程，在一定程度上还取决于甲方是否强势，如果甲方强势，坚持自己的要求，那对于公司方来说，意味着这将会是一个痛苦的过程，所以对于很多供应商来说，和银行做项目，特别是一期项目，都不指望能够挣钱，一般性都会赔钱，只是希望能够少赔点，目的在于和银行搞好关系，达成良好的合作关系，给领导留个好映像，后续二期、三期的项目可以想到自己，自身则是可以通过这些二期三期项目逐渐盈利；公司方项目经理对本公司，需要根据甲方的要求以及制定好的方案，在公司内部进行讨论，决定是否可以做，如果可行则协调包括开发、测试、UIUE、实施等在内的项目资源，推进项目的最终落地。
- 公司方开发人员
不同于公司方项目经理从前期交流阶段就需要驻场全程参与，公司方开发人员基本上等项目经理需求调研完成，最终方案已经输出并且得到行方确认后，才开始介入进来，主要负责的是产品本身以外的定制化部分以及和关联系统进行对接的开发工作；有些项目的公司方开发人员从进入到开发阶段，甚至是前期的方案交流阶段就驻场参与进来了，这样做的好处是可以便于沟通交流，特别是涉及和关联系统对接、联调测试的，可以更有利于开发工作的顺利推进，同时行方人员也可以随时了解开发进度已经和需求方案的吻合度是都符合要求，以防出现偏差，可以降低风险；但多数供应商出于成本考虑，不会安排开发人员长期驻场，顶多涉及到和关联系统进行联调测试的时候才会安排开发人员驻场工作。
- 公司方实施人员
实施人员负责将产品以及对应的实施方案在系统层面部署落地，如果公司方的开发人员是进行远程开发的，则会将开发好并通过测试的版本包发给实施人员，实施人员负责将版本包部署到系统中去。由于实施人员能否正确部署实施，决定了项目产出是否和预期的需求相符合，所以这就要求实施人员为了能够很好的了解需求，因此有些项目的公司方实施人员会和项目经理一起从前期交流阶段就驻场参与需求调研。
- 公司方UIUE人员
由于供应商提供的产品都是默认的版本，其风格样式都是带有公司特性的，比如logo、色彩、样式等，所以需要根据银行的要求对UIUE进行修改，也就是系统一打开就可以从风格样式上知道是哪家银行的；那么公司方的UIUE人员就会根据要求进行设计，如果方案认可，则交由前端开发人员进行开发；当然UIUE其实也是产品特性的一部分，如果无条件修改，则意味着成本的巨大投入甚至是系统的面目全非，所以基本上UIUE的修改都是针对一些关键部位，例如登陆页面、主页Title等；
- 公司方测试人员
在公司方开发人员完成开发后，首先会由公司方的测试人员进行测试，测试类型主要是SIT测试，测试范围主要是针对定制化部分，产品本身由于已经通过严格的测试，所以没有必要再纳入测试范围；通过测试后会将该版本交由实施人员，并由实施人员进行部署；当然公司方测试人员测试完还无法达到最终投产上线的要求，因为行方测试中心针对项目会有自己的测试要求，一般情况下产品部分不会再去测试，主要是针对定制化部分以及关联系统对接部分进行测试。
招聘
- 应届毕业生招聘
应届毕业生进入银行信息科技部是较好的一次机会，和社会招聘不同的是，对于应届毕业生的从业经验和职业技能要求没那么高，用人部门也清楚应届毕业生一般情况下不可能一进来就能独立的干活；所以银行信息科技部在应届毕业生招聘时主要看重这几点：
一是学历，基本上是要求本科毕业，而且越来越多的银行是要求硕士毕业，值得一提的是，对应届毕业生招聘来说，这里的硕士一般情况下是指全日制的双证硕士，既需要有学位证书，也需要有学历证书，而不是只有学位证书而没有学历证书的单证硕士，如果是单证硕士的话，银行可能不会认可。
二是毕业院校，如果是985院校最好，不是985院校退而求其次也得是个211院校，而且有些城市商业银行还比较偏向于总行所在城市的211院校，带有一定的地域性；所以很多银行的信息科技部在招聘启事上都会注明985、211院校优先考虑。
三是笔试面试表现，以上所说的其实是简历筛选的条件，银行的HR一般会把包括学校、学历在内的信息作为关键字进行搜索筛选，通过简历筛选，则进入笔试面试环节。笔试考察内容主要涉及数字、逻辑、文字、图形等，这和公务员行测考试类似，如果是IT岗位则还会额外考察计算机方面的相关知识。笔试通过后，就会通知去参加面试，面试的方式主要为无领导小组群面，5、6个应聘者为一组，每人分发一份材料，上面就某个话题进行描述，以及提出一些问题，每人花费大概5分钟左右的时间阅读材料，阅读完后每人轮流花费大概2分钟左右的时间简要阐述下自己的观点，然后花费大概30分钟左右的时间进行相互讨论，达成共识形成最后的观点，最有由大家推举一名成员进行总结发言。面试官在整个过程中主要考察每名成员的思考问题、解决问题的能力，对信息的抽象概括能力，以及语言的表达组织能力，还有就是团队协作能力；
所以银行信息科技部对于应届毕业生计算机专业知识是考察的一方面，但并不是决定性的，主要看重的还是学历、毕业院校、综合素质等方面，这点和互联网企业、IT企业的招人要求还是有所不同的，有些银行信息科技部可能会招一些非计算机专业大的毕业生。
应届毕业生入职后，有些银行可能不会让入职者直接去信息科技部工作，而是会安排先去做银行柜员，工作时间基本上是至少半年(也有可能少于半年的，比如2、3个月，也有可能多于半年，甚至一年多的，但大多数是6-8个月)，目的是让应届毕业生熟悉银行业务知识，而银行柜台是一个理想的工作学习的平台，工作满一定期限后，如果有意愿想转岗去信息科技部工作的，再通过内部招聘转岗的方式，调到信息科技部工作，当然不排除少数人原先想去科技部，后来在柜台工作一段时候后，觉得做柜员其实也是一种不错的选择。当然这种培养方式也有其弊端，原因主要有两方面：一方面，银行柜台学习业务知识3-4个月基本都可以接触到，剩下的时间只是在原有业务知识体系的范围内不断重复的过程，本身并不包含技术含量，对于业务知识学习本身也不会有什么提高，相反随着时间的推移，长时间不接触IT领域的知识，可能会导致对IT领域的知识和技能逐渐荒废，这对于需要去信息科技部工作的人来说是不利的；另一方面，应届毕业生从分支行的柜台转岗至信息科技部工作，这点也并不是完全由自己意愿控制的，银行会尊重你的想法和意愿，但并不是自己想走就能走的，还需要原先所在分支行放人才行，如果遇到原先分支行以种种理由(比如目前缺人手，需等新人入职后顶替你的位置，你才能离开)扣人不放的，那也是很无奈的，对自己今后的发展也是不利的。
- 社会招聘
社会招聘的人员来源一般有两种类别，一种是原先与银行合作的供应商人员，被银行挖过去成为银行员工的，也就是从乙方人员变成了甲方人员，这类人员一般是原先供应商中项目的核心人员，对项目、系统的情况都比较熟悉，工作能力和个人情况行内员工也比较熟悉，从银行的角度来看，如果这类人员一旦流失，对于项目本身来说无疑是一种损失和冲击，同时这类人员由于之前在银行长期驻场做项目，对银行内部的项目情况，规章制度，流程要求，人员组成都很熟悉，跳槽到银行的话不需要适应过程，直接就可以投入工作，所以银行要通过社会招聘找人的话，这类人员是比较好的选择。还有一种就是其他银行或公司跳槽过来的人员，有相关的工作经验和工作能力，这里就不再赘述了。
这里想描述一种奇怪的现象，一般会发生在从原先乙方公司跳槽到银行的人员，他们在对于老东家时的态度有时候会发生微妙的变化。由于甲方乙方这种合作模式的原因，甲方一般会扮演管理者，提要求者的身份，而乙方则会扮演执行者的角色，由于人性层面的原因，都希望自己能给对方提要求，让对方满足自己的想法，同时自己又不愿意听别人发号施令，由于这种心态的存在，导致角色一旦发生转变，做事情的方式和态度也会发生转变，这些从原先供应商那里跳槽过来的员工，有时候可能会失去原有的“阶级感情”，曾经的同事此时在他们看来只不过是自己管理、命令干活的对象而已，甚至把对方视为自己的马仔，举个可能不太恰当的例子，这些人好比农民进了城成为居民，却又对原来一个村的老乡充满鄙视。他们的这种态度和方式我个人还是不认可的，我对于供应商的态度一向是“既要斗争又要团结”，要斗争是因为银行作为甲方毕竟是付钱购买产品和服务的，需要完成项目任务的，站在银行的立场和角度需要谨防供应商的偷工减料和人为因素的延期，要团结是因为尽管是乙方，但也和我们一起是一个项目组的，人的层面本身没有高低贵贱之分，不能一味的以敌对和压迫的态度对待对方。
收入、工作与发展
薪资福利
银行信息科技部的薪资可能不及互联网公司或者IT公司的薪资高，在整个IT行业处于中上等的地位；具体给多少薪资还是看入职后给自己定的职级是多少，职级定了薪资也就定了，所以有些刚入职的应届毕业生会遇到这样的情况，为什么自己是硕士学历，薪资怎么和同一部门的本科毕业生一样，那就是因为两者定的职级一样；银行信息科技部的应届毕业生的薪资起点属于中上等，但后续的加薪频率较慢且涨幅较小，不会像互联网公司那样每年甚至每个季度都会涨；年终奖则根据年度KPI考核情况来看，一般情况下只要考核结果不是很差，年终奖一般大概2、3万的样子，如果你的考核结果很好，年终奖对应会多些。
银行信息科技部的福利情况还是不错的，一方面五险都是足额缴纳，特别是住房公积金这块比例较高，而且会提供住房补贴，举某城市商业银行的例子，一般企业住房公积金个人缴纳比例为8%，公司缴纳比例为8%，银行个人缴纳比例为12%，公司缴纳比例为12%，另外还有15%的补贴比例；另一方面，还会定期发放过节费，购物卡、汽油报销费用，过节礼品等，举例来说，过节费分别是劳动节2000元，国庆节2000元，元旦节2000元，还有一次年度旅游费2000元，另外每月发放500元超市购物卡，500元汽油报销费额度，同时还有一些儿童报销费用等。
工作强度
银行信息科技部原则上不强制加班，主要看自己手头项目情况或者事情多不多，如果手头事情不多，那就正常下班，到点就可以走了，也不用担心领导没走自己能否走，如果多的话只能留下来加班，而且如果项目比较急，那加班的频率会比较高，而且都要加到很晚，同时如果遇上需要投产上线的版本日，那肯定要加班，如果负责上线的是对外提供交易服务的系统那得等到交易量少的时候才能开始，一般都是凌晨。另外也有特殊情况的，例如遇上银行重大项目的，需举全行之力来做，那就需要强制加班了，可能是886(8点上班，8点下班，一周上6天，甚至7天)，周末上班必须来，不来领导会找你，当然会算你加班费，当然这是少数情况。对于加班这件事情，需要辩证的来看，一方面确实幸苦，占用自己大量的时间，另一方面也要看到，如果自己一直很清闲，到点就走，则意味着自己做的事情并不被重点关注，自己有可能被边缘化，加班其实也蕴含着学习成长甚至晋升的机会。
银行信息科技部由于是后台部门，不直接面对客户，所以一般不出差；但由于银行也正受到各方面的挑战和冲击，为了会更好的发展和盈利，银行的角色也在改变，由传统的甲方逐渐在某些方面变为乙方，例如有些项目是给政府部门或者事业单位做的，为了更好的获取需求或者提供服务，需要伴随一定的出差，但时间不会很长，少则几天，多则一个月。
所以加班出差这种事情也没有绝对的，还是看项目情况，而且看待的态度也需要辨证性。
晋升机会
职级
银行信息科技部的职业序列，从行政角度来看一般会有如下职级，如下图所示。
- 分管行领导(副行长)
银行中会有若干名副行长，每名副行长分管若干个部门或者事业部，例如有分管零售银行总部的行领导，有分管公司银行总部的行领导，有分管计划财务部、法律合规部的行领导等，这其中就包括分管信息科技部的副行长，即信息科技部的分管行领导。
- 总经理
总经理是一个部门的老大，随着银行事业部制的改革，信息科技部总经理也会被称为CTO。
- 副总经理/总经理助理
总经理之下会有若干个副总经理或者总经理助理，任命总经理助理是因为副总经理的名额是有限的，一个部门内的副总经理名额就那么2、3个，某些人员已经符合升为副总经理的条件，由于名额原因，先任命为总经理助理，总经理助理相当于副总经理级别；副总经理或者总经理助理会分管若干个中心，例如有分管开发中心的，有分管运维中心的，有分管测试中心的等等。
- 中心经理
中心是信息科技部的最小行政单位，中心经理就是每个中心的负责人。某些中心人员较多的，同时还会设置中心副经理。
- 员工
基础办事员。有些中心内部，为方便梯队化管理，会划分小组，每个小组会设置组长，虽然同样是员工，但从级别上会分三六九等，需要看你入职定的是什么级别，可能身边的同事和你同一个岗位，但人家可能是社招进来的，水平能力都比较高，那入职定的级别也就高。
所以银行信息科技部的行政职级的晋升路线就是按照以上级别来进行的，但银行里的职位是一个萝卜一个坑的，想要晋升不容易，并不是工作能力强成绩好就可以晋升，还需要参考其他诸多方面的因素，一名应届毕业生在银行里干个几年，如果能升到中心副经理已经很不错了，而且一般情况下，银行里的领导都不是本银行一步步升上来的，而是从其他银行或是企业跳槽空降过来的，有时候空降来个大领导，那么这个大领导原先所在公司的嫡系人员，也会一起过来成为各级别上的领导，而且都身居要职，后续如果遇到晋升机会，也是优先会考虑这些人员，毕竟从人的角度来看，还是会优先考虑自己人，对于应届毕业生来说，属于没有“派系”的人员，想要在银行里一步一步往上晋升难度着实不小。
另外，现在有些银行专门针对信息科技人员建立了IT职业序列，一种区别于传统行政序列的独立职级序列晋升路线，这似乎让专心想从事技术工作的科技人员看到了希望，但有人算过一笔账，从一名普通员工通过IT职级序列晋升至副总经理，理论上需要18年，而且这种管理方式也刚起步，没有建立起成熟的体系，是否可以开辟出一条新的路线还有待考证。
自身成长
对于很多应届毕业生来说，选择银行信息科技部时会考虑能否学到东西，这就要看想学到哪方面的东西。首先来看下银行信息科技部的工作模式，主要采取的是和乙方供应商合作的模式，采购供应商提供的成熟的产品，然后在此基础上再做定制化改造，这样看来银行与供应商之间就是传统意义上的甲方乙方的关系，银行提出需求，花钱购买产品和服务，属于甲方，供应商提供产品和服务，赚取费用，属于乙方；这样做的原因有三方面：第一，供应商都是在某些领域内比较专业的厂家，他们的专业性、为同业服务的经验可以为银行所用，这其实也是银行规避风险的一种方式；第二，如果银行完全从零开始研发建设系统，那么投入的时间、经历、预算都是巨大的，周期也是漫长的，在一定程度上也存在风险，肯定不如现成产品来的稳定；第三，除少数几家国有大银行的IT团队规模较大，实力较雄厚，具备能够独立研发复杂系统的能力，其余大多数银行的IT团队的实力还不足以从零开始研发复杂系统的能力，顶多可以研发一些规模较小的内部管理系统；
所以信息科技部的日常很多工作，都是建立在供应商产品以及对应服务支持的基础上的；虽然行方人员在项目、系统建设过程中会对产品逐渐熟悉起来，但是一旦出现问题需要解决，很大程度上还是需要依靠供应商的力量来支持。行方人员主要是明确需求、实施建设方案，更加偏向于管理，同时要求供应商根据行方管理要求和方案要求执行具体工作，包括开发，实施等。有些计算机毕业的同学，想好好学习技术能力，特别是开发方面的能力，相对来说这不是好的选择，开发工作主要会让外包人员来做，毕竟他们在一些系统细节方面要比行方人员要熟悉，而且有些产品供应商不对提供源码，当然银行信息科技部也逐渐要求需要有自主开发能力，能够自己写代码，但毕竟承接的代码开发工作都是些优化修改的工作，并不涉及系统核心模块的改动，而且行方人员的主要精力还要放在其他诸多的例如方案制订、项目管理中去，你无法全身心去做一名安静写代码的美男子。同时银行使用的都是些比较成熟稳定的技术手段，不会使用刚兴起的热门技术，就算使用到了也已经在其他公司使用过很长一段时间了。
另外同为信息科技部的子中心，但彼此之间的话语权还是有高低的，这可以体现到今后工作开展是否能够顺利，预期能否如自己所想，人家能够买你的帐等。那么还是从上文列举的几个中心来看：
- 规划中心。
规划中心负责IT体系的建设规划，计划制定，定标准定规范，所以很有话语权，毕竟人家是制定计划和规范的，后续工作的开展都必须符合这些要求。而且银行中的IT工作的开展，比较重需求，重方案，重计划，重预算，这些要素都与规划中心相关，可见其重要程度。
- 科技运营部
科技运营部话语权也较高，因为他们定制度、定标准、管资源、管权限；首先从基础架构角度来看，负责的都是主机、网络、数据库等底层基础的建设，尤其重要，自身也会根据管理要求提出IT体系的相应规范，制定行内标准，后续系统建设过程中都必须要符合这些标准，否则视为不达标；另外系统在建设过程中，涉及的主机、网络操作还需要在他们制定的变更日才能执行；其次从于运维角度来看，银行信息科技部在重规划的同时也注重运维，毕竟保障生产系统安全稳定的运行是首要任务，所以会建立相关的规范、标准和机制，项目建设和系统搭建过程中需满足这些要求，同时对权限也进行严格管理，如果需要触碰生产环境，则需要进行权限申请；同时为了保证生产环境的稳定有序，避免由于频繁变更对生产环境带来的冲击，运维中心还会制定版本日，例行的投产上线工作只能在版本日进行，所以版本日在一定程度上已然成为IT系统建设过程中一个非常重要的时间节点。
- 测试中心
由于测试中心负责对于版本的管控，测试资源的管理，以及对于测试过程制定标准和规范，所以也具有一定的话语权。
- 开发中心
开发中心相比于以上中心，话语权属于较轻的，因为开发中心负责具体事务的执行，并不负责管理资源或者制定规范标准，开发中心负责将方案落地成为现实，但这还没完，还要看是否满足制定的要求和标准。互联网公司或者IT公司对待开发人员的态度是“求”,但在银行中对待开发人员的态度则是“压”。而且银行信息科技部的开发中心人员处在一个较为尴尬的地位，首先任何银行系统的建设都是为了满足业务的，是业务驱动，所以要求对于需求、业务比较熟悉，这样有利于系统更好的落地，但对于需求本身的熟悉程度不及业务人员；其次，从技术角度来看，银行系统建设是建立在供应商产品的基础上，技术手段的开展又受制于此。
