测量应用程序稳定性以减少技术负担

在快速发展的软件和应用程序开发世界中，现实不可避免地存在着真正的错误，即使您尝试尽可能地减少错误，您最终还是会忽略其中的一些错误，以便更快地将您的应用程序或新功能推向市场。

这个概念称为技术债务。对于开发人员来说，每个人都已成为事实，他们了解他们的日常工作是如何导致该问题的。每当产品团队向市场推出新功能或希望对代码进行增量更改以进行开发时，开发人员便会意识到这一点。客户满意技术债务增加当软件框架和语言无法及时升级时，情况同样如此，因为高管们不想减慢开发速度

即使听起来有问题，技术债务也不总是很坏在某些方面它就像金融债务您可能需要短期承担债务，但是如果您长期让它长期搁置，则会导致软件较弱的主要问题。建立起来会减慢代码库中新产品工作的创建和维护

当这种情况发生时，这会给开发人员造成巨大的情感阻力，为什么？因为开发人员通常不具备充分的能力来解释技术债务的影响，并且难以获得更广泛的组织支持来解决此问题，因此，这形成了一个恶性循环，导致沮丧感日益加剧生产力和脱离项目

通常，技术债务被视为一种工程问题，阻碍了诸如建立新功能和取悦客户之类的赚钱活动。开发人员很少能成功赢得部门外部的拥护者，因为他们缺乏正确的工具来证明技术债务造成的问题

专注于测量稳定性

通过将稳定性概念引入对话中，开发人员可以提高对技术债务的认识并扩大与技术债务的对话组织必须致力于在提供可靠的产品路线图与维护健康且不断发展的代码库之间取得平衡，如果工程应用程序和产品无法实现平衡团队没有方法来公开，定期地讨论并就技术债务的影响达成协议

影响显而易见，因为技术债务是代码库中的可测量阻力，并且通过测量技术债务，您可以确定软件的稳定性

评估稳定性很像基础架构和运营团队如何依靠五个九来跟踪可用性度量正常运行时间并符合SLA，可以通过使用实时错误率和会话数据来确定每个版本中成功的用户交互百分比来计算软件稳定性。充当稳定性得分，以证明每个软件版本的稳定性

简而言之，当客户享受与应用程序的无错误交互时，稳定性分数很高如果错误导致中断或崩溃，则稳定性分数很低

从技术债务到业务价值

客户对无法正常运行的软件没有耐心，实际上只会在继续运行之前重试一次或两次应用程序。稳定性评分可直接洞悉错误的实际影响，而用户体验组织可以更好地了解减少技术债务的方式提升业务价值

更重要的是，可衡量的结果消除了仅由工程团队承担的技术债务负担。现在，这已成为整个组织可以定期集体查看和处理的指标

当跨职能团队以相同的语言衡量和沟通技术债务时，他们可以确定何时以及如何解决技术债务这是建立您的组织方法时应问的一些问题

我们的目标稳定性是多少
我们对高于目标的每个版本的稳定性得分是多少
如果有任何稳定性得分低于我们的目标，则首先修复哪些漏洞最有意义
我们可以为将来的版本切实地设置哪些目标稳定性分数？我们先修复会首先影响关键客户的错误，还是专注于影响许多客户的错误
多少个错误就是太多的错误

当使用稳定性评分时，这些问题成为讨论的要点，而不是沮丧的源头，通过重新设计对话团队，他们不再为烦恼的客户的下行保护而感叹，而是集中精力更快地开发功能并消除技术债务带来的麻烦。作为关键绩效指标（KPI），可通过稳定性得分将技术债务纳入工程团队的目标，从而从上到下建立问责制

稳定并解决问题不是技术债务问题，而是何时
最古老的之一软件开发问题是我们应该修复错误还是构建新功能？通过提供度量标准和分析功能的工具来帮助进行稳定性管理和错误监视的组织，企业可以更轻松地确定其重点，以便在推进软件的同时实现业务目标

错误是创新的结果要继续前进，您需要创建许多错误，但是您还需要采用适当的方法来及时解决错误的存在。毕竟，问题永远不是技术债务是否会影响您的软件，而是何时以及稳定性得分提供快速简便的答案的严重程度

组织中的每个人都可以根据业务需求，产品需求和客户需求来建立技术债务。稳定性评分使整个组织可以共同承担决定何时解决技术债务的责任。