后疫情时代下，互联网底层逻辑变革驱动技术管理重构！

导语 | 由于疫情不断反复，尤其以年初奥密克戎为代表的加速肆虐，导致了许多企业甚至行业都遭受了重创，管理亟待变革转型。疫情环境下的变量对互联网行业及业务的冲击，我们作为技术管理者，应该怎样适应和应对变化。有赞技术副总裁、腾讯云 TVP 沈淦老师将为大家分享后疫情时代下管理者在底层逻辑调整下该如何变革。

作者简介

沈淦，有赞技术副总裁、腾讯云 TVP。自我定位是一个简单的技术人——码农，深耕技术一线二十余载，带领团队壮大规模。积极参与各大技术社区活动，除 TVP 外，还在 TGO鯤鹏会、混沌学园等组织担任职务，深谙技术圈与非技术圈发展之道，善于思考技术的价值。

疫情对互联网的冲击：

底层逻辑的变革

这两年互联网行业发生了很大的变化。行业的发展速度整体放缓，越来越多的团队都在思考怎么长期健康的活下去。尤其是去年到今年年初，大环境发生了剧烈的变化，不少公司在环境的影响下开始收紧钱袋子。在疫情对各行各业都产生比较大的冲击的同时，国家去年开始对平台电商、平台型的互联网企业的管理力度也加大了。在这个时代背景下，我们今天一起聊一聊技术管理工作面临着哪些新的挑战。

国家为什么要做这样的事情？实际上这是中国经济底层范式的重置。中国有三四十年的时间其实都是围绕着绝对化的经济优先，来推进整个社会的进步。我们用绝对经济优先这个范式推进了四十年，而且做得相当成功。只是目前已经不太容易再用这种方式推进，最近两年明显感受到，政策上基本上不再一味追求 GDP，而是调整成了可持续发展、社会公平、数据安全、自主可控等这些大逻辑，那些在绝对经济优先范式时代成长起来的“旧经济”则受到不同程度的压制，而一些新的、更符合可持续性、公平、数据安全、自主可控这些方向的业务，则受到各种政策的支持而得到迅速发展。

这个模式下，会带来哪些情理之中又意料之外的变量呢？有一个很有意思的数字，如果按这种模式，到 2030 年，会有两个关键的数据，一个是我们的城镇化会从现在的 40% 多上涨到 72% 左右；另一个是中国一二线城市的城市化人均的可支配收入从现在的4万提升到8万块元人民币左右。由于我们城镇化规模还在持续扩大，城镇里的可支配收入再加倍的话，到 2030 年大概是8万块钱左右。8万块钱是什么含义呢？这意味着相当于有 10 亿人的生活水平都将超过今天的上海。从这个结果来看，是一个巨大的机会，我们很多思考问题的方式都可能跟着发生变化。

技术领导力的界定

及领导力模型初探

了解了大环境的变化，再来看看对技术领导力的期待，则会发现一些新的视角。我们先看看领导力这个词通常是指什么呢？从字面上来看，领导力就是你把你管辖下面的人、事，包括钱用一个最小规模的东西产生最大的效力。

我们可以看到有许多不错的技术领导力的模型，比如从影响力、技术功底、组织体系搭建能力、人员管理能力和文化等维度的六边形模型，再比如温伯格在《成为技术领导者》这边书里提到的 MOI（激励、组织、创新）模型。我们在日常的工作里或多或少都使用这些模型，并且对工作带来比较大的帮助。

大环境变了，技术领导工作该怎么变？回答这个问题，只靠这样比较普世的领导力模型可能还不够，需要在模型的基础上再深挖。现阶段最关键的技术管理目标是什么呢？环境变了，业务也变了，不再像之前那样一路高歌猛进，需求永做不完。今年摆在很多团队面前的任务是怎么过好冬，对我们技术领导者而言，就是我们怎么样带领团队跨越当下非连续性的环境。

后疫情时代下，技术管理重构迫在眉睫

内卷推动互联网行业技术管理调整

很长时间以来，国内的互联网处于一个内卷时代。大家都在把一个事情做到极致，越做越复杂。坊间流传过这么一个段子，在某大厂，一个产品同学想改一个 button 的样式，因为点击这个 button 触发的业务流程涉及到两个不同的大团队，两边的产品就针对这个 button 该怎么改开了很多次会，最后还是决定不下来怎么改，最后只好让两个团队的一号位来拍板。相信很多同学听到类似的故事都会会心一笑，改一个 button，毋庸置疑交互体验非常重要，不过客观上也的确不需要用这么复杂和低效的方式来处理。我们不少日常工作或多或少会带上这样的特征。产品不断迭代，同时又发现友商的学习能力都超强，刚做出来的一个好产品好功能，没多久市场上就到处都是；另一种方式是横向扩张，号称以用户为中心，围绕着一群人，什么需求我都满足你，什么业务都做，美其名曰生态扩张。这样带来什么？就是谁都是要平台化，要生态化，这些是内卷的一些现象。

在这样一个背景下，其实技术管理的最大价值就是让技术团队怎么样做到超高的交付效率，甚至是无限高的一个交付效率。因为越卷的厉害，对需求吞吐率的要求就越高，需求池里的需求积压的越多，越会制约着业务的发展。

实际上，大环境的变化带来的影响是蛮严峻的。首先政策层面，整个国家宏观经济层面的底层逻辑发生了变化，在这个变化的背景下，公司的很多业务都在调整，很多团队的业务都在调整，我们的技术管理模式要不要调整？从之前我们追求绝对效率这种方式，到底往哪个方向去调整？

专业化、流程化、赋能

助力技术管理效率提升

研发效能对不少团队规模比较大的技术同学来说是一个拦路虎，大家怀念团队小而美时候的幸福时光。是的，大部分技术团队是跟着业务伴生成长的。基本上刚开始一个早期业务的团队，都比较简单、扁平化。随着业务复杂了，研发团队也复杂了，复杂带来两个问题，一个是不容易提升效率，越大的团队效率提升越不容易；另外一个，复杂带来了协作成本的上升，团队越复杂，技术团队内部的协作，技术团队和外部的协作都变得非常有挑战性。

随着技术团队规模越来越大，我们做了哪些事来提升效率呢？专业上，我们期待通过各种学习和培训提升专业技能；过程上，我们通过推行 XP、Scrum 等敏捷流程期待提升团队吞吐率；工程上，我们通过推行 DevOps 来提升工程自动化能力；架构上，我们通过组件化、平台化、中台化来推进沉淀和复用；文化上，我们强调激活个体和赋能，充分挖掘同学潜能。这些都是我们这么多年来技术管理持续在做的事情，归根结底，无论是专业、流程、工程、架构、还是文化，我们期待达到的效果主要还是提升研发效能，只不过是不同层面上的研发效能。

托马斯.库恩《科学革命的结构》一书中，有一个很打动人的观点，大部分的科学研究并非是一个创造型工作，而是在围绕原有科学理论范畴内进行不断的自我解答。这样就把原有的科学理论越来越自洽，越来越完备，越来越接近绝对真理。只有极少数的科学研究打破了旧理论。对应到我们自己的技术管理，包括我们的研发工作都类似，大部分都是在围绕效率这个核心命题在工作。

底层逻辑变了，怎么回答这个问题呢？是继续禁锢在效率这个牢笼里，还是打破它，用更合适的方式？

技术管理：协作模式向服务模式转变

交付效率优先，一切围绕着效率的模式，背后有一个假设：快是业务赢的核心（这也是交付效率很容易被认为是影响业务的卡点的原因）。快为什么是业务赢的核心呢？我们之前弹药比较多，可以什么都做一下，然后快速推向市场。在剩者为王的场合，成本变得非常重要，光快其实是不够的，甚至快不再是最合理的选择。这时候，大家比的是把事情做准的能力，无效的事情能少做就少做，能不做就不做。用比较书面话的表达，把业务做准的能力，就是为目标客户提供超出客户预期的高价值产品和服务的能力。之前我们天下武功为快不破，现在则是无招胜有招，出招了就又准又快。在这个背景下，我们在围绕着提升研发效能的基础上，还需要建立赋能业务把产品和服务做准的能力。迭代团队的协作模式是提升研发效能一个非常重要的手段，而建立把产品服务作准的赋能能力，则需要我们打造一套围绕服务模型的机制。

说起协作，在 XP、Scrum、DevOps 等敏捷实践里有大量相关的探索，这里不做赘述。协作之所以越来越重要，和微服务架构大行其道有很强的关联。微服务架构下，每个团队都有自己的服务，同时也都依赖大量的其他团队的服务。这种相互依赖的关系，就导致我们必须和其他团队进行协作。微服务架构给我们的业务迭代带来了很强的灵活性，同时很多时候也是协作低效的根源。去年我们团队花了比较大的精力，从敏捷实践、架构实现、DevOps、研发效能度量体系多个维度建立了一套多团队高效协作的研发体系，使得整体的工程效率有将近 100% 的提升。通过这次实践，也坚定了我们对效能改进的理解，关注团队负荷，使团队之间从强沟通的协作模式变成弱沟通的协作模式，对整体效能提升的确帮助巨大。

同时，我们也在思考怎么回答把业务作准这个命题。我们目前的答案是，把业务一次作准是个可遇不可求的期待，把业务尽量作准，实际上需要技术团队给业务团队提供更灵活的快速试错能力。而打造快速试错能力的基础是建立一套以服务模式为核心的研发机制。所谓服务，简单的理解就是 API。这里说的 API，是指广义的 API，包括既包括 RPC、REST、本地接口，也包括 SPI、消息、业务事件等。研发团队的服务模型，是指把一个团队的职责，按照服务的方式建立对外的服务声明和服务契约，团队之间的交互，就像微服务之间的交互一样，通过服务发现来了解服务的功能，通过服务调用来实现业务逻辑的交互。可以想象，一个实现了高度服务契约的团队，可以更专注在自己的业务领域里，其他团队在使用这个团队提供的能力时，只有那些非常复杂的场景才需要和提供服务的团队进行沟通。

我们在探索服务模型的过程中，总结了一些关键步骤：业务可视化、API标准化和能力领域化。

业务可视化

业务可视化是指什么？大家可能都有类似的经历，在跨团队协作时有一个很突出的问题就是知识传播。如果一个团队的某个功能需要对商品模块进行调整，要么向商品团队提需求，要么这个团队自己去改商品模块。大部分场合，团队自己不太会去改其他团队的代码，一方面是因为每个系统都有自己的 Owner，大量跨团队的改动的确会对代码的质量和稳定性带来冲击；另一方面，其他团队为了改动一个貌似简单的商品逻辑，可能花在学习商品模块的业务知识和系统调用关系的时间（知识传播、知识学习的过程）成本也非常高。业务可视化的目标就是解决这个问题，我们使用线上流量，实时呈现业务产品视角的业务逻辑及服务之间调用关系。我们把这个能力叫做业务可视化。目前看，业务可视化带来的效果还是挺令人惊喜的。大家有兴趣可以自己在团队里尝试一下。

API 标准化

API 标准化是指用一组标准的 API 模版来定义团队的服务。团队要想实现服务契约，第一步就是需要通过 API 的形式把这些服务定义出来。估计大部分团队都走在微服务的路上，微服务的优点非常明显，它带来的问题也越来越突出了，服务碎片化是其中之一。我看到过不少真实的案例，某个功能相近的查询接口，居然同时在线上有将近十个版本，几乎没有人能准确的说出这十个版本在哪些场景适用在哪些场景不适用。API 标准化尝试在解决服务碎片化问题上提供一个可行的方案。

能力领域化

能力领域化，就是怎么样做 DDD，怎么样在产品体系和研发团队的尺度（而不是应用或者系统的尺度）上做领域。团队能力被领域化，更多是指怎么样让其他的团队更好的使用团队的能力，而不是指团队怎么做能力建设。这些工作，我们探索下来，发现都非常复杂。核心原因是，团队的能力不是一张白纸，而是积累大量历史包袱和技术债的系统和应用，要让这些系统和应用，通过迭代演进的方式提供清晰可靠的领域能力，是一个复杂的系统工程。这也是技术管理本身的魅力，技术管理肯定不光是把需求实现了就好了，怎么在完成需求交付的同时，做好团队能力的领域化，特别做好团队领域能力的演进式迭代，都是非常值得我们去突破的。

技术的本质到底是什么？布莱恩阿瑟在《技术的本质》一书中指出技术是推进社会发展的原动力，技术通过捕捉现象并对之加以应用来推动发展。换言之，技术是对捕捉到的现象进行针对性的编程。这个观点，跟前面我们讨论的内容非常接近。社会底层范式发生变化、宏观经济结构变化以后，我们业务上会随之变化，技术如何捕获这些现象，进行针对性的处理？现象倒逼我们在技术管理上对底层逻辑进行调整，不再只围绕着降本增效效率这一件事。实际上，在当下的大环境下，降本增效只是防守，纯粹防守是没有出路的。

技术推动业务发展可以划分成四个阶段。第一阶段强调专业性，技术团队搭建了数字化系统，这个活儿只有技术团队能干，其他团队都觉得数字化系统挺神秘的，基本上上 2000 年左右是这个阶段，现在基本上很少有团队还处在这个阶段了；第二个阶段业务团队和技术团队协同配合达成业务目标，通俗讲就是接活，接需求。这个阶段的核心点就是我们今天花了大量篇幅讨论的效率；第三个阶段是技术引领和差异化，就是给业务提供强大的试错能力；到了第四阶段，技术本身成为了业务。典型代表就是腾讯云，技术本身就是业务的核心、商业的核心。

综上，我们从技术领导力出发，聊到技术管理者在当下如何回答好赋能业务的命题，再进一步聊了技术的本质。其中讨论到的不少内容，我也在探索的过程中，期待能有机会和更多同学一起讨论和实践