当平台工程遇上DevEx：打造卓越的开发者体验

作者：京东零售 井亮亮

引言

近期在参与编写平台工程系列标准时，我发现开发者体验 (DevEx) 是一个不可忽视的关键因素，它对于构建一个成功的平台工程起到了重要的作用，DevEx 可以称之为平台工程的基础。基于我最近的学习和思考，我决定写这篇文章，想深入探讨一下 DevEx 对于内部开发平台的重要性，也希望为从事内部开发平台的同学们带来一些新的思考。

了解平台工程

平台工程是设计和构建工具链和工作流的学科，可在云原生时代为软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为“内部开发人员平台”，涵盖了应用程序整个生命周期的运营需求。 --定义来自 platformengineering.org

关于平台工程的定义和思考，我在上一篇《扯淡的DevOps，我们开发根本不想做运维！》文章也提到了，关于定义目前虽然从文字内容上有些差异，但大部分的意思较为一致：主要是倡导自助服务，将底层基础支撑工具的复杂性和不确定性去减少，减化工作流程，最终用户在使用过程中的认知成本降低，从而改善了最终用户的体验，和提高生产效率。

为什么需要平台工程

在公司内部，有负责中台的研发团队，有负责前台的研发团队，还有团队专注于开发者平台的研发。这些从事内部开发者平台的同学，实际上就是平台工程团队。与其他团队相比，平台工程团队最大的区别在于他们需要具备产品思维。这些团队的同学可以称做平台工程师，那么每个平台工程师最少是个兼职产品经理。

然而，在实际情况中，这些平台工程师可能过于专注于技术实现，而会忽略用户的需求和反馈。他们可能会认为自己负责的工具平台自己是最了解的，因此很少会去调研真正用户的需求和反馈，日复一日不断地开发新的产品和功能。

这里抛个问题，可以思考一下：为什么企业在选择上云时，往往不直接使用公有云控制台，而是通过企业的云管平台提供服务呢？

表面来看，直接使用公有云控制台似乎是最简单高效的选择。然而，当使用以后我们深入分析后发现，这种选择可能会带来一系列的严重问题。最终可能会造成资源浪费、资源安全性问题。另外，使用公有云控制台的使用成本也较高，从而也降低了用户的体验。

在平台工程的倡导下，应该降低开发人员的认知负荷和使用成本，企业通过 云管平台 来提供服务，可以有效降低开发人员使用认知成本，提升用户的体验，让开发人员能够更专注于构建自己的应用程序。

了解 DevEx

开发者体验 (DevEx) 指的是软件开发人员在日常工作中遇到的整体环境、工具、实践和文化。它涵盖了从设置开发环境的便捷性，到工作流程的效率，到工具和流程的有效性，以及整体的支持其创造性和技术努力的工作文化。

一个最常见的误解是，开发者体验 (DevEx) 主要受内部开发者工具的影响。然而，根据调研发现，除了工具因素外，环境因素和人为因素同样对开发者体验产生重大影响。

环境因素包括办公环境、团队文化等。一个良好的工作环境能够激发创造力，提高工作效率。例如，一些公司为了营造轻松愉悦的办公氛围，提供了各种娱乐设施，如啤酒桶、咖啡角、弹球台、乒乓球台等设施，旨在让开发者缓解工作压力，有助于提升开发体验。

另外，项目的稳定性、目标的明确性、绩效考核方式的清晰性也是影响开发者体验的重大因素。如果项目团队经常调整组织架构，项目目标不明确，绩效考核 A/A+ 的定义模糊不清，开发人员会感到非常困惑和不安，会极大影响研发同学的工作效率和体验。

因此，DevEx 是平台工程的基石，是促进开发人员效率提升的最佳路径。

DevEx 在平台工程中的意义

提升开发人员的效率一直以来都是一个追求的目标，但如何衡量开发人员的效率却一直是一个难题。仅仅追求需求交付周期或开发交付周期是相对比较片面的，未能考虑到开发人员的工作是一个复杂且多样化的任务。那么，怎么来衡量开发人员的生产力呢？

然而，一些企业在追求提高开发人员生产力方面取得了一些发现，他们发现注重开发人员的体验，以开发人员体验为目标的方法（DevEx）可以极大地促进开发人员的效率。根据 Gartner 的调研报告，78% 的受访企业已经制定或计划制定 DevEx 提升计划。DevEx 提供了一个度量框架，该框架将开发人员的反馈、认知负荷成本和专注程度综合在一起，为开发人员提供了清晰、可操作的衡量维度。

在平台工程领域，DevEx 是一个至关重要的因素。关注它不仅可以提高开发人员的工作效率，还可以加快交付周期，并提升开发者的幸福感。通过关注开发人员的体验和提供良好的工具和环境，企业为开发人员创造一个舒适且高效的工作环境，从而可以提高整体的开发效率和质量。

落地 DevEx

DevEx 是最大化提升开发效率的关键，假设你是平台工程团队，不知道有没有主动思考过一个问题：“为什么开发人员不愿意使用我们的工具？”，作为平台工程团队一定要牢记以下7个方法：

1、了解你的用户（开发者）

“顾客就是上帝”，虽然我们不是甲乙方，虽然我们同在一家公司，甚至一个办公室，但你是否真的了解用户的需求？你是否将用户视为上帝？是否真的了解用户的需求和痛点？

在平台工程团队，了解用户诉求，不仅仅是产品经理的职责，更应该是整个平台工程团队的工作，不仅要了解用户痛点，而且还要清楚知道用户平时都是以什么方式在使用你的平台。

•线上调查问卷：调查问卷是最直接的渠道，可以定期主动收集用户的心声。

•线下培训活动：面对面的产品培训，或通过用户拜访以及其他方式，面对面收集用户的意见。

•保持好奇心：多关注用户群、神灯畅聊的消息，当听到有抱怨或吐槽声音，要及时跟进解决并思考。

2、向专职 UX 岗位学习

如果把开发人员当初用户来看的话，其实 DevEx 要做的事，和公司内的专职 UX 岗位同学的职责差不多。 UX 岗位大部分精力都在和用户沟通调研，最终形成用研报告。

“唯一好的假设就是我们的假设是错的”，我特别喜欢这句话，讲的非常有道理，因为当我们开始假设的时候，我们就已经错了。通过假设做出了某个需求的时候，要么是没人需要的功能，要么是解决了没有人遇到的问题。因为所有的功能，都应该是发现出来的，而不是假设出来的。功能都是经过：发现、设计、开发、交付这4个阶段，但最难的就发现问题，通常 UX 岗位同学在用研过程中是最容易发现问题的。

3、以用户为中心的心态

任何产品都应该以用户为中心，在平台工程团队更加重要，因为常常我们自己也是用户，特别容易把角色搞混，所以更应该时刻强调，谁才是真正的用户，且要时刻确保这种心态。

•一定不要假设用户的需求。

•所有的需求用用户视角去描述，解决【哪些用户】的【什么问题】，将需求的目标转移到用户身上。

4、自动化你的系统

自动化在提升 DevEx 方面具有重要作用，无论是在成本、效率还是稳定性方面。通过自动化工具和流程，都可以自动完成繁琐的任务，减少开发人员的负担。例如，自动化构建和部署流程可以减少手动操作的错误，并加快交付时间。自动化测试可以提高产品质量和稳定性，减少问题的出现。此外，自动化还可以帮助提高产品的一致性，减少人为因素的影响，提高稳定性和可靠性。

总的来说，自动化在提升 DevEx 方面是至关重要的。通过减少手工环节和自动化流程，可以降低用户使用产品或工具的步骤，从而提高开发者体验。

5、明确岗位和职责

在过去，大部分公司里面有这样一个岗位，叫 SCM 工程师或者配置管理工程师，但这些年随着 DevOps 的发展，自动化构建和持续集成/持续交付的成熟，开发人员通常会通过工具自动化完成这些工作，从而减少了专职的需求，因此这个岗位或者叫法正在慢慢消失。

目前，在公司中负责平台或者工具的团队，虽然有专职的团队，但岗位名称大部分仍然是前端/后端软件开发工程师岗，这就无法明确这部分同学的具体职责，但虽然平台工程的发展和推动，目前在一些公司中，已经有一些叫平台工程师这个岗位角色，这个角色正在逐步替代测试开发、工具开发、运维开发、甚至替代SRE的岗位角色。因此，我觉得通过明确的岗位和角色，可以更好明确岗位对应的具体职责，更好推动平台工程的落地。

6、Shifting down

在软件开发过程中，通过转移的方式，将开发人员身上的职责进行减轻，通过转移到其他角色或者平台上，从而降低开发人员的负担，从而提升 DevEx。

左移：将测试左移，测试在开发过程中早期阶段进行，可以更早发现和解决Bug，使用自动化测试工具或者测试框架来验证代码，不过这种做法对测试要求较高，如果测试人员能力达不到，一味地推动测试左移，甚至可能会给开发增加负担哈哈。

右移：上线效果A/B实验，通过比较实验的方法来验证上线功能效果。

下移：下移的整体思路就是将开发人员从工具和平台中解放出来，平台工程师负责构建和维护工具平台，为开发人员提供稳定的基础设施和工具，这样，开发人员可以专注于业务逻辑和创新，可以加快开发速度，从而也提升了 DevEx。

7、建立衡量 DevEx 的指标

最后一点，是建立 DevEx 指标，从而衡量 DevEx，并提升 DevEx ，老实说这点确实比较难，但想一想业务开发团队都能指定一些 KPI 去衡量，那么平台工程团队也应该这样做，或者可以说可以尝试这么做。

度量 DevEx

大师彼得·德鲁克说过：“如果你无法衡量它，你就无法管理它。”，在 23 年发布的一篇研究论文中揭示了度量和提升开发者生产力的一种全新框架，该框架称之为 DevEx 框架，作者为 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。

影响 DevEx 的因素

针对开发效率或开发者生产力的度量，为什么一直以来都比较困难，主要有两大原因：一方面软件开发的过程是不可重复且创造性的工作，另一方面开发人员在工作中容易受到外部干扰的影响。

①软件开发过程非标准：软件开发的过程不是重复性的劳动，且是创造性的工作，产出物并非标准的可衡量的，无法通过衡量流水线车间工作一样的办法来衡量软件开发工作。

②外部干扰的影响：除了公司提供的工具效率影响外，也还有开发项目的难易程度、开发者和其他角色的沟通成本、历史代码的技术债务等因素都会影响开发效率。

DevEx 框架提出了反馈周期、认知负荷、专注状态三个维度。倡导通过关注这三个维度，从而推动开发者生产力的提高。

•反馈周期：在开发过程中，可以快速的反馈对于提供开发人员的工作效率至关重要。例如，构建、测试或开发环境设置效率低下，导致反馈周期延长，将直接影响开发人员工作的积极性和生产力。

•认知负荷：在开发过程中，如果开发人员需要花费大量时间理解代码、理解工具的使用方法或者查找文档上，这会导致认知负荷增加，从而影响工作效率。

•专注状态：在开发过程中，如果开发人员频繁被打断或干扰，不能进入到专注状态，那么生产力就会收到严重影响。我们的 “No meeting day” 其实也是组织为大家能够进入到专注状态的一种手段和方式。

衡量 DevEx 的指标

对于提升开发者体验，衡量指标是非常重要。下图是 DevEx 框架提供的一个示例，用于了解当前存在的问题，从反馈周期、认识负荷、专注状态三个维度进行评估。建议在每个维度上选择要一两个关键指标进行度量。同时，也需要从全局上考虑，制定一些宏观指标，如员工满意度、需求交付周期等，作为全局考核的北极星指标。

为了衡量开发者体验（DevEx），需要综合考虑主观和客观数据。除了从相关工具或系统中获取客观数据外，还需要调查开发人员的看法、态度和意见。这些主观的数据在某些情况下可以提供相对准确的反馈。

例如，尽管构建过程可能非常高效，但如果构建操作的步骤过于复杂，可能会干扰开发人员并影响其体验。因此，从整体构建过程的角度来看，开发者体验可能相对较差。这种主观反馈可以补充客观数据，提供更全面的视角。

除了反馈周期，认知负荷对开发者体验的影响最大。认知负荷可以从两个状态来看：

•进入状态：这是开发人员完全投入并享受工作的状态，通常需要约 23 分钟的时间来进入。如果频繁中断这种工作状态，例如穿插其他任务，那么进入状态所需的时间可能会更长。

•等待状态：例如等待重新编译、等待代码评审、等待部署、等待服务启动等。这些等待状态的累计时间将构成认知负荷的一部分。

常见的 DevEx 度量指标。例如，可以选择度量自动化测试效率（反馈周期）、平均部署时长（反馈周期）、执行路径数（认知负荷）、可选择操作数（认知负荷）、代码库复杂性（认知负荷）、技术债务（认知负荷）和深度工作时间（专注状态）、XX自动化率（综合维度）、平台NPS满意度值（综合维度）。

通过综合考虑以上指标，可以帮助组织更好地发现真实的开发者体验，找出可能存在的问题，并针对性地进行优化，通过不断地改进和度量，从而提升 DevEx 。

结语

根据 StackOverflow 的调查，约有 62% 的受访者每天花费超过 30 分钟的时间在搜索答案和解决问题上，而 25% 的人甚至花费超过 1 小时。此外，根据 CNCF 云原生的 Landscape 展示，目前已有 2000+ 张卡片，覆盖了各个维度的能力，但这也导致了开发人员认知负担的日益加重。

审核编辑 黄宇