原文：
towardsdatascience.com/measuring-the-cost-of-production-issues-on-development-teams-5efcd13bc9c7?source=collection_archive---------8-----------------------#2024-12-11
降低对质量的优先级会牺牲软件的稳定性和速度，从而导致昂贵的问题。而投资质量则能提升速度和成果。
https://medium.com/@davettran13?source=post_page---byline--5efcd13bc9c7--------------------------------https://towardsdatascience.com/?source=post_page---byline--5efcd13bc9c7-------------------------------- David Tran
·发布于 Towards Data Science ·8 分钟阅读·2024 年 12 月 11 日
–
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/5b74a24780110b6aa90f8e6b380af5ff.png
图像由作者提供。（AI 生成，使用 Midjourney）
投资软件质量往往说起来容易做起来难。尽管许多工程经理表示他们致力于高质量的软件，但他们通常对将大量资源投入到以质量为重点的计划中持谨慎态度。在紧迫的截止日期和相互竞争的优先事项面前，领导者经常面临如何分配团队时间和精力的艰难抉择。因此，质量方面的投资往往是第一个被削减的项目。
在任何工程组织中，投资质量与优先考虑速度之间的紧张关系都至关重要，尤其是在数据科学和机器学习项目中，其中交付结果是重中之重。与传统的软件开发不同，机器学习系统通常需要持续更新，以保持模型性能、适应不断变化的数据分布并集成新功能。机器学习流水线中的生产问题——如数据质量问题、模型漂移或部署失败——可能会扰乱这些工作流程，并对业务成果产生连锁反应。在机器学习团队中，平衡实验和部署的速度与严格的质量保证至关重要，只有这样才能交付可靠、高效的模型。通过应用一种结构化的、科学的方法来量化生产问题的成本，正如本文中所述，机器学习团队可以在质量改进的投资与优化开发速度之间做出明智的决策。
质量往往面临一个强大的对手：速度。随着业务目标和关键功能交付压力的增加，证明任何非直接提升速度的做法变得越来越具有挑战性。
推动产出。许多团队将非编码活动减少到最低限度，专注于单元测试，同时降低集成测试的优先级，推迟技术改进，并依赖可观察性工具来捕捉生产问题——希望只在问题出现时再进行处理。
平衡速度和质量很少是一个简单的选择，这篇文章也没有打算简化这一点。然而，领导者常常忽视的是，速度和质量是密切相关的。通过降低改善软件质量的优先级，团队最终可能会导致发布的内容既充满缺陷又很慢。快速推出更多功能所带来的任何收益
生产力可能迅速衰退，因为维护问题和持续出现的故障最终会削弱团队的速度。
只有通过了解质量对速度的全面影响，以及质量措施的预期投资回报率，领导者才能做出明智的决策，以平衡团队的工作负载。
在这篇文章中，我们将尝试提供一个模型，用来衡量在提高发布质量的两个方面上的投资回报率（ROI）：减少生产问题的数量，以及减少团队在问题发生时花费的时间。
避免缺陷，指的是那些进入生产环境的漏洞。
防止回归可能是减少生产问题对团队负担的最直接、最上游的措施。那些从未发生的问题不会拖累团队，造成中断，或威胁到业务的持续性。
尽管好处可能非常吸引人，但在某个拐点之后，防止代码出现问题的做法可能会导致发布速度的急剧放缓。理论上，团队可以将所需的代码审查次数增加三倍，将测试的投资增加三倍，并建立一个严格的负载测试装置。这样做可以防止更多的问题，但也会让发布新内容变得极为缓慢。
因此，为了证明投资于防止回归的任何努力是值得的，我们需要更好地理解其投资回报率。我们可以尝试估算回归减少 1%的成本节省对整个团队表现的影响，从而开始建立一个框架，帮助我们平衡质量投资。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/118bef0e741f2de408ed4b4313770477.png
作者提供的图片。
防止问题的直接收益首先体现在团队处理这些问题所花费的时间上。研究表明，团队目前花费的时间中，有 20%到 40%用于处理生产问题——这对生产力是一个巨大的拖累。
投资于防止问题的好处是什么？通过简单的数学计算，我们可以开始估算在开发过程的早期阶段防止每个问题所带来的生产力提升：
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/da0f8a918487dbdfad1c8fef0248b316.png
作者提供的图片。
其中：
Tsaved 是通过问题预防所节省的时间。
Tissues是目前用于处理生产问题的时间。
P是可以预防的生产问题的百分比。
该框架有助于评估工程投资的成本与价值。例如，一位经理指派两名开发人员花费一周时间使用可观测性数据分析性能问题。他们的努力将生产问题减少了 10%。
在一个 100 名开发人员的团队中，如果 40%的时间用于问题解决，这将转化为 4%的容量增益，再加上通过减少上下文切换带来的 1.6%。通过回收 5.6%的容量，这项投资证明是值得的，展示了这种方法如何指导实际决策。
很容易看到，预防每一个 1%的生产回归问题对团队工作速度的直接影响。这代表了团队不需要执行的生产回归工作。下面的表格可以通过插入一些值来提供一些背景信息：
根据这些数据，举个例子，对于一个将25%的时间花费在处理生产问题的团队，每1%的改善带来的直接团队资源增益将是0.25%。如果团队能够预防 20%的生产问题，那么这意味着会有**5%**的资源回到工程团队。虽然这可能听起来不是一个足够大的数值，但还有其他与问题相关的成本可以优化，从而带来更大的影响。
平均修复时间（MTTR）：减少因问题解决而浪费的时间。
在之前的示例中，我们讨论了通过预防问题所获得的生产力提升。那么，对于那些无法避免的问题呢？虽然一些漏洞是不可避免的，但我们仍然可以通过减少解决问题所需的时间来最小化它们对团队生产力的影响——这被称为平均修复时间（MTTR）。
通常，解决一个 bug 需要几个阶段：
问题分类/评估：团队集合相关的主题专家来确定问题的严重性和紧急性。
调查/根本原因分析（RCA）：开发人员深入研究问题，以识别根本原因，通常是最耗时的阶段。
修复/解决：团队实施修复。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/1b7f382517de07c70a93bcfd2cb88ebf.png
图片来自作者。
在这些阶段中，调查阶段通常代表了节省时间的最大机会。通过采用更高效的追踪、调试和缺陷分析工具，团队可以简化他们的根本原因分析（RCA）工作，显著减少 MTTR，从而提升生产力。
在问题分类阶段，团队可能会邀请主题专家来评估一个问题是否应该进入待办事项列表，并确定其紧急性。接下来是调查和根本原因分析（RCA）阶段，开发人员会深入研究问题。最后，修复阶段涉及编写代码来解决问题。
有趣的是，前两个阶段，尤其是调查和根本原因分析（RCA），通常占总解决时间的 30%到 50%。这一阶段具有最大的优化潜力，因为关键在于改进现有信息的分析方式。
为了衡量改善调查时间对团队速度的影响，我们可以计算团队在每个问题上所花费的时间百分比，并减少调查阶段的比例成本。这通常可以通过采用更好的跟踪、调试和缺陷分析工具来实现。我们将类似的逻辑应用于问题预防的评估，以便了解每减少一个百分比的调查时间，团队可以获得多少生产力提升。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/2dbea2d7d91f676553fb4737bbbd73a1.png
图片来自作者。
Tsaved：节省的团队时间百分比R：调查时间的减少T_investigation：每个问题上用于调查的时间T_issues：处理生产问题所花费的时间百分比
我们可以测试相对于T_investigation和T_issues变量，性能提升的表现。我们将计算每减少 1%调查时间R的边际收益。
随着这些数字的积累，团队可以获得显著的提升。如果我们能够将调查时间减少 40%，例如在一个团队中，该团队的 25%时间用于处理生产问题，那么我们将重新夺回该团队生产力的 4%。
结合这两项好处
考虑到这两个优化领域，我们可以创建一个统一的公式来衡量同时优化问题预防和团队在无法预防问题时所花费的时间的综合效果。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/edd6a3b2f4534c8660b9c992a2115c30.png
图片来自作者。
回到我们举的例子，假设该团队将 25%的时间用于处理生产问题，并且每个问题的解决时间中有 40%用于调查。如果能将调查时间减少 40%并且预防 20%的问题，那么团队的生产力将提升 8.1%。然而，我们的工作远未完成。
考虑到上下文切换的隐性成本
以上每一种简单的计算都没有考虑到一个主要的惩罚因素——由于未经计划的生产问题导致工作的中断——即上下文切换（CS）。有大量研究反复表明，上下文切换是昂贵的。多昂贵呢？由于中断和在多个任务之间切换，额外工作量的惩罚在 20%到 70%之间。在减少中断工作时间的同时，我们也能减少上下文切换的惩罚。
我们最初的公式没有考虑到这一重要变量。一个简单但天真的方法是假设任何未计划的工作处理生产问题都会对已经分配给团队的待办事项造成相等的上下文切换惩罚。如果我们能够节省 8%的团队效率，那应该会导致上下文切换的惩罚也相应减少，尤其是对于原定任务的完成。在减少 8%的未计划工作时，我们也就减少了相应的 8%计划工作上的上下文切换惩罚。
让我们将这一点加到我们的方程式中：
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b8c1ea554c303538191baaf50f9caa77.png
图片由作者提供。
继续我们的例子，假设的组织会发现他们的改进实际影响现在略超过 11%。对于一个 80 人规模的开发团队来说，这相当于有 8 名开发人员可以腾出时间做其他事情，为积压工作做出贡献。
使用 ROI 计算器
为了简化操作，我已将上述所有公式上传为一个简单的 HTML 计算器，你可以在这里访问：
ROI 计算器
衡量 ROI 是关键
生产问题很昂贵，但一个清晰的 ROI 框架有助于量化质量改进的影响。通过优化分诊和调查来减少平均修复时间（MTTR）可以提高团队生产力。例如，调查时间减少 40%
恢复了 4%的生产力，并降低了上下文切换的隐性成本。
使用 ROI 计算器评估优质投资，并做出数据驱动的决策。点击这里查看如何通过有针对性的改进提高效率。
参考文献：
1. 开发人员实际编写代码的时间有多少？
2. 如何更快编写优质软件（我们花费 90%的时间进行调试）
3. 调查：修复漏洞挤占开发时间
4. 上下文切换的真实成本
