DPE洞察｜亚马逊应对大规模开发人员体验挑战带来的启示

最近关注到Insider发布了一篇关于亚马逊创建ASBX团队以应对开发人员体验的文章，相信这也是很多开发团队对开发体验投资不足会面临的问题和挑战。希望对大家带来一些启示。如果你发现你们已经在面临这种情况，已经不得不处理这些后果，该怎么应对呢？以及如何避免在前期陷入这种局面。

（原文：Insider - After 28 years,"Day 2" finally arrives at Amazon）

在最近的一篇文章中（2022年9月），Insider的Eugene Kim报道说，亚马逊首席执行官Andy Jassy正试图通过一个名为亚马逊软件建设体验（ASBX）的新部门来修复崩溃的工程文化。ASBX的任务是解决该公司受挫的开发人员提出的 "基础性痛点"。

尽管亚马逊试图将这个新团队作为 "帮助亚马逊成为全球最好的软件建设者雇主 "的积极步骤来推销，但内部“抱怨冷漠的工程文化”和“官僚主义的低效率”情况早已存在。

据Insider消息，自启动以来，ASBX团队已经发展到400多名员工，致力于代码自动化，改进开发者工具，以及加强教程和安全基础设施。此外，其章程是改善整个亚马逊的软件建设者的体验。而它最主要的职能是聚焦于将开发人员报告的一些基础性痛点，如代码如何进行日常管理和部署以及操作工具的可用性。

亚马逊的开发者之痛

最近的内部调查由Insider总结量化了一些开发人员的痛苦和流程浪费：

· 34%的工程师说他们每周花4到8个小时做无差别（即不增值）工作

· 10-20%的工程时间是用来做与构建新产品无关的事情

·30%的工程时间用于执行"重复性任务"

此外，亚马逊内部人士直接表达了他们对开发工具的失望。开发人员分享如下：

· 内部工具往往与一些开源工具不兼容，而且这些工具会拖累开发人员。更糟糕的是，这已经直接与减员联系在一起。

· 许多工具都是过时的。开发团队希望使用更先进的技术，但往往不能，因为工程团队与专门被授权购买软件的管理团队相距太远。

· 没有可视化工具可以直接测量开发人员的痛点（例如反馈周期时间），特别是在本地构建方面。

· 关于构建性能和失败率的趋势数据没有得到一致的跟踪，所以没有衡量痛点的基线，也没有办法知道关键的生产力和开发者体验指标是在改善还是在恶化。

不作为的代价（CoI）

是什么样的不良开发人员体验带来的后果促使亚马逊做出反应的？

· 许多负责公司早期发展的高管已经转到较小的初创公司或竞争对手那里。

· 以速度和内部创业精神著称的亚马逊文化正在被侵蚀。

· 如果DevX在早期就被确定为基础性的优先事项，那么大量的补救投资，包括组建新的400人的组织单位来解决这个问题，是可以避免的

· 浪费在执行普通的人工任务上的时间挤占了核心的生产性编码时间，包括用于创造性和创新性的时间。

· 亚马逊的CoI（不作为的成本）高达千万美元，至少百万美元

通往DevX的“救赎”之路

看起来亚马逊在解决他们的挑战方面进展顺利。他们迈出了第一步，和以往一样，就是承认有问题。但亚马逊也清楚地看到了将目前的弱点变成优势的机会。考虑到这一目标，他们采取了下一步措施，即确保最高级别的管理层支持和赞助，以及必要的资源。Jassy已经亲自看到了这一切。最后一步是制定一个计划并执行它。ASBX团队的计划包括一个专门用于 "构建工具 "的单元。这很重要，因为构建过程通常是开发者痛苦和挫折的主要来源。

面对这些问题和挑战，作为DPE领域倡导者，我们能给的最好建议是，让开发者生产力工程（DPE）的实践成为改进 "构建工具 "计划的更核心的部分。为什么？这将提供一个硬性的投资回报率和快速的胜利，以解决上述调查中量化的开发者生产力痛点和流程浪费。我们也会鼓励把工具的决定权和购买权推给那些每天直接感受到工具不足之苦的团队。

DPE工具通过最大限度地减少亚马逊所说的 "无差别的工作"，并最大限度地保证开发人员将时间花在创新和编写有用的代码等有差别的工作上，从而改善开发人员的体验。通过使用DPE加速技术加快构建和测试，开发人员可以花更多的时间高效的工作，因为他们减少了因不必要的缓慢的反馈周期造成的闲置时间。此外，DPE流程和故障分析工具通过提供可操作的洞察数据，快速确定问题的根源，使故障排除更加高效。

另外，DPE工具可以使构建和测试记录和趋势数据更加可视化。这使开发人员和构建工程师能够采取积极措施，提前发现问题，从一开始就防止推动无差别工作的构建过程事件发生。

聪明的投资回报率

仅仅是加速技术通常就能让开发人员每周至少损失一天的生产力的到节省，从而用于等待构建和测试反馈周期的完成。

DPE的投资回报率计算很简单，也很有说服力。只需将缩短构建时间所节省的时间（例如，从10分钟的基线到新的平均构建时间2分钟，或者节省8分钟），乘以每位开发人员每年结合本地和CI构建的平均构建数量。然后用每个开发人员每年节省的总时间，乘以开发人员的总数，得到整个开发团队每年节省的时间（分钟）。假设没有100%的时间被浪费（我们的客户通常保守地认为是80%），用这个因素调整节省的总时间，并将结果乘以工程分钟的成本。这就是你每年因加快构建和测试反馈周期而节省的总时间。

即使对于规模不如亚马逊的中等规模的开发团队来说，运营成本的节省也可以迅速达到千万美元。在此基础上，最大限度地减少修复构建和测试故障的平均时间，进一步提高你的投资回报率。

结 语

显而易见，亚马逊所面临的问题在其他公司页并不少见。我们鼓励企业了解更多关于开发者生产力工程的情况，以解决中等和大规模企业DevX危机，并将DPE 作为企业的竞争力优势。如果你面临类似的挑战，并想了解更多关于提高开发人员的生产力和大规模的开发人员体验，请点击“阅读原文”或者扫描下方二维码获取《开发人员生产力工程白皮书》。对于那些希望主动将开发者生产力和体验的实践嵌入其现有流程的开发团队来说，这也是一个很好的资源。通过从现在开始投资于开发者生产力流程和工具，企业可以避免支付更高的不作为成本。（关注“Gradle Enterprise”公众号或前往中文官网​​​​​​​了解更多）

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！