工程师文化如何在组织中落地

前言

在正式分享工程师文化的话题之前，我想先聊一聊研发效能。相信很多概念在场的各位都不陌生，比如：敏捷开发、精益生产、CI/CD、DevOps、大库、主干开发等等，大家在各自公司或者团队应该也引入落地了很多的实践、经验、工具，但我自己在研效领域10年，得到的最有价值的一个观察就是：

研发效能的提升没有银弹。

——《人月神话》

工业流水线理念在软件开发中的应用

近百年来生产效率得到飞跃提升的一件事情，就是福特流水线的提出和使用，它把工序标准化后通过流水线的方式极大地提高了工厂的生产效率。这个理念也被广泛用于各行各业。

流水线的理念也衍生到了软件行业，例如精益思想、CICD、DevOps等等，可是我们发现它的效果并没有想象的好，因为软件开发和工厂里机械式的工作有本质的区别：软件交付的需求、方案、架构、代码、架构等产出没有标准答案。可能1000个人写出的需求和方案有1000种。工业制造的流水线是通过标准化过程来提高协作效率，现在我们希望通过一个标准化的节奏和方式来提高非标准化的软件开发的效率是有难度的。

我们常说知识工作者，还有很多程序员自称“手工艺人”，也反映了软件开发的创造性和不确定性。所以研发效能问题，人是根本，研发人员的行为发生改变，研效才能真正得到大幅提升，研发效能问题的解决，一定离不开对于研发人员的行为驱动力的理解，所以我们今天来聊工程师文化。

文化的力量

在之前的一次全员调研中，我发现了两个有趣的团队：

有一个团队的研发满意度特别低，这个team的研发人员士气很差，然后我到这个团队，大家整体的感受都很一致，大概的反馈就是，业务需求压力很大、历史技术债很多、填不完的坑，还被业务追着跑，有时候为了赶时间，会搞很多临时方案，有时候明明知道有问题，还是先上线再说，这必然导致上线后问题很多，然后就是查问题，返工等等。

就是这样的恶性循环……我问他们:“你们觉得有什么办法可以改变这种状态？”他们回答说不可能。然后我又深入了解了一下这个团队里的每一个人，发现其中有一个同学是社招进来的，他之前是在外企工作，我在内网看到了他写的一篇分享他的前公司工程实践的文章，写得非常好。一个原本工程师素养非常高的人，放在类似这样的团队，久而久之也被同化了。

另一个是满意度非常高的团队，业务对他们很信任、团队单测覆盖率能到90%左右、个别单兵的单测覆盖率甚至可以达到100%。我问他们是不是没有新人的加入，团队一直稳定不变，形成了很好的开发习惯和协作默契。

然而事实是这个团队的人员流动性也比较大，还有人是近一两个月才进来的，他们却能连续3年保持始终是一个非常敏捷的团队。不同的人，放在类似这样的团队，都表现出了很高的工程属素养。

然后我把视线放大到一个BU，甚至整个公司，我跟很多人去聊，有从Google、亚马逊、微软这些外企回来的，有在公司十几年的老兵，有新入职的人，跟待过不同气质的团队的人聊天，同样的人，把他放在不同文化气质的组织中，他会随着组织而变化，这就是文化的力量。

什么是工程师文化

关于什么是工程师文化， 可能没有标准答案，但是我想分享3个我喜欢的说法：

一是借用我很喜欢的一位架构师回答过类似的问题，我很喜欢他的回答：一个好的架构师反复做四件事：选择好的挑战，把简单的东西想复杂，把复杂的东西做简单，把复杂的东西讲简单。反之，则是选一个不值得做的问题，把复杂的东西想简单，把简单的东西做复杂，把简单的东西讲复杂。

二是我的TL也说过一个我很喜欢的答案：把复杂留给自己，简单留给别人，就是工程师文化；把简单留给自己，复杂留给别人，就是内卷文化。

三是对好代码的三层进阶：

It works

It is easy to understand

It is safe to change

初阶的目标是“It works”，让系统运转起来就可以了；进阶希望“It is easy to understand”，需要做到让中间产物，比如需求文档、架构设计文档、代码可读性、注释等，是可以理解的；高阶需要考虑“It is safe to change”，很多人在问一个问题“如果我的系统是快速变化的，要不要写单测？”那你可能要反问自己“如果不写单测，我敢不敢变？”

但当我们真的去落地工程师文化，当从研发个人视角切换到组织视角的时候，我们得回答一个问题，程序员的精进是如何实现的？

我有个同事写了一篇很火的文章，叫软件道德观，我前面提到的那位架构师也分享过一个话题，叫架构师的良知。大家想想看，道德和良知，这相当于说这里面有很宽泛的可操作空间的，站在组织视角去思考的时候，我们当然不能全部寄希望于程序员的自省、自我精进，更何况这里面还有我前面讲的文化的可怕力量。

从研发视角去谈工程师文化，和从组织视角去谈工程师文化，是不一样的事情，如果我们直接把社区或者行业KOL的语言转换为组织的语言去对研发同学讲的话 ，研发会觉得你在PUA我。所以重新解构什么是工程师文化，我想应该是三个方面：

1.好的工程。在库里的代码是健康的，架构设计是合理的。

2.好的工程师。工程师有能力把系统代码写得“easy to understand、safe to change”。

3.好的组织。组织不是生硬地给员工提要求，说你的单测覆盖率要达到多少，而是反过来思考我能为研发解决哪些问题，帮助研发成长，提升研发体验，例如工程师能力成长、顺畅流程、称手的工具、还有大的文化环境等等。

正确认知是正确行动的前提

一个工程师案例

有一个团队在启动工程师文化大概3个月，然后从数据上看有了很大的进步：单测覆盖率从30%提升到50%，还对一些遗留的老应用做了下线……本来我以为这个团队转型非常成功。

结果有一天，一个刚转入团队两三个月的开发说“你不知道最近这一个月我过得有多痛苦，我们团队有十几个系统，所有的启动优化都是我一个人做的，大家加班是在写代码，我加班是在给全组的人写单测。”

这是一个反例，这个团队把工程师文化转型理解成一个KPI指标，比如说我们要把单测覆盖率从30%提升到80%，就派一个同学专门来补单测，更有甚者会借助工具来实现完成这个“数据指标”。这样的做法对团队的伤害是非常大的。

一次管理者调查

上面的问题在于团队管理者对工程师文化转型出现认知偏差，于是我们做了一次管理者调查，问题很简单“你对组织对工程师文化了解吗？你对工程师文化的态度是什么样的？你愿意学习吗？”通过调查我们得到了一组反差很大的数据，50%以上的人认为：我知道工程师文化，但它的内核是什么我还不了解，虽然我不了解，但我觉得我不需要学习。

管理者对于工程师文化的认知决定了转型的成败，工程师文化是团队自己的事情，责任方是你，行动方是你，收益方也是。只有在达成这个共识的情况下，才有可能产生正向的化学反应。而反模式是：你要求我工程师成长，要求我写单测，那我想办法叫他们刷上去，然后得到一堆虚荣数据和一群痛恨你的研发。

“运动式”解决“冷启动”问题

管理者意识层面的问题解决，一线同学也行动起来之后，我们要开始换位思考，他们在行动过程中会碰到的实际困难。从一个比较差的工程文化发展到一个很好的工程文化？这里还有一个很大的问题：冷启动。

我们要理解几乎所有的程序员都是工作在遗留系统中，很少有人这么幸运，到一个地方可以从0-100写一个系统。在学校写的代码可能是一次性的，一个人把题目的答案跑出来就可以了，但我们在公司写的软件可能要跑10年，写代码之前先要研究老系统，先找到自己要改的那一行代码在哪儿，了解系统用了哪些技术栈和云资源、如果是分布式系统我的上下游是什么等等。

复杂度是完全不一样的。我这里写了15和85两个数字，是我们统计出来的两个魔法数字 ，有两层含义：一个研发只有15%甚至更少的时间在写代码和自测，剩下85%的时间可能都在做别的事情，比如需求沟通、联调、发布等等；一次代码变更，代码开发+自测的时间占比15%，集测、联调、发布等这些时间加起来占85%。

大家想想看，任何一个15%提升到30%就是飞跃，但这不是靠把一个程序员的能力提升一倍就可以实现的，控制和降低系统的复杂度才是根本。

所以我们要理解，为什么在做文化转型的时候，有冷启动的问题，我们有一个经验值，3-6个月的时间能让团队完成冷启动，这个过程需要“运动式”的完成，当团队整体达到一个比较好的水位之后，后续的坚持就会变得相对容易。《Google软件工程》这本书里面也有类似的的案例，推荐大家阅读。

我们在谈更好的工程实践的时候，往往谈的比较多的是这个实践的价值，但团队在选择研发模式或工程实践时，需要对当前成熟度水平、对各类前置依赖有充足的判断和准备，否则会形似而神不似，反而带来研发体验和效率的下降。

任何新实践的引入都是一项变革，会打破团队已有的工作惯性，只有基础设施能较好地支撑实践落地，才能尽可能降低变革对体验和效率的冲击。对研发模式演进路径的研究和基础设施支撑能力的建设应该提前于实践的推进。

正确理解“度量”

我想请问大家，你的公司在用的度量指标包括哪些？

代码行数。前些天看到一个新闻：说有一个公司根据程序员的代码产出行数付工资，然后有一个人一个月产出了20多万行代码。然后有一个评论说：如果真这么发工资，程序员分分钟把公司写到破产。我还听过一个更振聋发聩的表达，说“代码行数其实是衡量一个研发的愚蠢度的指标。”同样一个问题，两个工程师，一个用100行代码就解决了，另一个要用1000行代码才能解决，你会选哪个？肯定是第一个，说明他能更好地理解和解决问题。

需求周期。我们曾经用过这个指标，提了一个目标，就是需求周期降到20天以下，3个月后很神奇的事情发生了，80%以上的需求交付周期都降到了20天以下。需求周期的可操作空间很大，因为它跟太多东西相关了，比如需求颗粒度、系统复杂度等，把一个大项目拆小，拆成10个小项目，这个指标可能就达成了。类似的例子还有很多，大家也可以自己试着从不同的角度加以分析。

我们在做度量体系设计的时候，还要想清楚是给谁用的，是在为管理服务，还是在为研发服务。给一线研发用的指标要想清楚具体在哪个场景下，能让研发或者帮助研发解决哪一个具体的问题，或者可以帮助研发发现日常工作中洞察不到的问题。

正确定义后还要正确使用，比如我见过很多团队把指标当目标，在团队间通晒进行横向比较，或者把对工程的度量直接用于对工程师的考核。这样做的话我们以为在帮助研发解决问题，但实际上变成了“管理研发”，这样做极易带来动作的变形。

以CR有效性为例，设计的初衷是希望用CR有效性这个复合指标来观察整体CR行为往我们倡导的“CR左移、小批量提交、及时响应、完整阅读、有效评论、完整解决”几个方向发展，但如果这个指标被分而治之，就会发生变形，比如为了追求提交规模变小，特意将一个feature分多次提交，但缺乏完整性之后其实会降低Code Review的效果。

其他场景也会有类似的问题，当一个场景下的指标集被分而治之的时候，就出现了大家倾向于先做简单的事情，虽然能看到指标数值的上涨，但本质上对于工程质量提升的目标却没有达到。

度量是一把双刃剑，大家用的时候一定要谨慎。

高质量带来高效率

我想大部分负责工程师文化转型或者研效相关的工作的同学都面临过灵魂拷问：“面临交付的压力的时候，可不可以降低质量要求甚至牺牲质量”，我想告诉大家的是，如果你一开始就觉得质量是可以牺牲的，那么也鲜少见到后续真的去补齐质量，很多的技术债就是这么产生的，最后往往付出更大的代价。

如果我们希望建立持续健康的长期发展，高质量带来高效率才是正向良性循环。