开发者90%时间耗在现有代码管理和非编码任务！集成DORA、SPACE等指标，结合Jira、SDLC工具数据，通过内部开发者门户如Port的Engineering360，整合MTTR、部署频率等指标和开发者情绪，利用AI驱动的自助服务操作，实现持续改进和ROI提升，解决工具蔓延问题。
译自：Optimizing the 90%: Where Dev Time Really Gets Stuck
作者：Sooraj Shah
人们非常关注开发者编写的新代码：如何使用 AI 来加速它，如何管理 AI 工具 以确保它们不会导致混乱，以及开发者的生产力能提高多少？
但现实情况是，编写新代码只占开发者全部时间的一小部分。根据 Gartner 最新发布的关于 AI 开发者工具的新兴技术报告，开发者只有 10% 的时间用于为新应用程序编写新代码。
那么所有其他时间呢？开发者剩余 90% 的时间包括管理现有代码（30%）以及非编码任务，如设计、架构、项目规划和文档编写。在这一大块时间中，有很大的空间可以减少瓶颈。
但是，由于对代码生成投入了如此多的关注，工程领导者可能会忽略一些明显的改进机会。以下是许多工程组织中存在的三个瓶颈示例，这些瓶颈是可以克服的。
虽然像 DORA 和 SPACE 这样的现有框架通常在软件工程智能平台中提供，并且可以为生产力提供有价值的见解，但它们并不能说明全部情况，而且通常是从 Jira 和源代码控制工具中提取的初步指标。例如，基于标准的工程指标可以帮助管理者密切关注成本、安全漏洞、SLO（服务级别协议）合规性、所有权、文档、新工具或实践的采用、生产准备情况等等。
此外，还有许多其他工程指标可以作为 DORA 的代理指标，但这些指标分散在软件开发生命周期 (SDLC) 中使用的许多工具中。它们既不统一，也不集中在一个地方。虽然它们各自都可以提供有价值的见解，但尝试整合、跟踪和理解它们可能会很困难。而且，通常整合方法意味着工程团队不信任数据。
所有指标缺乏集成意味着，虽然你可以看到你的变更失败率或平均恢复时间 (MTTR) 很高，但你无法理解原因，这意味着很难进行调整。
工程领导者倾向于偏爱系统指标，因为在担任领导职务之前，他们是经常通过日志和遥测数据监控系统的工程师。但是，相同的方法不能应用于衡量人。
这部分是因为系统数据需要先清理才能使用。从管道数据中测量 CI 构建时间听起来很简单，但组织仍然必须过滤后台任务并调整并行性，然后才能获得可靠的指标。系统指标也无法捕捉工程工作的人性化一面。例如，了解开发者是否能够保持心流状态，以便他们能够完成最重要的工作。
传统的工程指标仍然可以被操控。例如，衡量部署频率可能会激励团队通过仅部署简单的、影响较小的更改或将较大的更新分解为较小的、意义较小的更新来操控数据，仅仅是为了提高部署计数，而不是专注于交付真正的价值或提高稳定性。
填补这些空白的一种方法是通过调查。调查 可以帮助你了解团队士气、满意度和摩擦点，这些在系统数据中不会显示出来。虽然指标告诉你“是什么”，但调查可以帮助你回答“为什么”，有时还可以回答“如何”。
工程领导者可能认为开发者调查平台可以解决这个问题，并且有一些很棒的选择，但它们通常不会与开发者工作的所有工具集成（例如，Microsoft Azure DevOps）。
此外，这些工具通常具有陡峭的学习曲线，需要额外的时间和资源才能有效地使用。使用专门的平台还会为工程师增加另一种工具，而工程师平均每天使用 7.4 种工具来完成日常运营任务。开发者工具的蔓延导致 75% 的开发者每周损失 6 到 15 个小时。
如果你已经有了指标，你仍然需要为你的组织理解它们的意义。但是你可能会遇到一些难题：
- 我该怎么做才能改进这些指标？
- 我可以采取哪些行动？
- 如何跟踪这些行动以及任何改进尝试的进度？
- 如何就此进行报告，以及向领导层报告任何变更的投资回报率 (ROI)？
这意味着首先能够整合指标并将其与情绪进行交叉引用，然后能够决定如何在你的流程、工具和文化中进行更改。这个想法是建立一个持续改进的循环。
来源: Port
来源: Port
通过内部开发者门户整合你的软件工程智能指标、基于标准的指标以及来自开发者调查的情绪，使你能够更好地了解 SDLC 的不同领域如何相互影响。不同之处在于，所有你需要的信息和你能够采取的所有行动都内置在你的开发者门户中，而不是被安置在单独的仪表板或一次性的调查报告中。
例如，你将能够在你的门户中看到以下所有内容之间的相关性：
- 部署频率的降低
- 通过监控 MTTR 发现的事件激增
- 中断和部署失败的次数
- 处于打开状态与已解决状态的事件数量
在本例中，门户还可以提供更多上下文：你最近的部署是否导致了事件的激增？
可以进行预先构建的调查（尤其是在门户中也是可配置和可共享的调查），以更好地了解：
- 工程师是否因为必须专注于事件管理而被从他们的路线图任务（包括部署）中拉走。
- 这占用了多少编码时间。
- 哪些步骤导致了特定的时间消耗。
使用指标和情绪数据的组合，你可以启动一个计划来改进事件管理方法，如下所示：
- 立即为响应团队创建一个 Slack 频道。
- 在软件目录中轻松找到有关谁在待命、服务所有者以及服务是否得到正确监控的信息。
- 执行 Day 2 operations使用自助服务操作，例如请求访问集群的权限、回滚服务、扩展云资源以及切换功能标志。
此外，可以实施成熟度记分卡，以确保遵守最佳实践（例如拥有正确数量的 ReplicaSet），以预防和减少事件的数量。
然后，你可以使用门户中的专用仪表板跟踪这些改进和自动化是否在事件管理响应 (MTTR) 和部署频率方面有所作为。
如果影响体现在 MTTR 中，而不是部署频率中，那么可能值得研究如何简化部署频率本身，例如通过创建自助服务操作来搭建新服务、启动开发环境或发送提醒以审查拉取请求。
关键的区别在于，你可以将所有指标集中在一个地方，检查相关性，采取行动，定制工作流程并跟踪进度，而不是采用最全面的调查工具或最先进的仪表板，从而将重点从指标可见性转移到真正的改进。
如果你正在寻找一种克服这些瓶颈的方法，请查看 Port 的 Engineering360，这是一种将 DORA 指标和开发者情绪整合到你的门户中的工具。