行业新情势下，工程效能何去何从？

从业务发展上讲，在过去的二十多年里，软件行业，互联网/移动互联网在国内高速发展。

伴随公司、行业高速增长，需求实现是第一优先级要解决的问题，研发管理也不需要太复杂，市场足够大，只要找个爆点，有点儿浪费“根本不是个事儿”，所以软件工程问题并不是很凸显。

即使工程问题凸显了，由于有「业绩增长」，所以管理者也都不太在意它们。

从人力供求关系上讲，在过去二十年，软件市场旺盛的需求也导致大量人力涌入，大多数企业通过人海战术来争取时间，抢夺市场。从生意的角度讲，这绝没有错。然而，原本依靠于传帮带模式的“软件工程师”队伍无法快速扩展，只能通过岗位细分，每个人只需要在短时间内接受培训，并仅需掌握局部知识即可开始工作。面对市场环境，这也没有什么错。

然而，从宏观环境上看，2021年以后，移动互联网技术的应用，以及互联网人口红利都已逐渐见顶，国内市场发展空间受限，很多大厂尝试出海，但国内的成功者很少。

2022年开始，各相关行业的各种整顿、反垄断，也很难再有之前的飞速发展。

几乎所有的管理者今年都在清点人头，都发出同样的感慨：“为什么我们有这么多人了，但出活儿并不多，也不快呢？”

如果说，过去每年关于大厂裁员的消息都是媒体为了吸引眼球，那今年好像的确有一些不一样。

上图为百度搜索提供的结果。

经济大环境的寒冷，叠加自身研发问题复杂度的提升，又遇上数字化浪潮的智能时代，之前问题不严重的软件工程管理，现在面临的局势越发紧张了，而且会持续加剧，行业焦虑也会同时上升。

国内软件行业的工程效能低下是必然的。因为没必要精打细算过日子，

过去的经济形势太好，只要大胆，就能发展，有点儿浪费，不打紧。

写到这里，必须把我 2021年6月份在腾讯做分享时讲的一张图拿来了。

2021年的分享内容在这里《一致性，是研发效能提升的必经之路（长文慎入）》

研发效能

到底想提升的是啥

现在我们大家谈论研发效能的时候，每个人的定义都不一样，每个人认为的效能，每个人期望的效能，都可能不一样。

管理大师德鲁克认为：“效能”只有在企业外部才能被证实。所以，

我的观点是：研发效能是产研结合所产生的业务收益。

而现在行业内所讨论的研发效能，多是指“效率”。也就是《持续交付2.0》双环模型的第二个环——「快速验证环」的运转效率。

如果我们将支撑公司发展要素做个简单的逐层分解的话，可以简化为：

对于公司管理者来说，「工程」是最不易受到关注。

它既没有「业务」那么受CEO关注，也没有「产品」那么受人追捧，还没有「技术」那么时尚。它一点儿都不「性感」，有时甚至看上去好像有点儿「蠢笨」或「多余」。

然而它却像「风/火/水/电」一样的基础设施，又很重要。

往往上面「三个兄弟」都乏力时，它才会被注意到。

此时，会让很多人有「无力回天」的感觉。因为，欠下的「债」已经有点多了。

其中一个「债」就是基础设施工具之「债」。

现在，各个公司对「工程效能」的关注点都有「基础设施与工具平台」这一条。

当真盘点时，你会发现，公司在「工具平台与基础设施」上投入的人力与资源并不少，工程师人数越多的公司，这方面的投入就越多。

而且，过去的每一年，工具基础设施团队都会上报自己的「伟大战绩」。

然而，

当公司说：「要提升研发效能」时，

你可能会发现，

第一个背锅的一定是「工具平台」。「工具平台」背锅，一点都不冤枉。

在「大干快上」的时候，工具平台建设得不那么严谨，在整体环境下并不显眼，用人力顶上也能把活儿也能干了。

但是，正如我当年在腾讯分享时说的那样……

有一些工具当时搭歪了，没有来得及纠正。而依赖这些工具脚手架所搭建出来的东西，

能用，但都不好用。当时靠人力肩背手顶搞定的事情，会衍生更多不必要的偶然复杂性。

（比如：你的工具不能及时响应我的需求，我在你工具的上面再魔改一套出来！）

当回头看它们时，它们已经成为一个「庞然怪物」。同一个问题，解决方案五花八门，而这些解决方案又衍生出更多的偶然复杂性。

原因也很简单。当时的情况比较紧急，会有很多方案是临时性的，依赖于很多假设。而这些假设在经过一段时间后，变得不那么清楚明白了。

债务太多了。当想要改造的时候，已经改不动了。

同一个公司的很多工具平台之间是竞争关系。它们之间有很多功能是重合的，（常见的原因有：魔改和包装），名日「对业务进行贴身服务」。

过去不恰当的衡量指标会加剧这个问题；其表现出来的形式如：

（1）工具看上去炫酷无比，但使用量很少；

（2）工具在公司内部的PR不少，只为了要日活用户数（互联网公司的通病）。

为了互相不产生干扰（容易甩锅），甚至各工具都有自己独立的用户体系，而且互不相通。做一件事，需要在两个平台上分别填写很多相同的重复信息。

首先：平台工程 ≠工程平台

在上一篇文章 《Platform Engineering 平台工程 15 问》中，已经强调过，平台工程建设中，应该包含IDP（内部开发者平台），但是，它不仅仅是工具链或内部开发人员平台。

平台工程继承了 DevOps 运动的目标，通过打通Dev与Ops之间的隔阂，加快软件的价值交付，同时还需要：

• 通过提高工程师的体验，来减少工作流程中各角色之间的工作摩擦阻力。这些摩擦来自于DevOps早期对其简单粗暴的解释。即：就是让开发工程师了解并掌握所有运维技能，并使用自己不熟悉的工具完成大量的运维琐事。

• 通过提升 DevOps 工程实践与工作流程的一致性，保持只需较少的人力，即可进行IDP的建设与维护。

企业内部的DevOps基础设施产品是”有限市场的ToB产品”。这一点就已经决定了它的建设方法不能使用 toC产品的做法。它的投资方是IT主管部门，主要的用户是软件产线上的众多个体。

Netflix 和阿迪达斯等首批采用者从其平台工程计划中获得了巨大收益。这是因为这两家公司都清楚地知道自己想要实现什么目标，并逆向制定了解决方案：Netflix 的目标是统一工程体验，而阿迪达斯则希望缩短开发人员启动项目并将其集成到基础设施中的时间。

一位团队分布于多个国家的组织说：对他们来说，所有地区的基础设施部署、应用程序开发和安全措施保持一致是重中之重。他们的解决方案是一个内部云原生平台，可供分布在各地的团队使用。另一位客户希望将开发人员从管理基础设施等端到端责任中解脱出来，因此成立了一个基础平台团队，以便轻松 "插入 "其他系统或应用程序。

从上面的例子中，可以看到，无论是减少开发人员的责任，还是创建一致的软件开发环境，公司制定明确目标至关重要。这一点是与原有的 DevOps 运动所不同的重要的主张。

原有的DevOps 运动并没有提出这一明确观点。