当前位置: 首页 > 办公技巧 > 正文

银行办公室技巧(银行的IT人该如何面对来自领导的高压?)

  • 叁碗诸角 叁碗诸角
  • 办公技巧
  • 2023-08-25 19:16:28
  • 0

作者|苏文力

看懂经济专栏作家,曾供职于阳光保险、中国工商银行(TA已经入驻看懂App小程序)

最近有些公司遇到了经营困难,采取了适当缩减成本的举措。涉及IT资源的整体投入下降明显。IT部门面临减少IT人员数量,降低系统运营费用的巨大压力,而相应的工作任务目标要求仍然很高。

听到一位企业老板介绍其心得:“IT总是有潜力,就如同橙子,只要给的压力足够大,总能挤出汁来。”相信这一定是他的心里话,因为他就是这么做的,并且屡试不爽。IT部门也总是配合证明他是正确的。

向IT大力施压,似乎变成了企业领导惯常的管理手段,压力不断加码,IT还有苦说不出。有次公司遇到了非常棘手的业务问题,需要IT快速帮助解决。大领导听到进度安排后,不由分说,大幅缩短了任务完成的期限。

赶紧向领导解释说明。表示我们完全理解该工作的重要性和迫切性。已经安排了加班,很多人都吃睡在了办公室,几乎是连轴转。鉴于时间太紧,实在力所不能及。希望领导能够理解,给予一定时间的宽限。

大领导半开玩笑半认真的说:“既然有时间吃饭和睡觉,证明你们还大有潜力可挖啊!”。听了这话,心里很不是滋味。既然领导都说到这份上了,咱也就别争了。默默收拾起心情,赶紧想办法交差吧!

最后这件事还是按要求完成了,再一次证明了领导的“英明”。我们肯定是拼尽了全力,但显然还是吃饭和睡觉了。并不是我们有什么神奇的魔法。秘诀在于我们改变了任务完成的内容和质量。

领导只能看到任务目标实现的表面部分,而看不到完成的具体内容。IT开发中,有许多工作是隐含着的。涉及系统容量、数据安全、差错处理等非功能需求的实现,对开发工作量的影响极大。

外行根本不清楚这其中的道道,也没必要过多了解。一般这都是由IT系统开发设计人员,以专业负责的态度,从照顾长远,还是看眼前,是要保质量,还是速度优先等方面,做统筹平衡选择。

领导给出的巨大压力,就是在强调其中的某一方面,是领导自己在做选择,压缩了IT开发设计人员选择的空间。既然领导强调进度,那就减少要完成任务的内容和质量,先凑合着搞出来,回头再找机会完善。

这就如同装修房子,若客户一定要在某个时间期限内完成,那就只能先把功夫下在看得见的地方了,而对表面看不到的地方,不管是否重要,能省则省,结果肯定会影响到后续的使用体验。

赶进度开发出来的系统,在一开始业务量不大的时候,还能凑合着运行,但当业务量激增时,那些曾经舍弃掉的部分,就会跳出来惩罚你,不仅会时不时出现各种故障,甚至可能引发灾难性后果。

IT部门十分清楚其中的风险隐患,一般会在系统上线后,第一时间安排开发弥补所存在的缺失漏洞。也就是说还要经过一段时间,才能完成全部开发任务。这会造成大量返工,期间还要期待好运气,别出生产事故。

企业领导一般不太清楚IT人员究竟都在做什么,总感觉人很多。当企业日子不太好过时,则会实实在在的感受到这些人所带来的成本压力。内心对提高IT人员的工作效率,有着强烈的期待。

这样的偏好,会引发一部分IT人员的主动迎合。自己曾经供职的一家集团,其子公司所属互联网事业部下的IT团队,总能在很短时间内完成互联网产品的系统开发上线。集团和子公司领导对此相当认可。

赶紧安排学习取经,却并没有发现其中有什么提高IT开发效率的诀窍。本质上就是前面所提到的,主动忽略掉一些重要但并不紧急的工作。实际上是在给后面的工作埋雷,极易造成未来容量、安全等方面的问题。

可领导显然不喜欢听到这样的反馈,咱也无法多做解释。由于该事业部的业务没做上去,业务量有限,系统容量上还能撑得住。但其网络防护上的漏洞则很快暴露出来了,且成为了整个集团公司防护体系上一个薄弱环节,问题被进一步放大。

自己曾估计到其在防网络攻击上会偷工减料,可没想到居然会到如此程度。还好发现的早,没有造成太大的危害。赶紧安排其他团队去支持,将漏洞补上。可该行为对扎实做事的公司IT开发文化所造成破坏,就需要较长时间弥补了。

企业领导对IT业绩特定考核指标的重视,也会对IT产生很大影响,甚至会波及到IT专业的系统架构领域。多年前,老东家特别强调IT系统的生产运行稳定。在对IT部门的考核中,对相关指标的达成有特别严格的要求。

当时正值电子银行业务快速发展的时期,业务交易量持续大幅攀升,配套的机器设备需要不断扩容。而基于主机系统的技术架构,所需要的设备只能单一来源采购,价格很高,总体费用惊人。

尝试寻找其他更为经济的替代解决方案。想到将一些对系统一致性处理要求不高的业务,搬到开放平台上,这样在技术上就有了新的发展空间,更多的选择意味着采购时有更大的议价谈判权。

很快就确定从业务呈现爆炸性增长,系统处理简单,且与其他业务相对独立的活期历史明细查询功能人手。工程进展十分顺利,可投产当天因经验不足,未能按时将该部分服务对外上线。

延误了大约十几分钟,只对极小一部分客户有影响。对于整个系统架构的调整工作来说,应该说是一次比较成功的实践。出现一些问题很正常,是必须经历的学习过程。考虑到代价并不算高,局面完全可控,自己还挺得意,

可部门领导却不这么看,认为这是一次严重的生产事故。并全盘否定了该架构调整,要求我们重新退回到原来主机处理的模式。不仅如此,还提出更为过分的要求,将其他一些原本就采用开放平台架构的系统,也搬到主机上。

一开始我很抵触,努力想说服领导,可其十分坚持,主要考虑的就是年底考核。新开放平台架构的确省钱,但一段时间内的确会降低生产运行的稳定性。考核中没有省钱的要求,却对生产稳定性有严格的要求。

这样的决策虽然符合部门自身的利益,可对公司利益肯定有所损害。短时间看不太出来,从考核表现上,公司领导挺满意。购买设备只是惯性的操作,公司也承受的起。省钱的事情,反而没有太多人关注。

后来证明自己没有极力坚持是个极大的错误。同时代的一些大型互联网公司则因无法承受主机的高昂费用,全面采用开放平台架构。经过十多年的积累,成功的站在了IT新技术应用的前沿。

IT有较高的专业门槛,对其的一些管理举措,所产生的反馈信号存在很大的滞后和偏差,需要较长时间综合来看。可人们往往乐于将焦点放在最容易取得成效的目标上,把它作为解决复杂问题的抓手。

短时间内反馈出来的结果貌似挺好,可实际上是以对另外一部分的损害为代价。重视了其中的一部分,很可能引发另一部分出现状况。得到了想要的某些结果,伴随而来的还有其他次级后果。

仅仅预见到自己行动所造成的直接结果,只是简单的一阶思维。出发点是好的,以为是在做正确的事,却忽视了结果所造成的后果,很可能是在给自己挖坑。若从整体来看,或许就有些得不偿失了。

我们应提前从更长远和全局去思考,考虑更深层次的结果,即二阶思维。预判所做决定还会引发其他什么样的结果,从而修正不恰当的决策,帮助规避问题,预测挑战,提前加以应对。

领导不要期望通过提出“即要、又要、还要、更要、特别要”句式的要求,就可以将一切都置于掌控之下。IT作为执行者,在有限的资源条件下,不可能创造奇迹,很可能做出损害整体利益的取舍。

对IT应追求最后有好的综合结果,这其中一定需要有平衡和妥协,而不是在各个细节上的最优。领导应对IT专业充满敬畏,尊重客观规律,将IT专业的权利和责任交给IT自己。

要相信IT团队有意愿和能力把工作做好,也相信自己会做出最好的决策。先不要轻易表态,要让IT部门阐述他们的理解,相应的解决意见,所预测的可能结果,以及为此将要付出的代价。

IT资源虽可以在短时间内通过加大投入予以扩充,但毕竟是有限的。决定去做了什么,所消耗掉的资源,就无法再用于做其他什么了。因此一定要衡量判断究竟该做什么,依据就是要看这事的重要和紧急程度。

如果重要且紧急,那显然必须赶快安排;如果重要但不紧急,则不能轻易舍弃,一定要安排在恰当时间之前完成,否则随着时间的流失,事情一定会变得紧急起来,搞不好会遭受时间不够的惩罚。

领导一定要保持足够的耐心,不断深入提问:为什么要这样考虑?这样做的目的是什么?还有哪些可能呢?这样会带来什么结果?促使IT部门将问题考虑的更周全。领导自己则可以掌握更全面的决策信息。

当公司领导有要求时,IT部门要主动思考其重要性,所要达到的目标和最终拿到的结果,可能的方案措施,将引发的次级后果和代价,所需相关方的配合支持,以及其他更好的方案选择等等。

针对思考的结果,站在公司领导的视角做出预判,争取对公司利益最佳的决策和行动。若发现事关重大,一定要争取向公司领导做出汇报,请其掌握更多的决策信息,获取其更多的支持。

有一次接到人行文件,要求短时间内完成某项政策调整。因前期与业务部门的沟通出现问题,耽误了开发工作的安排。眼看时间一点点过去,开发测试的时间已明显不够,事情就闹到行领导那里了。

行领导召集业务与技术部门就此事展开讨论。直接忽略了前期双方沟通的问题,先一起确认最终要达成的任务目标,然后明确指出这不仅仅是IT的事情,是行里必须不折不扣做好的事情,要求大家一起想办法。

大家立即就站在了一条阵线,不分彼此你我,考虑的重点变成了确保任务完成。大家实事求是的分析了现有开发资源所能做到的极限,勉强上线可能蕴含的风险隐患,业务可以接受的最低要求,以及其他可行的方案。

最后商定大幅减少提交IT开发的需求范围,聚焦于开发最常用的业务操作部分,将一些开发工作量大,特殊情况才用的功能,由业务安排手工操作。其间行领导不断提问,而最后给出的总结安排,让大家都很服气。后续也顺利达成了任务目标。

企业领导给IT团队越多的信任,越多的尊重,越大的空间,IT团队就会越有责任意识,越能够充分调动起自身的才智和能量,越能发挥出专业上的优势,也就越能够为企业做出贡献。

苏文力在看懂经济上发表的文章

一、创新与转型

1、用“第一性原理”思考金融创新

2、金融企业互联网转型工作中的3个忠告
3、大数据工作的正确打开姿势
4、金融机构开展人工智能应用,你应该了解这3点

二、数据隐私

5、重新认识隐私
6、315痛批用户隐私泄露,数据安全该何去何从?

7、大数据保险会影响社会公平吗?

三、区块链

8、关于区块链,您应该了解这三点
9、区块链给金融科技创新带来新机遇
10、让数据资产变现—利用区块链实现数据使用权流通的构想

四、IT与业务

11、做好需求分析是提升金融企业IT应用水平的关键

12、金融企业竞争需要IT队伍前置
13、金融企业IT和业务水乳交融七条建议

14、自主研发与引进国外系统间的选择
15、“老司机”告诉你核心系统建设中的5个常见错误
16、金融机构,这三招让IT公司真正成为你成功道路的伙伴!

17、IT安全生产运行可不仅仅是IT团队的事

18、怎样的IT工作才会让金融高层领导满意?

19、为什么IT项目开发周期远比想象中的长?

20、IT开发人员怎样转型成为业务人员?

21、怎样才能让IT产品更受金融机构欢迎?

22、金融机构怎样才能有效推动IT治理?

五、领导力与制度建设

23、码农也能搞承包?!

24、遇到了贵人领导
25、科技引领战略不能只是一句口号!

26、布置工作给个眼色已经远远不够用了!

27、说“不”让事情更靠谱

28、走出专家角色定位的舒适区
29、您听懂金融高层领导的声音了吗?

30、管理者到底应该怎么授权?

31、加班带来了怎样的价值?

32、一项容易被忽视的重要沟通技能

33、学会当教练,才是好领导

34、困惑焦虑脑中缠,找个教练聊聊天

35、高效制定工作方案也有“满满的套路”

六、营销

36、保险代理人,未来你要成为网红才行!
37、将金融网点变成社交场所,一家保险公司的实践将

七、其他

38、大多数培训学习都只是走过场

39、金融从业者应该掌握的IT知识
40、银行为何在个人支付领域节节败退?

41、网络安全防护那些事儿

42、市场需要更加高效的中心中介!

43、银行做金融科技公司,或许那不是你的菜

44、留给中小银行和保险公司的时间不多了~

45、金融产品创新管理的前世今生

46、高科技武装下的银行网点能带来什么价值?

47、金融IT应小心陷入单纯追求技术目标的误区

48、金融机构如何应对疫情带来的线上化升级挑战?

49、那年,宇宙行主导了中国支付领域首次重大变革

50、成为变化世界中更受欢迎的人

51、尚待开拓的2.5亿客户市场

52、摘掉低情商专业人员的标签

53、学过没问过,还是会错过

54、这样的金融创新还是免了吧!

55、“蚂蚁”成功的底层密码

56、金融数字化转型要“摸着石头过河”

57、别让创新掉进“不接地气”的坑里

58、存折是怎么没的?

59、银行打造优秀团队的五个要点

60、宇宙行为何将软件开发中心设在珠海

61、“抄作业”行不通了,银行该如何创新?

62、探索应用区块链踩过的坑

63、企业战略决策规划如何能更靠谱?

64、金融机构要从两个方向激发员工动力

65、“元宇宙”将深刻影响金融企业的未来

66、金融IT服务亟需走出负向循环的怪圈

67、金融机构怎样才能让业务与IT人员更好的融合?

68、金融科技创新中的三个大坑

69、金融企业数字化转型必须迈过这道坎

70、从电脑到讲台,一位金融开发者的成长

71、金融机构数字化转型应围绕产品展开

72、打破数字化转型中的部门墙

73、金融机构的数字化转型离不开企业文化的引领

74、金融企业共享中心的未来发展

75、“人”的转型才是金融机构转型的关键

76、被耽误的金融机构数据治理

77、一位金融IT老兵的成功心法:追求成绩,既要成就业务,也要成就IT自己

78、金融IT都忙死了,如何解套?

79、为了开发银行核心系统,我曾经夜不能寐、胃疼到食不下咽.....

80、如何拓展金融IT人的思维模式?

81、金融机构不可不察的IT系统架构

82、金融机构亟待升级的IT与业务合作模式


最新文章