最大化开发人员的效率

https://martinfowler.com/articles/developer-effectiveness.html

科技在不断地变得更加智能和强大，新技术不断被引入到组织内，以提升整体生产力。而这也会增加复杂性和开发人员的认知开销，减少了他们个人的生产力。

这里介绍的是一个用于最大化开发效率的框架。

通过研究，我找到了一些非常关键的开发者反馈回路，其中某些微反馈回路会在一天内被开发人员执行 200 多次。我们应该对这些微反馈进行不断地优化，让它们更快，更简单和更有影响力。

我经常帮助工程组织中的转型工作，这类转型通常是既是一个技术转型，又是一个文化转型。例如，这些组织可能试图将一个核心的单体应用分解成微服务，使它们能够由独立的团队开发和维护，同理，会引入DevOps方法论，以更快地响应来自市场的反馈信号。

然而，或早或晚地，这些变革之旅都失败了。因为管理者对延期和预算超支感到很不满。尽管技术人员努力地解决各方向上的障碍，然而，由于各种各样的依赖、认知超载，以及和在新工具/流程方面缺少知识，导致最新技术成果的转化还不够快，生产力太低，没有达成对领导层的承诺。

事实上，开发效率高的公司和低的公司之间，有一个鲜明的对比。当我们研究这些场景时，问题的一个主要原因是：工程组织忽视了一点，即：为开发人员提供一个有效的工作环境。在变革期间，组织引入了许多新流程、新工具和新技术，这导致在开发人员的日常任务中，增加了一定量的复杂性和摩擦力。

通过与各种类型的公司打交道（这些公司可能是刚刚开始数字化转型，或进程已过半，而且在一开始就导入了DevOps文化），我发现，通过对比开发者的一天日常工作，就能识别这个公司是高效公司，还是低效公司。

开发者在高效环境中的一天

• 早上来查看团队项目管理工具，然后参加standup，她很清楚自己要做什么。
• 注意：此时，开发环境已自动更新，其所依赖的类库和服务也是与生产生产环境一致的，而CI/CD 流水线也是绿色的（处于成功状态）。
• 从代码库拉下最新代码，进行增量代码开发，并通过部署到本地环境，运行单元测试进行快速验证。
• 他开发的特性依赖于另一个团队负责的业务API。能够通过开发者门户找到该团队的文档和API规范。看了文档，他仍然有一些疑问，于是，他就跑到那个团队的on-call支持群里，快速从另一个正在负责技术支持的开发人员那里获得了帮助。
• 他在几个小时内专注于自己的任务，没有任何干扰。
• 休息一下，喝杯咖啡，散散步，和同事一起打会儿乒乓球。
• 提交代码变更。这个变更在部署到生产环境之前，要经过多种自动检查。然后，发布到生产环境上，逐步让更多的用户使用，同时监控业务和运维指标。

开发人员能够在一天之内就取得进展，并开心地回家了～

开发者在低效环境中的一天

• 新一天的工作刚开始，你就必须立即处理一些生产环境中的问题告警。
• 检查多个监控系统中查看大量日志记录，以查找错误报告，因为没有跨系统的聚合日志。
• 与电话那头儿的运维同事不停地讨论，最后确认，这个警报是误报。
• 你必须等待架构组、安全组和治理组对其之前已完成的特性的结果反馈。
• 一天中有很多会议，大多数会议都是状态跟进会议。
• 现在，前一个特性已经被审查者批准了，你把它合并到另一个分支，开始长时间的E2E测试套件。而这个一个独立QA团队管理测试套件几乎总是失败的。
• 由于你负责的代码依赖于其他团队的API，但又无法找到这个API的有效版本，只好去找另一边的项目经理沟通，试图得到答案。找答案的工单可能将需要几天，所以这阻碍了你当前任务的迅速完成。

我们还可以继续描述更多的情景。 但最终结果就是，开发者并没有取得什么成就， 令人沮丧和丧失动力～

什么是开发人员的高效性

高效是什么含义？作为一名开发人员来说，是向客户交付最大价值，是能够把自己的能量和创新力以最佳方式达成公司目标。如果是在一个高效环境下，他可以很容易地将有用且高质量的软件发布到生产环境，并高效运营，而不必处理那些具有不必要的复杂性且很琐碎的问题，或者长时间的等待，自己有更多的时间专注于增值活动。

在低效环境中，作为一名开发人员，你的一天就是处理无尽的事务，不是一件，而是很多件，时间被分割成数以千计的碎片。慢慢地，你生产力就被这些小东西破坏了。而且，这种效率低下，会产生复合效应，扩展到整个组织，而不仅仅是工程团队。更糟糕的是，这个环境中的这些人完全接受了这个现实。这种工作方式成为一种公认的惯例，并制定了在这种环境中进行开发的低效流程。实际上，开发者此时正面对习得性无助。

而在提供高效环境的组织中，会感受到一种动力，每件事都是简单有效的，而且开发人员很少遇到摩擦力。他们花更多的时间创造价值。 正是这种无摩擦的环境，以及支持它的文化，培养出不断提升的欲望和能力。当然，这是公司在做数字化转型中最难的事情。

高效是开发人员的动力。没有摩擦，他们就有时间创造性地思考，并运用它们。

组织都在寻找衡量开发人员生产力的方法。其中一个反模式就是看代码行数，输出的特性数，或者过多地专注于找出表现不佳的开发者。 更好的方式是围绕该组织如何提供一个高效的工作环境。没有摩擦，高效工程师就有时间创造性地思考和应用。如果组织不这样做，那么以我的经验，最好的工程师会离职

让我们看一个公司优化了开发人员效率的例子。

案例分析：Spotify

Spotify在其工程师中进行用户研究，以便更好地了解开发人员的高效性。通过这项研究，他们发现了两项主要调查结果：

1. 内部工具的碎片化。 基础设施和工具被建造成孤立的小“岛”，导致了工程师不得不进行上下文切换，以及认知负荷。

2. 信息发现能力差。Spotify没有一个地方可以找到技术信息。 随着信息的扩散，工程师们甚至不知道从哪里开始寻找信息。

Spotify的开发者体验研究团队将这些问题描述为一负向飞轮；也就是一个恶性循环。开发人员面临很多未知，迫使他们孤立地做出许多决定，而这在需要将碎片信息合成在一起时，增加了很多重复劳动，最终侵蚀了产品端到端的交付时间。

为了减轻这些复杂性，他们开发了一个后台系统，一个带有插件的开源开发者门户体系结构，以帮助在一个地方公开所有基础设施工具平台产品，提供一个连贯的开发者体验，和一个为工程师找到他们需要的信息的统一起点。

在我所描述的高效的环境中是什么感觉？喜欢在完全拥抱DevOps文化，持续交付和产品思维的公司工作。大多数公司非常明智的，他们已经读了《加速》一书，以及DevOps状态报告](https://martinfowler.com/bliki/StateOfDevOpsReport.html)。他们了解他们正在努力建立什么类型的组织。

四大指标（Leadtime、部署频率、MTTR和变更失败率） 是衡量DevOps的重要指标。

然而，这些DevOps度量是滞后性指标。它们的确是有用的度量指标，因为它们可以让你了解你所在的位置，并可以用于验收“你的公司公司所做的一些切实可行的事情以后，是否真的变得更好了”。在理想情况下，我们希望确定一些引领性的指标，这些指标比上面提到的滞后性指标低一个或多个层级，但是更易被执行的，也与更高的层次指标相关联。有一些指标可能还要结合其他来源，比如关于开发者满意度调查的研究报告。

已经有大量的好建议、实践、工具，可以应用于过程改进。但可能你仍旧很难知道到底要做什么。我的研究显示，有很多关键的开发者反馈环指示器。我建议把重点放在优化这些循环上，让它们变更快速且简单。当新的工具和技术被引入时，衡量这些反馈回路的长度和约束。这些低层次的细节指标可以清楚地显示开发人员有效性是否有所改善，或者至少不是更糟。

我确定的关键度量指标是：

这些指标是基于我所观察到的可能性。公司并不需要把上面所有的反馈回路指标都纳入到效率提升的范围中，但它们的确提供了具体的目标，用来指导做出一些决策。各组织应在其所在的具体情况下开展研究，以便找出哪些周期时间和指标是重要的技术策略。

常看看应用哪些技术可以用于优化反馈循环，以及公司实现这一目标的过程，这是非常有用的。 案例研究可以提供很多可以应用于自己组织内容的想法。

上图显示了开发人员特性开发过程中的反馈时长。你可以看到，在整个过程中的多个节点上，开发人员验证他的工作成果是否满足规范要求和预期标准的时间与节奏。

需要注意的主要观察点是：

• 如果反馈环时间短一些，开发人员就会更频繁地运行这个反馈环
• 如果开发人员认为这些反馈对他有价值就会更频繁地运行它，并对反馈结果采取行动，而不是纯粹的形式主义。
• 更早且更频繁地进行验证可以减少后来带来的返工问题。
• 反馈回路应该非常简单直接地解释反馈结果，从而减少反复沟通和认知开销。

当组织没能达成上述这些效果时，很多问题就会快速交织在一起，并产生更多的问题。大量的浪费会体现在等待、搜索，或尝试获得运行结果等方面。

这些问题累积起来，导致产品开发的重大延误，这将表现为在四个关键指标中得分较低，特别是部署频率和前置时间（Leadtime）。

引入微反馈回路

根据我的观察，你必须抓住一些最基本的东西。比如，开发者每天要做10次、100次或200次的东西，我称之为微循环。

这些微循环可以是：

• 为了修复bug，而运行单元测试

• 看到代码变更在本地环境或测试环境上产生了预期的变化

• 在自己的环境中刷新数据

如果给开发人员足够的授权，开发人员自然而然会对其优化。然而，我经常发现，这些微反馈回路被忽视了。这是为什么呢？

事实上，这些微循环所用的时间本来就不长，因为优化而能节省下来的时间看上去就更少。因此，我们就很难向管理层解释，为什么我们要关注这么小的问题。为什么我们要投入大量的时间来优化编译阶段，从 2 分钟降低到 15 秒？这些优化工作本身可能需要花很多时间，甚至需要更长的时间把系统解耦成多个独立组件。

其实，这么多的 2 分钟加起来很快就可以超过一天 100 分钟。这些小停顿就能让开发人员丢失上下文，或失去工作焦点。这么短的时间也足够让开发人员分心干点儿其它的事情，比如去看看电子邮件，看看群聊天，或者走人去喝杯水，这就会让他们脱离心流状态。

有研究表明，失去心流状态后，可能需要长达 23 分钟的时间才能再回到心流状态。我并不是说，工程师不应该休息，或 偶尔出去清醒一下头脑！但他们应该是有意而为之，而不是因为环境如此，不得不分心。

你可能会说，开发者可以做其它有用的工作呀？是的，的确是这样的，大部分开发者会找到其它一些有用的事情来做，以填补这些时间。他们可能同时做两个任务，并来回切换。当然，还有一种可能，那就是一次性改完大量的代码，然后再一起执行一次编译，从而降低编译频率。在我的研究中，这两个因素都会导致延迟集成代码，延长开发时间。

你需要优化到什么程度呢？怎么算够用了呢？想象一下，现在我们已经把编译时间缩短到了 15 秒，但我们认为我们可以把这个时间缩短到 3 秒。这个投资值不值得呢？这要看它难不难，以及会带来什么样的影响。。如果你能开发出一个工具，并能够让十个团队都用上，以提升速度，那么，它可能就是值得的。这就是平台思维，而不是针对单个团队的优化。

分布式系统是一个特殊的挑战。有很多理由促使我们将系统分成不同的可部署单元（通常是微服务）的原因。然而，分布式系统也使许多事情变得困难（ 微服务的前提条件），包括降低开发人员的效率。

有时团队为了团队自治而愿意做改造，或者运行时性能进行优化，但他们可能牺牲了开发人员效率，因为他们不投资于快速维护 反馈循环。而这是经常遇到的情况。