为什么你的组织应该优先考虑开发者体验
原文链接｜https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience
对于经历了转型和迁移到云的科技公司来说，下一个释放生产力的机会在开发者体验方面。提高开发者体验可以改善企业形象，提高员工留存率，增强产品的安全性和质量，并释放开发者生产力。
为什么要考虑开发者体验
类似更广泛的员工体验，优秀的开发者体验让开发者的生活更轻松，这反过来可以转化为更优秀的表现。开发者经常要花很多时间与公司的繁文缛节斗争，发邮件，开会，找人，只不过是为了完成他们的工作。对他们而言，常见的繁琐任务包括：部署代码，创建变更请求，加强基础设施，为安全测试调研工具，或者建立一个新的组件并集成到现有平台中。优先考虑开发者体验的组织有机会在以下几个方面得到改善：
吸引和保留人才
最棒的工程师希望为最棒的科技公司工作，不仅因为这是个大品牌，还因为它们有强大的科技文化和高员工满意度。在这样的组织里，开发者得以做他们最擅长的事：用最先进的工具打造优秀的软件，同时避免官僚主义和不增值的工作。
生产力和节约成本
如果减少开发者花在处理模板事项和寻找工作所需资源上的时间，那他们把想法变成解决客户问题的代码的时间就可以从几个月缩短到几分钟。这种生产力的提高需要对开发者体验进行有针对性的投资，但这种支出具有很高的投资回报率：在一个有 500 名开发者的群体中，如果每人每天少浪费 5 分钟，节约下的时间完全可以支持一个从事标准化工作团队了。
一致性和质量
标准化和产品化整个开发工具栈的有助于更好的开发者体验，这也能提高产品的质量，因为在优秀工具的基础上建立伟大的东西要比用平庸的工具容易得多。此外，容易找到、使用和集成的工具让开发者更容易专注于真正重要的东西。
安全和合规
把安全和合规纳入开发流程，所有的合规都已准备就绪了，这可以大大减少团队在常规工作、满足审计、安全和风险要求上花的精力。比如把安全测试归为公司范围 CI/CD 的一部分，或者默认把合规性政策嵌入到所有云环境中。此外，整个组织的合规性程序应该是标准化的，而不是随着每个团队的认知和喜好而变化。
速度
通过减少团队之间的交接和协调，对质检（如测试、代码质量和控制）的早期反馈消除返工，以及完全自动化的发布路径，开发者可以更快地覆盖更多的领域，组织也能够实现一天多次部署，而不是几周或几个月一次。
开发者体验应有的样子
优秀的开发者体验可以通过一个平台来实现，它要在几个要素上满足开发者的需求：
随时可用的平台、基础设施和开发工具
包括结构化和清晰的文档，如教程、演示环境和经过设计的学习路径。例如，通过一键式部署的快速自助上手，使开发者能够使用预先构建的组件创建新的实例，接收 API 密钥，并获得用户访问权，而无需邮箱、开会或等待时间。此外，工具和机器人可以自动完成标准化的任务，帮助开发者将代码部署到生产环境。
一站式满足所有开发者需求
在许多组织中，开发者得在 20 种不同的工具中筛选以找到他们需要的东西。一个中央开发者体验平台可以在一个基于结构化服务目录的，类似应用商店的环境中，包括所有文档、API 和基础设施产品等元素。
降低复杂性
当开发者可以选择应用模式（如 API 微服务、前端工具），并在几分钟内完成部署（包括环境、预集成的 DevSecOps pipeline、监控以及自动化的变更和发布流程），他们可以避免在真正开始写代码前进行数周的重复性工作。这种标准化的技术栈通过设计实现了内置的安全和质量，并有可重复使用的组件。
资产透明
通过集中跟踪当前使用的软件、API 和基础设施服务的状态和版本可以实现资产透明。一个实时仪表盘可以促进遵守架构标准、安全控制和安全与审计问题的修补状态。机器人可以通过自动建议修改源代码来解决代码异味（Code smell，代码中的任何可能导致深层次问题的症状）补丁和库升级来帮忙。这些自动建议可以通过 PR 提交给开发者。
关键绩效指标（KPI）和 FinOps 仪表盘
自助式 onboard 可以为团队提供标准化的仪表盘，以衡量和比较他们的 KPI，如速度、技术债务、错误率、MTTR（平均修复时间）和基础设施成本。公司范围使用的标准工具，如 backlog, pipeline 和监控工具，可以自动提取这些指标。
开发者体验实践
一家领先的 SaaS 供应商经历了数年，通过 DevSecOps、混合云和 SRE 转型为了技术创新者。过去，为了通过 CI/CD 交付代码，开发者需要花费自己 20% - 30% 的时间来整合不同的服务，如防火墙变更、域名系统（DNS）和安全访问，以实现端到端的测试环境，并协调多个手动步骤，比如变更的工单、审批和质检。CIO 发起了全面提高开发者体验的计划，建立了一个拥有产品经理的平台团队，为开发人员提供一个共同的、安全的 CI/CD 服务。一个一流的应用门户、多个 API 和 GitOps 使得这些服务得以实时提供。
通过一个结构化的开发者体验计划，这些服务被系统地推广给了 2000+ 名开发者采用。这种方法包括文化变革、内部资源贡献，以及通过游戏化，以数据驱动的方式了解各团队的采用速度。开发者体验计划的影响是巨大的：开发者的生产力提高了 10% - 20%，关键事件减少了 20%，安全漏洞减少了 15% - 20%。此外，这些服务在用户满意度方面得到了开发者打的高分。
十项原则确保优秀开发者体验
科技公司应将以下十项原则融入到加强开发者体验的工作中。
专注于用户
开发者体验平台的最重要客户是开发者。该平台需要提供一条黄金通道，而不是一个黄金笼子。开发者需要大量参与设计、功能的优先级和测试，以确保平台适合目的并能够完全自我服务。专注于创造一个可用的设计，解决开发者的真正需求，可以使一切变得不同。
像对待产品一样对待平台
建立一个小的团队，让他们负责开发者体验平台，并改进它，确保它是面对用户的，满足开发者的需求。
分散化的贡献模式
一个完全拥有开发权的中央团队是无法规模化的，它也无法让组织从企业中获得最好的资源。负责平台的团队需要确保贡献模式是分散、持续的开发，每个人都可以分享插件并提出修改意见，就像开源模式一样（不过是在组织内部）。
将成功定义为使用
衡量成功的一个关键指标是，一个组织是否有能力为平台带来流量，并吸引开发者每天使用它。这需要仔细规划和实现功能；强调变化管理，包括最小可行产品（MVP）；跟踪使用情况，如其他团队的贡献和每日用户数量。简而言之，开发者使用这个平台，应该是因为他们想用，而不是因为他们必须用。
衡量影响
要清楚组织要改善什么，并从第一天起就衡量 KPI。例如，Salesforce 计算从想法到解决客户问题的代码所需时间（目标是 < 1hr），Spotify 衡量新开发者的生产力，例如，看到他们需要多长时间来完成他们的第 10 个 PR（目标是 < 20 天）。
从现有的能力中获得最大的收益
使用已经产品化并被组织采用的工具（如 backlog 管理、CI/CD 工具链、容器平台），让现有的团队通过插件追求与平台的整合。在适用的情况下，企业应该使用开源工具，并利用云原生。
从第一天起就建立能力
这不是为了吸引一批优秀的平台工程师来建立平台，而是为了建立一个高质量的平台工程能力。企业应设法确定精心策划的学习路径，例如，销售团队如何利用平台，供应商团队如何处理通过插件将其产品整合到平台中。
传播平台
促进工程文化和实践，以推进 DevOps 团队的采用。一些创造兴奋点的方式包括黑客松和演示日。此外，企业可以确定专门的倡导者，直到开发者体验平台成为组织文化的一部分。
管理变化
开发者体验不仅仅是技术，还包括支持平台采用和使用所需的所有先决条件。变革管理通常需要强有力的治理、协作和高绩效的工程文化，以及对运营模式的改变。
大处着眼，小处着手
为了确保平台从第一天起就能提供价值，并且能够扩展，MVP 的范围应该限制在第一个客户或用例。然而，可以在早期与利益相关者一起进行设计迭代，以验证技术选择的可行性。
实现更好的开发者体验是企业释放 IT 工程生产力的关键步骤。应用程序和基础设施堆栈的标准化）、极端的自动化以及满足所有开发者需求的一站式服务，有助于开发者团队以更快的速度交付高质量的软件。