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

Dear 丶 2023-06-19 02:29 4阅读 0赞

有时IT团队很努力的在工作，投入了大量的热情和精力，项目所表现出的最终效果却很一般。究其原因，很可能是忽视了项目的最终目标，陷入了单纯追求在某些技术局部上取得成果的误区。长此以往， IT团队很难赢得企业领导的充分信任，造成自身影响力受限。

**一、思维中的局限**

大学毕业设计时，老师让我负责开发田径运动会信息系统。项目都到了测试阶段，老师对最后计算形成参赛各团队总得分成绩单的速度不满意。就找我讨论，有什么方法可以更快的获得计算结果。当时的计算机性能很差，通过增加计算资源的方式无法解决问题。

很快想到用存储空间换计算时间的方法，但会引起一系列副作用。首先相应的数据结构设计看上去很笨重，完全不符合教科书上的完美要求；其次配套操作流程也要改变，带来很多人工操作环节；三是要调整现有系统，增加大量开发工作量。

原设计虽然计算时间周期较长，但出结果的速度肯定比手工计算速度快的多。只要在最后一个单项比赛完成后，我们操作的动作迅速一些，最终应用效果应该还是不错的。当然新方案明显更能确保快速拿到最终团体总分成绩。一想到新设计方案的笨重繁琐，就实在不想采用。

老师非常耐心的从工程角度给我做工作，而我却怎么也听不进去。最后总算达成妥协。新方案所涉及增加的工作部分由另外一位同学负责，我还是继续按原方案工作，但要配合新方案提供接口数据。这次与老师的激烈争论，还在同学间传开了。让我在同学中很有了一些不畏惧权威的名声，自己一度还有些自鸣得意。

投产验证的时刻到了，在北京市高校田径运动会上，我们开发系统的编排秩序册、检录和单项成绩公告等功能都运行的十分顺利。最后一个比赛项目完成后，赶快操作计算总分，一切都在按设计要求顺利的进行着。不一会儿，负责新方案的同学拿出了总分成绩单，交给了组委会领导。我所坚持方案的程序还在运行中，听着计算机咔嚓咔嚓的运转声音，自己既焦急又无奈。

随着主席台宣布完团体总分成绩，运动会圆满结束。我的方案计算结果终于也出来了。的确比过去手工计算快，但显然还是不够快。组委会对我们这套系统给予了充分的肯定。特别表扬了递交团体总分成绩结果的速度，让运动会有了一个非常完美的结尾。看到组委会领导兴奋的神情，终于明白了老师为什么坚持一定要不惜代价尽可能快的拿到结果。

自己关注点一直放在项目功能的实现上，而没有从用户角度思考其体验要求。让体育场内众多运动员和观众持续等待，即便是多几分钟，也是感觉十分煎熬的事情。能够提前出结果，恰恰就是我们系统最需要表现出的亮点。自己曾经的想法太狭隘了！

另一件让我印象深刻的教训是在老东家建设全行网络系统的项目中。在方案前期研究论证阶段，我提出用微型机联网的设计思路。从技术上看，完全符合工程要求，施工难度比较小，投入成本也非常少，还可以快速实施见效。领导却认为该思路存在局限，这件事后来交由其他同事负责了。

很快最终方案确定下来了，与自己曾经的思路完全不同。方案采用国外最新款小型机在各省和地市分行部署联网，所需费用成倍上升。由于涉及到新设备和配套系统的学习掌握，还需要安排出国培训。还要安排一系列开发和试点验证工作。工程难度和周期都大幅增加。这让我有些想不通，为什么要采用如此大动干戈的方案呢？

工程实施过程中，各分行的领导，以及IT部门人员表现出非常高的参与热情，进展十分顺利。让我没有想到是该项目除搭建了高质量的主干网络系统外，还带来特别有价值的附加效应。各级领导对于全行网络建设给予了积极的关注，全行上下达成要全面启动业务应用网络化的共识，为全行IT应用迈上网络化台阶奠定了基础。

这让我反思，如果采用我提出的方案去开展该工程会怎样。很可能各级领导看到如此少的经费投入，这么小的工程规模，就不会有如此的重视程度。若方案没有太多新技术内容，具体工程人员也就不会有太多参与的热情。估计工程也可以正常完成，但很可能也就在不温不火中结束。很难推动后续全行IT网络化应用的全面开展。

**二、站在系统全局看问题**

IT人员做项目时很容易站在技术角度考虑问题，更多关心的是项目本身问题和解决问题的技术细节。若眼睛里没有整体观念，对于到底要达成什么目标缺乏认识，很可能就会显得不合时宜，甚至成为绊脚石。要思考为什么要启动这个项目，其将带给企业什么价值，最终完成后究竟是什么样的状况。要以终为始去思考，看清楚未来目标，再回到当下，确定自己应该做些什么才能更好的达成目标。

项目中所采用的各种技术手段，都只是起到辅助作用。自我陶醉于技术本身，会让我们忽略掉企业的最终目标，给项目带来失败的后果。一定要放下自己单纯的技术追求，面向实现企业的目标，发挥自己的技术优势，提升自己的专业能力，扮演更加积极的角色。

领导和业务部门往往需要对最终经营结果负责，因此对于目标的理解更清晰准确。IT人员站在技术的角度，受自身角色的局限，有可能对业务目标缺乏深入了解。应充分相信领导和业务部门，耐心倾听理解，了解其所要达成目标的最后结果究竟是什么，为什么这么重要。这样一般就能够比较好的掌握该事情的目标。

技术有其专业性，某种程度上也表现为一种权力。领导和业务部门不太明白其中的门道，又非常依赖技术的帮助，有时处于比较被动的位置。他们特别希望搞清楚技术方面到底在想什么和做什么，怎么才能充分发挥技术的作用为提升企业竞争力服务。在此过程中，特别需要技术与业务之间建立起充分的相互信任。

技术方面不能滥用所掌握的技术权力，一味方便自己或追求自己在技术专业上有所斩获。必须首先将企业的最终目标放在第一位，一切从大局出发。领导和业务方面也应理解技术方面对于技术专业的追求，支持其在满足最终目标要求的过程中，有自己专业上的学习探索。

现在更多金融企业强调科技引领。在执行过程中，有些IT部门的管理者专注于做自己感兴趣的技术专业事情，盲目强调技术先进性对企业的作用。结果费了很大力气，做出来的东西并不能带来业务上的收益。甚至失败后也还不能认识到自己的错误，却将问题归结于当前技术还不够完美。

一定要先想明白到底业务需要的是什么，最终做出来怎样的东西才是业务真正所需要的，业务会如何使用这些成果，会为其带来怎样的价值。必须要与企业领导和业务部门的人员一起讨论技术架构和技术平台的建设规划。千万别认为这些都是技术部门自己的事情，避免导致工作方向上的偏误。

要想方设法让领导和业务人员了解技术会带来什么。讨论中切忌简单使用技术概念和词汇，而应该用那些能够让对方理解的语言去讲解。如果你无法解释清楚到底技术上做的是什么，能够为业务带来什么，那么你对所要做的事情根本就没有真正想明白，那就还需要更深入的研究思考。

例如很多IT部门热衷于从技术层面建立数据仓库，认为会对满足未来业务方面数据统计和分析带来很大帮助。为此投入了大量开发资源，或许在技术实现上完成的很先进。实际应用下来就会发现，真正产生的业务价值并不突出。IT人员可能会强调业务方面不积极，各个系统缺乏统一规划，数据缺乏统一标准等等客观原因，但难以推卸自身的责任。根本错误很可能是对技术抱有不切实际的幻想。

技术上的很多好想法，需要有业务上的配套支持，而业务发展的现实状况很可能不具备相应的条件。片面强调在技术上做出完美解决方案，就会带来曲高和寡的局面。正确的做法应该是瞄准未来的最终结果，结合现实条件，开发实现能够快速带来业务价值的需求，先向前迈出一步。这样不断积累，待条件成熟后，就会水到渠成做出适合业务发展的好平台。

业务发展到一定程度时，受到现有技术架构的限制，技术上可能会出现力不从心的状况。这时候需要一定的时间周期，升级改造技术架构。一定要与企业领导和业务部门充分沟通，特别要请业务人员在此过程中成为更为积极的参与者。若只考虑技术的一面，忽视业务方面的配合，往往经过一段时间闭门造车，最终的结果还是不尽如人意。时间一长，领导和业务部门就会失去耐心，认为技术只是在找借口，掩盖自己的无能。

技术上追求自身的利益无可厚非，但要知道只有帮助企业创造了价值才真正能够提升自己的影响力。正所谓成就别人才能成就自己。多年前作为鉴定委员去给很多银行的申报系统做鉴定。从技术上看，有些系统的设计实现十分先进，也充满了创意。可惜因没有在业务经营上体现出优异的效果，最终也就很难更好的证明自己，也就不会获得理想的评价。

IT架构最重要的是适合业务需要。过分追求架构的先进性和对未来扩展的支持，将会消耗大量的IT资源。这些投入要在未来业务发展到一定规模后才能收回，而业务本身也不能肯定未来会发展到什么程度。一些探索性的创新，很可能经过一段时间后，业务就不在该方面做更多投入了。

项目首先要尽快满足业务快速投产的要求，实现最紧迫的功能，一定程度上满足业务未来的发展要求，避免追求所谓完美。让业务方面先用起来，在实践中做出检验，进一步完善自己的经营管理想法。有时候业务甚至可能根据实际情况做出颠覆性的变化。技术要积极响应业务的发展要求，主动优化调整相应的系统服务，成为业务的理想伙伴。