从“懂管理的IT人”,到“懂IT的管理者”

余晟 2020-08-10 10:09:33

前段时间和朋友聊天,说起我之前十多年一直都在做后端开发,到德国以后竟然“狂写了几万行JavaScript”。
朋友笑称这是真正的“全栈工程师”了,我竟然很意外,似乎从来没想过这个问题。然后我们又聊起各自工作中的一些困惑,我忽然明白了一点,回敬他说:“我不是全栈工程师,我是‘懂IT的管理者’,而你是‘懂管理的IT人’”。

 

“懂IT的管理者”和“懂管理的IT人”,到底有什么区别?工作了很多年之后我才体会到,其中的区别很大。

 

对“懂管理的IT人”来说,管理只是巩固IT的能力之一,补齐短板所需,他考虑的坐标系仍然是IT,许多从IT出身的领导都是这样。但是对“懂IT的管理者”而言,IT只是众多技能中的一项,无甚稀奇,他考虑和决策的标准是生意,是通盘的管理。

 

这么说可能仍然有点玄,那么下面我分几个方面详细讲述。

 

取舍技术方案

 

身为IT专业人员,我们都清楚技术的重要性,也知道技术的评价标准。什么样的技术方案是好的,大家有相当的共识,或者起码对评价标准有共识。

 

但是我们接受的教育里,很少有“技术如何取舍”的部分。时间有限、人力有限、资源有限,这时候该如何决策,到底在哪些方面让步?是运行效率,还是程序质量,或是架构设计,没准也是安全性……

 

如果我是“懂管理的IT人”,无论放弃哪个方面,都让我感到异常纠结,无比难受,因为它。但如果定位为“懂IT的管理者”,我非常清楚必须放弃某些方面,而且不能犹豫,因为犹豫反而会错失时机,而时机对生意来说往往是无比重要的。

 

所以,“懂IT的管理者”平时可以耐心跟大家讨论技术方案的优劣,一旦遇到资源有效、目标明确的场合,必须毫不犹豫地放弃自己对技术的执念,迅速定下取舍。近年来,我已经不止一次地告诉程序员:对,这样做确实很丑,但别犹豫,赶紧动手吧。

 

与人打交道

 

身为IT专业人员,我们都习惯与机器打交道,因为它是那么的讲规矩、可预见,那么充满确定性。相反,我们大多数人都不喜欢跟人打交道,因为人会有各种想法,难以沟通,而且人会有情绪,更难以预见。既然如此,何不早早摆脱与人打交道,潜心编码,更让人安心。

 

不过另一方面,编码往往是决策的最终环节。一个想法从灵感迸发,到讨论打磨,到设计成型,最后才是编码实现。这就决定了编码工作也会出现供应链中的“牛鞭效应”:负责编码的人往往是最后得到变化信息的,最初的念头可能只是差之毫厘,经历各环节加工之后,到编码环节已经偏差万里。于是也经常引起程序员的抱怨:什么事情都是改来改去,从来不想好再动手……

 

这样就陷入了恶性循环:因为大部分的讨论和决策都不是依赖编程语言和机器通讯,而是依赖自然语言和面对面沟通。所以越不参与讨论,对变化就知觉得越迟,对变化知觉得越迟,就越容易引发误解和矛盾……

 

如果换个思路,把自己定位为“懂IT的管理者”,那么面对面交流、讨论就变得相当重要——几乎所有的管理者课程都强调沟通的重要性。沟通交流的目的,绝不是需要草草敷衍,然后可以让自己醉心编码,而是保证自己的信息灵通,协作顺畅。这一切都搞定之后才轮到处理具体事务,IT只是诸多“具体事务”中的一项而已。

 

工作方式

 

身为IT专业人员,我们大多数人都无可避免地沾染了IT的惯性,比如各项工作都要很整齐有序,工作安排应当有条不紊,讲话应当有理有据,人应当不断学习提升自己等等。基于IT的极大能力,我们往往也相信,这应当是世界通行,凡事都应当参照的标准。

 

对圈内人来说,这种想法很正常,也很容易获得理解。但是对圈外人来说,未必那么容易获得理解,甚至可能完全得不到理解。

 

一个突出的例子是2016年阿里巴巴的“月饼门”事件。当时我也和许多业内同行一样,认为这纯粹是小题大做,专业人员成了政治的牺牲品。但是后来我逐渐发现,事情大概并不像我们想象的那样。

 

对这世界上的其它许多人来说,IT是他们承认“非常重要”,同时又自认“永远也学不会”的技能。所以IT人员对他们来说,就好像掌握着巨大能量但又难以驾驭的工具,如果这种能力不受控,就会产生巨大的不安全、不信任感。

 

所以圈内人大概觉得,写几个无伤大雅的脚本,抢购了几盒月饼,无非是一时兴起,平时绝对能拿捏分寸,不可能做这样的事情。但对圈外人来说,让你去负责安全,你却在做破坏安全的事情,并且摆出一堆道理来为自己辩护,这还了得?

 

我虽然不知道阿里巴巴当时到底是如何决策的,但以我后来和圈外人聊天的经历,大多数人都感到“负责安全的人竟然会利用公司的安全漏洞”完全不可思议,而程序员给出的理由他们完全听不懂——圈内人的理由是定量分析,而圈外人只懂得定性分析。双方沟通,纯粹是鸡同鸭讲,完全不在一个频率上。所以我们大概能判断,无论这种事件发生在什么公司,只要决策者不是技术出身,结果基本不会有什么变化。

 

所以我后来时常劝那些认定某些决策“匪夷所思”的同行:你觉得人家奇怪,人家还觉得你奇怪呢。你摆出一二三四五六七,人家未必有那闲心听下去,或者听了也跟不上。你动不动搬出权威资料来为自己站台,人家没准觉得你这纯粹是小题大做,无事生非……

 

要想明白,绝大多数公司都不是科研机构,而是基于利益的组织。在这种组织里,整齐有序、逻辑顺畅、善于学习等等,作为自己的追求很好,但未必是唯一的工作方式,甚至不是所有人都认可的工作方式。如果公司对统一工作方式没有严格要求(那些口号不算),在沟通协作中就不要执着于自己的工作方式。

 

比较可取的办法是先着眼于目的,摸索出各方的最大公约数。然后,在自己能决定的范围里践行自己的工作方式,在这个范围之外,则以目的优先,绝对不要过多计较工作方式——要知道,在你没有绝对权力,也没有绝对话语权优势的时候,单纯强调工作方式多半会碰得头破血流,尤其是在业务部门面前。

 

另外,也别执着于凡事都要以系统、流程、规范来做,它们未必是人人认可的工作方式,甚至可能让人觉得繁琐和反感。

 

价值眼光

 

“懂管理的IT人”,往往在能力上并没有明显的短板,但他的工作节奏和思考重心仍然是IT,想着如何把IT做好。这本来没有错,可惜的是,不是每家公司都需要那么好的IT,至少不那么迫切需要——别信老板们的鬼话,看看他们的投入就知道了。

 

我以前的领导曾跟我说过一句话,让我印象深刻:你们把系统做好,公司当然喜欢,但更重要的是,你们应当从价值链的角度出发,找到自己的定位。

 

什么意思?IT虽然很强大,可以大大提升效率,但公司是追求利润的组织,利润是由各个部门、各个团队一齐贡献的,换句话说,大家形成了一条价值链。更微妙的是,价值链上谁重要谁不重要,谁更灿烂谁更黯淡,往往并没有客观的标准,而是根据大家的印象来作出判断。

 

所以如果你是“懂IT的管理者”,在懂得IT价值的同时,一定也要能看到整条价值链,看到其它团队的价值所在,不要做僭越自己身份的事情。同时,也需要想办法影响大家的印象,强调自身的价值。哪怕你很诚实,希望用一套客观的数据体系去证明自己的价值,起码也应当先设计出这套数据体系,获得大家的共同认可,并在工作中持续发出信号。

 

所谓“价值链”,其实也没有那么玄乎,一般来说,主要包含两大因素:人事、财务。无论在哪家公司,这两大因素基本都是不变的,剩下的只是你如何从这两个角度展开,看待和证明自己的价值。

 

所以下一次和圈外人沟通的时候,或许不必强调IT本身如何如何,只从人事和财务出发,反而更容易被人接受。比如业界同类型业务需要多少人团队,自己带领了多少人团队就交付了同样的功能;又比如上次投入大量开发资源的项目,最终整体收益并不如预期,如果把这些资源投入其它某项目,大概可以带来多得多的收益……

 

职业生涯

 

我把“职业生涯”列在最后,是因为我发现,“懂IT的管理人”的定位可以让人摆脱技术的焦虑感。

 

什么是技术的焦虑感?就是面对层出不穷的新技术,永远在学习,永远在追赶,永远担心被拉下的忧虑。

 

为什么“懂IT的管理人”可以摆脱这种焦虑?因为相比技术的更新速度,生意和组织的更新速度要慢得多。实际上,如果我们把目光从头部的那几家“技术弄潮儿”移开,就会发现很难有公司一直引领技术潮流,甚至大部分公司(恰恰是它们解决了大部分IT就业)根本不需要那么高精尖的技术,它们更需要的是用合适的技术去解决自己生意中的具体问题。

 

所谓“合适的技术”,并不是把最新技术降几级就可以直接得到。这个“合适”,需要你懂得取舍,需要你懂得与人交流协作,需要你找到共同认可的工作方式,需要你看得到整条价值链,找得到自己的定位。然后就会有越来越多的人愿意承认,你是能让他们放心解决IT问题的人。

 

一旦具备了这种“提供合适技术”的能力就会发现,错过几波技术新浪潮,或许并不那么让人担心,一味追新反倒很可能浪费。另一方面,把这些追新的精力用来提升自己取舍的能力,与人交流协作的能力,打磨工作方式的能力,价值定位的能力,对提升个人价值来说往往反而能起到事半功倍的效果。

 

最后的最后,“懂管理的IT人”相对容易,只要懂IT的人补齐基本的管理知识,没有明显短板就可以,所以竞争也会相对激烈。“懂IT的管理者”相对更难,因为很难想象其它管理者能主动学会IT,所以它只能来源于搞IT的人主动变身,主动越界。

 

不过,千万不要被“越界”和“变身”给吓倒了,以我的经验,最大的困难来自于你的大脑,只要不时时刻刻绷着“我是(跟其他人不同的)IT人”的那根弦,剩下的都好办。

 

作者丨余晟
来源 | 余晟以为(ID:yurii-says)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

 

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告