最大化开发人员效率
技术不断变得更加智能和强大。我经常观察到，随着这些技术的引入，组织的生产力（而不是提高）降低了。这是因为该技术增加了开发人员的复杂性和认知负担，从而降低了其有效性。在本系列的第一篇文章中，我介绍了一个最大化开发人员效率的框架。通过研究，我确定了关键的开发人员反馈循环，包括开发人员每天执行200次的微反馈循环。这些应该进行优化，以便它们对开发人员快速，简单且有效。我将研究一些组织如何使用这些反馈循环来提高整体效率和生产力。
我经常帮助处于转型中的工程组织。这通常既是技术转型，也是文化转型。例如，这些组织可能正在尝试将核心的单片系统分解为微服务，以便他们可以拥有独立的团队并采用DevOps方法。他们可能还希望提高敏捷性和产品技术，以更快地响应市场中的反馈和信号。
这些努力在一遍又一遍地失败了。经理们对延误和预算超支感到不满，而技术人员则努力解决各个方面的障碍。生产率太低。这些团队瘫痪于无数的依赖关系，认知超负荷和新工具/过程的知识不足。对执行领导层关于最新技术的承诺还没有很快实现。
开发人员效率高低的公司之间的方法形成了鲜明的对比
当我们研究这些场景时，出现问题的主要原因是工程组织忽视了为开发人员提供有效的工作环境。在进行转换时，他们引入了太多的新过程，太多的新工具和新技术，从而导致其日常工作中增加了复杂性并增加了摩擦。
我与各种类型的公司合作。这些企业可能只是刚刚开始数字化转型的企业，或者只是半途而废的企业，也可能是从一开始就采用DevOps文化文化的企业。我发现开发人员效率高低的公司之间的方法形成了鲜明的对比。
检查团队项目管理工具，然后参加独立会议，在那里她清楚自己需要做什么。
注意，开发环境已自动更新为与开发和生产相匹配的库，并且CI / CD管道是绿色的。
提取最新代码，进行增量代码更改，可通过将其部署到本地环境并运行单元测试来快速验证。
该功能取决于其他团队的业务能力。她能够通过开发人员门户网站找到文档和API规范。她仍然有一些疑问，因此她跳入了团队的Slack会议室，并迅速从另一位正在提供支持的开发人员那里获得帮助。
提交代码更改，然后在部署到生产之前先通过一系列自动检查。在监视业务和运营指标的同时，将更改逐步发布给生产中的用户。
开发人员可以在一天内取得渐进的进度，并可以回家。
开始新的一天，必须立即处理生产中出现问题的大量警报。
检查多个日志记录和监视系统以查找错误报告，因为系统之间没有聚合的日志。
必须等待架构，安全性和治理小组对她已完成的先前功能的答复。
注意到先前的功能已由审核员批准，她将其移至另一个分支，该分支启动了一个漫长的夜间E2E测试套件，该套件几乎总是红色，由孤立的QA团队管理。
取决于另一个团队的API，但是她找不到当前文档。因此，她与另一个团队的项目经理交谈，试图获取查询。寻找答案的门票将需要几天时间，因此这阻止了她当前的任务。
我们可以继续。但是最终，开发人员并没有取得太大成就，沮丧而又毫无动力
有效是什么意思？作为开发人员，它正在为您的客户提供最大的价值。它能够以最佳方式将您的精力和创新应用于公司的目标。有效的环境可以轻松将有用的高质量软件投入生产；并对其进行操作，以使开发人员不必处理不必要的复杂性，琐碎的搅动或长时间的延迟-使他们能够专注于增值任务。
在说明低效环境的示例中，一切花费的时间都超过了应有的时间。作为开发人员，您的每一天都是无休止的阻碍和官僚主义。这不仅仅是一件事，很多。这类似于裁减1000人。效率低下会导致生产率低下，而效率低下会导致复合效应。效率低下的感觉遍布整个组织，而不仅仅是工程。工程师最终感到无助。他们没有生产力。更糟糕的是，他们接受它后，工作方式就成为定义开发方式的公认例行程序。开发人员会遇到学习的无助。
在提供高效环境的组织中，有一种动力。一切都很简单，高效，并且开发人员几乎不会遇到摩擦。他们花更多的时间创造价值。正是这种无摩擦的环境以及通过不断发展的愿望和能力来支持它的文化，这是公司在进行数字化转型时要创建的最难的事情。
富有生产力会激励开发人员。在没有摩擦的情况下，他们有时间进行创造性思考和运用自己
组织正在寻找衡量开发人员生产力的方法。常见的反模式是查看代码行，功能输出或将过多的精力放在试图发现表现欠佳的开发人员上。最好进行讨论，以专注于组织如何提供有效的工程环境。富有生产力会激励开发人员。在没有摩擦的情况下，他们有时间进行创造性思考和运用自己。如果组织不这样做，那么以我的经验，最好的工程师会离开。当许多伟大的创新数字公司希望聘请强大的技术人才时，开发人员没有理由在效率低下的环境中工作。
Spotify在工程师中进行了用户研究，以更好地了解开发人员的效率。通过这项研究，他们发现了两个关键发现：
内部工具中的碎片。 Spotify的内部基础架构和工具被构建为孤立的小型“孤岛”，从而为工程师带来了上下文切换和认知负担。
可发现性差。 Spotify没有找到技术信息的中心位置。随着信息四处传播，工程师甚至不知道从哪里开始寻找信息。
Spotify的开发人员经验团队将这些问题描述为负面的飞轮；这是一个恶性循环，开发人员面临太多未知因素，迫使他们孤立地做出许多决定，这反过来又增加了工作的分散性和重复性，最终侵蚀了产品的端到端交付时间。
为了减轻这些复杂性，他们开发了Backstage，这是一个具有插件体系结构的开放源代码开发人员门户，可帮助将所有基础结构产品展示在一个地方，从而提供一致的开发人员体验，并为工程师查找所需信息提供了起点。
在高效环境中，我所描述的就是在一家完全拥护DevOps文化，持续交付和产品思考的公司中工作的感觉。非常明智的是，大多数公司都在努力实现这一环境。他们已经阅读了Accelerate和DevOps状态报告。他们知道他们正在努力建立哪种类型的组织。四个关键指标（提前期，部署频率，MTTR和更改失败百分比）是DevOps性能的重要指标。
查看DevOps指标的一种方法是它们是滞后指标。它们是有用的衡量标准，可帮助您了解自己的位置，并指出何时需要进行工作以弄清公司应该做些什么才能使自己变得更好。理想情况下，我们要确定更可行的领先的较低水平的有效性指标。与更高级别的指标相关。它会爬起来。还应将其与其他研究资源（例如，对开发人员满意度的调查）相结合。
您应该使用大量的良好建议，实践，工具和流程来进行改进。很难知道该怎么做。我的研究表明，存在许多关键的开发人员反馈循环。我建议着重优化这些循环，使它们快速简便。测量反馈回路的长度，约束条件和结果。当引入新的工具和技术时，这些指标可以清楚地表明开发人员的效率提高的程度，或者至少没有恶化的程度。
指标基于我观察到的可能。并非每个公司都需要每个反馈环都可以进入高效存储桶，但它们提供了指导决策的具体目标。工程组织应在其特定环境下进行研究，以确定哪些周期和度量标准是重要的技术策略。
看看应用了哪些技术来优化反馈循环以及公司为达到该目标而进行的旅程非常有用。这些案例研究可以提供许多想法，供您在自己的组织中应用。
上图显示了开发人员在开发过程中如何使用反馈循环的简化表示。您可以看到开发人员在此过程中的多个点上验证了他们的工作是否符合规范和预期的标准。要注意的主要观察结果是：
如果开发人员认为对开发人员有价值，而不仅仅是官僚主义的开销，他们将更频繁地运行并对结果采取行动。
易于解释结果的反馈循环，减少了来回通信和认知开销。
当组织无法达到这些结果时，这些问题会很快变得复杂。开发人员付出了很多浪费的精力。体现在等待，搜索或尝试理解结果所花费的时间上。它加起来会导致产品开发的显着延迟，这将表现为四个关键指标（尤其是部署频率和交付时间）得分较低。
根据我的观察，您必须牢记基础知识，即开发人员每天执行10、100或200次的操作。我称它们为微反馈循环。这可能在修复错误时正在运行单元测试。可能会看到代码更改反映在您的本地环境或开发环境中。它可能正在刷新您环境中的数据。开发人员如果获得授权，自然会进行优化，但是我经常发现微反馈循环已被忽略。这些循环是故意缩短的，因此您最终需要处理一些非常小的时间增量。
很难向管理层解释为什么我们必须专注于如此小的问题。为什么我们要花两分钟的运行时间来优化编译阶段，而只花15秒呢？这可能需要大量工作，可能需要将系统分离为独立的组件。将需要花费两天时间的工作优化为值得完成的工作要容易得多。
这两分钟很快就会加起来，一天可能会超过100分钟。这些短暂的停顿是失去背景和注意力的机会。它们足够长，以至于开发人员无法分心，决定打开电子邮件或去喝杯咖啡，因此现在他们正分心而无法正常使用，有研究表明，这样做可能最多需要23分钟的时间。恢复到流动状态并恢复高生产率。我不是在建议工程师们不应该休息一下并且偶尔清理一下头！但是他们应该有目的地这样做，而不是由环境强制执行。
实际上，开发人员将通过在这些不活跃的时刻填充有用的东西来进行补偿。他们可能正在进行两项任务，并在它们之间切换。他们可能会通过批量添加更改来降低编译频率。在我的研究中，这两者都会导致代码集成和开发时间的延迟。
您需要进行多长时间的优化？什么时候足够？想象一下，现在我们可以将更改降低到15秒，但是我们认为可以将其更改为3秒。这值得投资吗？这取决于进行更改的难度及其带来的影响。如果您可以开发一种可以加速10个团队的工具或功能，那可能是值得的。这是平台思考而不是针对单个团队进行优化的地方。
分布式系统是一个特殊的挑战。将系统分为不同的可部署单元（通常是微服务）有很多有效的理由。但是，分布式系统也使许多事情变得困难（请参阅微服务先决条件），包括开发人员的效率。有时，团队可能会针对团队自治或运行时性能进行优化，但是他们牺牲了开发人员的效率，因为他们不投资于维护快速的反馈循环。这是我公司遇到的非常普遍的情况。
我们将分期发布本文。下一部分将探讨改善这些反馈循环的步骤以及Etsy从专注于开发人员效率方面吸取的教训
要了解何时发布下一部分，请订阅该站点的RSS feed或Martin的twitter流
感谢Spotify的Pia Nilsson和Etsy的Keyur Govande合作开展了有关其工作的案例研究。
感谢我的同事Cassie Shum和Carl Nygard的反馈和研究帮助。没有赖安·默里（Ryan Murray）关于平台思维的想法，就不可能有这篇文章。
