从“懂管理的IT人”，到“懂IT的管理者”
The following article is from 余晟以为 Author 余晟
前段时间和朋友聊天，说起我之前十多年一直都在做后端开发，到德国以后竟然“狂写了几万行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人”的那根弦，剩下的都好办。
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。