对A厂工程效能的一点看法

这段日子经历职业生涯经历了不小的变化，在纠结了许久之后选择了从(递增的)工号已逾 35 万的大厂（简称 A 厂）跳到了百"缺"待兴的贵司（简称 P 厂）。作出这个选择的很大一个原因是自己对“变化”的渴望 ── 渴望巨大的变化能给自己更多的感悟和成长。

“遗憾”但是又“幸运”的是在 P 厂我负责的领域和在 A 厂一样，都是研发效能/工程效率领域，尽管入职还不到两周，距离离职也已快过去一个月，但如我所愿在对比中我也有一些对 A 厂研发效能的想法，趁着感觉还没完全消散，忙里偷闲地进行一些暴论。

免责声明: 以下内容带有强烈的主观推断，有极大可能结论是错误的，都是出于个人的经验和感受进行的总结。我很欢迎大家直接地指出我的错误(如果有人看的话)，也期望能有人和我进行深入地探讨，但对于没有价值的贬低我会直接删除。

也不知道是从谁口中开始传的，大家都说研发效能的三要素是“人”、“流程”、“工具”，仔细一琢磨，想说的几个点大概也可以归到这三个方面上，因此我也就不打算免俗，从工具开始说起吧。

工具大概是明面上最容易感受到差距的地方。到了 P 厂简单了解后就不得不感慨，A 厂的效能工具确实很齐全。从需求/缺陷管理、设计、文档、IDE（及插件）、到代码托管、持续交付、发布管控、数据洞察、工单支持…这个领域内所有我能想到不能想到的边边角角都已经被插上了 A 厂自研的大旗。

得益于完备且相对统一的工具体系，A 厂在质量效率上确实有着很高的起点。速度上来说，（在不出错、不需要审批、且已经被工具调教熟练的前提下）A 厂的发版能享受到完整的一条龙服务。质量上来说，IDE 插件保证编码期间的错误提示，持续交付中的各种规则和组件换着花样伺候开发，线上变更三板斧配合各种应急措施（当然还有故障复盘和追则），保证了蚂蚁极低的线上故障率和极短的修复时间。上万名研发、数千个仓库、每周小几千个 MR、每分钟上百条流水线…以统一的工具体系支撑起这个量级的多种服务需求，不能算是小的成就。

不仅如此，“统一”一定程度上也意味着“标准”。A 厂定义了自己工具体系下的“标准”，这个“标准”即代表使用标准、流程标准，也代表评价标准、管理标准，只要适应了这个标准的语境，员工们就能很快享受到这个“标准”所带来的红利：除了上文所说的显著的质量效率提升，还有沟通术语的一致、团队切换在工作方式适应上的低成本、宏观度量数据的采集和清洗低成本…

这一套体系能够形成如今这么一个宏大的布局，我想最主要大概有这么几个原因：

• 首先最直白的原因便是人多。效能部的人多，A 厂的研发效能部在巅峰时期有 180 多个人（还是 130 多个，记不清了），抛开巅峰时期不谈也从两年前的 50 余人发展到现在的 80 余人，涵盖了开发、产品、解决方案、技术支持、运营等角色，这还不谈体量更大的中间件团队和技术风险团队（作为对比 P 厂的工程效率部在本文撰写期间 2022 年 5 月中旬为 7 个人）。人多是因也是果，人多是工具体系得以全面覆盖的基础，工具体系全面带来的业务也需求并带来了更多的人。

• 其次就是公司大，公司大了业务也就广了。某个 P8 指点过我，公司也是市场黑暗森林里的一个孤立群体，保持静止最终只会带来死亡。A 厂发展到这个阶段，锁涵盖的业务范围不是我这种小 P 可以简单数清的，而 A 厂的组织方式又以中台为主，这么复杂的业务体系收束在一个部门下，确实也不是一些简单的工具可以支持的。

• 再有就是 A 厂对校招生的偏爱，这是我校招进公司时 HR 就提过的。校招生的一个特点就是好调教，一张白纸，A 厂说啥是规范流程啥就是规范流程，再加上 A 厂的校招生水平不低（我算是其中极差的了），这么些各大院校里的尖子生能快速地体会和掌握 A 厂的标准，快速地成为 A 厂的生产力。校招生的高比例和不知是否存在的青睐，也导致他们占据了 A 厂中高层的大多数。“人无法知道自己没看过的东西”，统一语境下成长起来的校招生们，大概对于标准不会有太多的敌意。

• （KPI 导向，但实际上我入职后的 KPI 对我并没有太多约束，因此我也没有太多想法）

但是，质量和效率就是研发效能的全部吗？

很惭愧，在 A 厂两年多的时间里我基本没有吃过我们自己的狗食，我没办法从用户的角度来评判 A 厂的研发效能并给出答案。因此我也只能从一个研发效能部研发人员的视角谈谈我的看法。

如上面所说，其实我代表的就是（我认为）比较典型的，A 厂效能部研发值得诟病的一方面: 我们即不是自己的用户，也离业务太过遥远。

我起先负责的是代码分析能力的建设，代码分析作为持续交付 CI 建设的一环，以“任务”的粒度进行分析，而在当时的我眼里，对这些“任务”进行优化和扩展就是我的工作，我最高频地接触用户的场景，就是在自研的对内的工单咨询系统上进行答疑。在这个阶段，也偶尔有用户跟我提出了需求，而我和 mentor 讨论的时候，往往要关注的是这些需求的“性价比”── 大部分需求是较定制化的，便找理由搪塞了过去，最终我所实现的大部分较“大”的需求，实际上都是我们自己 YY 出来的，看起来牛逼轰轰的需求。

我想这其中就有“统一”的原因，研发效能听起来像是服务于研发的团队或工程，但当我们开始抽象业务的复杂度，实现这个领域的统一时，我们有了很充分的拒绝服务的理由。当我们有了充足的人手，我们的分工也可以足够细，细到我这种螺丝钉始终对业务懵懵懂懂。

我并不知道 A 厂有多少校招生和当时的我一样对自己创造的价值感到困惑，我也不清楚当公司壮大、业务复杂后，这种大一统的中台部门是否是一个必然的选择，如果是的话这个选择带来的业务疏远感应该如何处理（异或是根本不必处理？）。就在上周我和我在 P 社的老板简单地聊到了这个话题，他提到了在他的老东家（另一个大厂）同样要面对需求的性价比问题，他会要求团队里的同学紧贴业务创造价值。这可能是一个很直接且有效的方式吧，我也希望在 P 社成长的过程中自己能有更清晰的答案。

我颇感不适的第二点，就是这全套自研的基础设施。

如上面所说，不能否认自研工具的复杂度和它们对 A 厂复杂业务的支撑价值，但自研又封闭地开发环境在我看来损失了不少成长的可能。

一是足够活跃的社区反馈和讨论（尽管 A 厂内部也建立起了技术论坛，但在用户与产品负责人论坛上的讨论方式让我觉得更接近于“吐槽与公关”的关系），我们服务的主体是技术人员，技术人员本身对生产力工具应该是有天然的热情和兴趣的，缺少健康的沟通渠道以及足够的社区用户让自研仿佛闭门造车。

二是公司内的语境限制了与业界先进实践的接轨，“公司内的语境”指的是当基础设施建设得足够齐全，就相当于在公司内营造了自己的上下文，后续的很多上层建筑的建设工作都是基于这个上下文提出的。这些上层建筑累积得越厚，可能离业界的先进经验就越远，吸取地成本也就越高。

三是当自研工具体系覆盖了大部分领域，但又没有足够的灵活性时，A 厂的研发人员在工具选择上面临着尴尬的局面：自研的产品并不能完美地匹配团队的特性，但“又不是不能用”，这种情况下大部分团队会选择将就使用自研的产品（上面的“社区反馈产品”也是这个例子，A 厂的代码托管平台的 issue 功能鲜有人用。）。

这又带来了另一个问题，即流程上的不规范。是的，上文我们说到了 A 厂的流程是“统一的、标准的”，但统一和标准不同于规范。

**当工具不能很好地满足个人、团队的特性，而流程标准又要求使用这个工具时，工具的使用在一定程度上就变成了负担，负担的累加导致了不规范。**在我参与的第二个项目（某内部洞察项目）中，我和另一个同事曾就内部工具数据对多个（内部）团队进行数据分析工作，所得到的分析结论大部分都因“团队流程不规范”导致的脏数据不可用。

如果你问我，质量和效率就是研发效能的全部吗？我无法回答，我也愿意相信 A 厂仍然能够又好又快地交付产品，但作为曾经 A 厂的效能研发人员，我无法认可自己在那种工作模式下产生的价值。