最大化开发人员效能

高效环境中的日常工作

开发人员

• 检查团队项目管理工具，然后参加站立会议，她清楚地了解了需要做什么工作。
• 注意到开发环境已自动更新，包含与开发和生产相匹配的库，并且 CI/CD 管道是绿色的。
• 拉取最新代码，进行增量代码更改，并通过部署到本地环境和运行单元测试来快速验证更改。
• 依赖另一个团队的业务功能来实现她的功能。她能够通过开发人员门户找到文档和 API 规范。她仍然有一些疑问，所以她跳进了团队的 Slack 房间，并迅速从另一个正在进行支持的开发人员那里获得了帮助。
• 专注于她的任务几个小时，没有任何干扰。
• 休息一下，喝咖啡，散步，和同事打乒乓球。
• 提交代码更改，然后通过一系列自动化检查，最后部署到生产环境。将更改逐步发布给生产环境中的用户，同时监控业务和运营指标。

开发人员能够在一天内取得增量进展，并开心地回家。

低效环境中的日常工作

开发人员

• 开始工作时，必须立即处理生产环境中出现的一系列问题警报。
• 检查多个日志和监控系统以查找错误报告，因为系统之间没有聚合日志。
• 与运营人员通话，确定警报是误报。
• 必须等待架构、安全和治理团队对之前完成的功能进行响应。
• 一天被许多会议打断，其中许多是状态会议。
• 注意到之前的功能已获得审阅者的批准，她将其移到另一个分支，启动一个漫长的夜间 E2E 测试套件，该套件几乎总是失败，由一个孤立的 QA 团队管理。
• 依赖另一个团队的 API，但她找不到最新的文档。因此，她与另一个团队的项目经理交谈，试图获得查询。找到答案的工单需要几天时间，因此这阻碍了她的当前任务。

我们可以继续说下去。但最终，开发人员并没有取得什么成就，感到沮丧和缺乏动力。

开发人员效能

有效意味着什么？作为一名开发人员，这意味着为你的客户提供最大的价值。这意味着能够以最佳方式将你的精力和创新应用于公司的目标。有效的环境使将有用、高质量的软件投入生产变得容易；并使其能够运行，以便开发人员不必处理不必要的复杂性、无谓的混乱或漫长的延迟——使他们能够专注于增值任务。

在说明低效环境的示例中，一切都比预期花费的时间更长。作为一名开发人员，你的工作日充满了无尽的障碍和官僚主义。这不仅仅是一件事；而是很多事。这就像被一千刀割死。缓慢地，生产力被微小的低效率所破坏，这些低效率具有累积效应。低效率的感觉蔓延到整个组织，不仅仅是工程部门。工程师最终感到无助；他们没有生产力。更糟糕的是，他们接受了这种状况，这种工作方式成为一种公认的惯例，定义了开发工作的完成方式。开发人员经历了 习得性无助。

而在提供高效环境的组织中，有一种前进的动力；一切都轻松高效，开发人员遇到的摩擦很少。他们花费更多时间创造价值。这种无摩擦的环境，以及通过培养不断改进的愿望和能力来支持它的文化，是公司在进行数字化转型时最难创造的东西。

组织寻找方法来衡量开发人员的生产力。常见的反模式是查看代码行数、功能输出，或过分关注试图找出表现不佳的开发人员。最好将对话转向关注组织如何提供有效的工程环境。生产力激励着开发人员。没有摩擦，他们有时间进行创造性思考并发挥自己的才能。如果组织不这样做，那么根据我的经验，最好的工程师会离开。当许多伟大的创新型数字公司都在寻找招聘优秀的技术人才时，开发人员没有理由在低效的环境中工作。

让我们看一个优化开发人员效能的公司示例。

案例研究：Spotify

Spotify 在其工程师中进行了用户研究，以更好地了解开发人员效能。通过这项研究，他们发现了两个关键发现。

1. 内部工具的碎片化。Spotify 的内部基础设施和工具是作为小型孤立的“孤岛”构建的，导致工程师进行上下文切换和认知负荷。
2. 可发现性差。Spotify 没有一个中心位置来查找技术信息。由于信息分散在各个地方，工程师甚至不知道从哪里开始查找信息。

Spotify 的开发人员体验团队将这些问题描述为一个负面飞轮；一个恶性循环，开发人员面临着太多未知因素，迫使他们在孤立的情况下做出许多决定，这反过来又加剧了碎片化和重复工作，最终侵蚀了产品的端到端交付时间。

图 1：Spotify 的负面飞轮

为了减轻这些复杂性，他们开发了 Backstage，这是一个具有插件架构的开源开发人员门户，可以帮助在一个地方公开所有基础设施产品，提供一致的开发人员体验，并为工程师提供查找所需信息的起点。

如何开始？

我在高效环境中描述的是在完全拥抱 DevOps 文化、持续交付和产品思维的公司中工作的感受。非常明智的是，大多数公司都在朝着实现这种环境的旅程中。他们已经阅读了 加速 和 DevOps 状态报告。他们知道自己正在努力构建什么样的组织。四个关键指标（交付周期时间、部署频率、MTTR 和变更失败率）是 DevOps 性能的良好衡量指标。

看待 DevOps 指标的一种方法是，它们是 滞后指标。它们是了解当前状况和指示何时需要进行工作的有用指标，以确定公司应该采取哪些切实可行的措施来改进。理想情况下，我们希望确定更可操作的效能领先指标。它们与更高层次的指标之间存在相关性。它将逐步上升。这还应与其他研究来源相结合，例如关于开发人员满意度的调查。

有大量关于应该使用哪些好的建议、实践、工具和流程来改进的信息。很难知道该怎么做。我的研究表明，存在许多关键的开发人员反馈循环。我建议专注于优化这些循环，使它们快速简单。衡量反馈循环的长度、约束条件和最终结果。当引入新的工具和技术时，这些指标可以清楚地显示开发人员效能是否得到改善，或者至少没有恶化。

反馈循环

我确定的关键循环是

这些指标基于我观察到的可能性。并非每家公司都需要每个反馈循环都处于高效率类别，但它们提供了具体的目标来指导决策。工程组织应该在其特定环境中进行研究，以确定哪些循环和指标对技术战略很重要。

查看哪些技术已被应用于优化反馈循环以及公司为实现这一目标所经历的旅程，这很有用。这些案例研究可以提供许多想法，供您在自己的组织中应用。

图 2：功能开发过程中的反馈循环

上图简化地展示了开发人员在开发过程中如何使用反馈循环。您可以看到，开发人员在开发过程中的多个点验证他们的工作是否满足规范和预期标准。需要注意的关键观察结果是

• 如果反馈循环更短，开发人员将更频繁地运行它们。
• 如果开发人员认为反馈循环对他们有价值，而不是纯粹的官僚主义开销，他们将更频繁地运行它们并根据结果采取行动。
• 尽早更频繁地获得验证可以减少后期的返工。
• 易于解释结果的反馈循环可以减少来回沟通和认知开销。

当组织未能实现这些结果时，问题会迅速加剧。开发人员会浪费大量精力。体现在等待、搜索或试图理解结果所花费的时间。这会累积起来，导致产品开发出现重大延误，这将表现为四个关键指标（特别是部署频率和交付周期）得分降低。

介绍微反馈循环

根据我的观察，您必须掌握基础知识，即开发人员每天执行 10、100 或 200 次的事情。我称之为微反馈循环。这可能是修复错误时运行单元测试。这可能是看到代码更改反映在您的本地环境或开发环境中。这可能是刷新您环境中的数据。开发人员如果得到授权，会自然地进行优化，但我经常发现微反馈循环被忽视了。这些循环是故意缩短的，因此您最终会处理一些非常小的增量时间。

图 3：微反馈循环累积影响更大的反馈循环。

很难向管理层解释为什么我们必须关注如此小的问题。为什么我们必须投入时间来优化编译阶段，使其从 2 分钟的运行时间缩短到仅需 15 秒？这可能需要大量工作，可能需要将系统解耦为独立的组件。更容易理解优化需要两天时间的事情是值得进行的。

这两分钟会很快累积起来，每天可能超过 100 分钟。这些短暂的停顿是失去上下文和专注的机会。它们足够长，可以让开发人员分心，决定打开电子邮件或去喝咖啡，这样他们现在就分心了，并且处于非流动状态，有研究表明，恢复到流动状态并恢复高生产力可能需要长达 23 分钟。我并不是说工程师不应该偶尔休息一下，让头脑清醒！但他们应该有意识地这样做，而不是由环境强制执行。

实际上，开发人员会通过用有用的事情来填补这些不活跃的时刻来进行补偿。他们可能同时进行两个任务，并在它们之间切换。他们可能会通过批量更改来降低编译频率。在我的研究中，这两种情况都会导致代码集成和开发时间的延迟。

您优化到什么程度？什么时候足够了？假设我们现在将更改缩短到 15 秒，但我们认为可以将其缩短到 3 秒。这值得投资吗？这取决于进行更改的难度以及它带来的影响。如果您能开发出一种工具或功能，可以加快 10 个团队的速度，那么它可能是值得的。这就是平台思维发挥作用的地方，而不是针对单个团队进行优化。

分布式系统是一个特殊的挑战。将系统拆分为不同的可部署单元（通常是微服务）有很多正当理由。但是，分布式系统也使许多事情变得困难（参见微服务先决条件），包括开发人员的有效性。有时团队可能会优化团队自治或运行时性能，但他们会牺牲开发人员的有效性，因为他们没有投资于维护快速的反馈循环。这是我的公司经常遇到的情况。

组织效能

高效的组织已经设计了他们的工程组织，以优化有效性和反馈循环。随着时间的推移，领导层创造了一种文化，导致授权开发人员对这些反馈循环进行增量改进。

它始于领导层认识到技术——以及消除开发团队的摩擦——对业务至关重要。这在许多方面都有体现。

技术领导者不断衡量和重新审视有效性。高效的组织已经创建了一个框架，通过跟踪四个关键指标以及对他们环境重要的其他数据点来做出数据驱动的决策。这种文化始于执行层，并传达给组织的其他成员。

除了指标之外，他们还创建了一个开放论坛，倾听每天在环境中工作的个人贡献者。开发人员会知道他们面临的问题，并会提出许多解决这些问题的想法。

根据这些信息，工程经理可以决定投资的优先级。大型问题可能需要相应的大型现代化计划来解决糟糕的开发人员体验。但通常更多的是授权团队进行持续改进。

一个关键原则就是拥抱开发人员体验。通常会看到一个团队的工作计划专注于此。开发人员体验意味着技术能力应该使用与最终用户产品开发相同的方法构建，应用相同的研究、优先级、结果导向的思维和消费者反馈机制。

为了激励开发人员，高效的组织会进行特许经营；这意味着开发人员应该有能力改善他们的日常生活。他们有一个政策，让团队进行增量技术改进并管理技术债务。开发人员和产品管理之间应该进行健康的、有数据支持的讨论。高效的组织还为开发人员提供创新的能力；当他们的团队有明确的目标和明确的瓶颈认识时，开发人员可以在解决问题方面富有创造力。这些组织还创造了让最佳想法“浮出水面”的方法，然后加倍努力，使用数据来评估什么是最好的。

在承诺、衡量和授权之后，是扩展。

在一定规模的组织中，需要通过规模经济来创造效率。组织通过应用平台思维来做到这一点——创建专门针对提高有效性的内部平台。他们投资于构建技术能力以提高开发人员有效性的工程团队。他们将其他开发团队视为他们的消费者，他们提供的服务被视为产品。这些团队拥有技术产品经理和与他们如何影响消费团队相关的成功指标。例如，专注于可观察性的平台能力团队创建了监控、日志记录、警报和跟踪功能，以便团队可以轻松地监控其服务运行状况并调试其产品中的问题。

治理的必要性仍然是优先事项。但是，这不需要被视为一个脏词，因为它的应用在高效的组织中非常不同。他们从集中式流程转向轻量级方法。这是关于设定和传达护栏，然后引导团队朝着正确的方向发展，而不是冗长的审批流程方法。治理在通过以下方式实施时，可以在有效性方面发挥关键作用

• 明确的工程目标
• 指定团队和服务之间相互通信的方式
• 鼓励有用的同行评审
• 将最佳实践烘焙到平台功能中
• 通过架构适应度函数自动化控制

本质上，有效的组织缩短了治理反馈循环。我将在以后的文章中对此进行扩展。

案例研究：Etsy

Etsy 是 DevOps 运动的先驱之一。其领导者一直致力于将开发人员的有效性融入其文化，他们相信快速行动既是一种技术战略，也是一种商业战略。他们积极衡量他们快速安全地将有价值的产品投入生产的能力，并将调整他们的技术投资以修复任何阻碍或缓慢。

Etsy 的关键指标之一是交付周期，它在整个办公室实时测量、监控和显示。当交付周期达到某个关键阈值以上时，发布工程团队将努力将其降低到合理的水平。他们的首席技术官迈克·费舍尔谈到 Etsy 工程师“无所畏惧”地快速前进，拥有安全网来尝试新事物。

快速部署软件只是故事的一半。要真正有效，该软件必须对消费者有价值。Etsy 通过采用数据驱动的方法来做到这一点，每个功能都有可衡量的 KPI。

代码更改会经过一系列检查，以便开发人员确信更改符合 Etsy 的性能、可用性、故障率等 SLA。更改投入生产后，Etsy 的实验平台能够捕获用户行为指标。团队使用这些指标来迭代产品，优化相关的 KPI 和用户满意度。如果最终证明更改没有价值，它将被清理，从而避免技术债务。

Etsy 目前有一个优先考虑开发人员体验的计划。它有四个关键支柱

该政策代表了 Etsy 领导层对其开发人员的真正承诺。他们通过跟踪包括四个关键指标在内的指标以及每月对开发人员进行调查以捕获净推荐值 (NPS) 来不断验证他们的有效性。

结论

本文开头谈到了开发人员有效性的重要性及其对开发人员幸福感和生产力的影响。我专注于开发人员想要实现的结果，而不仅仅是工具和技术。通过进一步推动这种考察，我们看到了一系列开发人员在开发产品时经常使用的反馈循环。

我还谈到了微反馈循环中的低效率如何累积影响更大的指标，例如四个关键指标和产品开发速度。以及强调开发人员体验作为一项原则的重要性，以及平台思维如何帮助最大限度地提高效率和规模效益。

在接下来的系列文章中，将通过案例研究进一步解释对开发人员有效性和各个反馈循环的更深入的探讨。这些将提供具体细节，说明组织如何能够实现这些数字以及由此产生的结果。除了描述在本地和全球范围内实现这些优化的组织结构和流程。

下一篇文章将从最小的微反馈循环开始。