指标-项目运行状况指标

在IT中，一个健康的项目是一种系统或服务，一方面，它是高质量的，也就是说，它可以满足要求并且用户喜欢它。 另一方面，它可以获利，因为企业始终真正想赚钱。 没有质量和业务的捆绑，就不会有任何好处。



根据削减，Ruslan Ostropolsky将为您提供有关IT系统运行状况指标的所有指标。 他将分析什么是指标，随着项目的发展它们如何变化，哪些指标最适合在哪个项目中使用。 解释质量和业务如何在指标方面互相帮助，以及为什么需要这种协作。


关于演讲者和公司： Ruslan Ostropolsky自2010年以来一直从事IT，主要关注领域是质量保证。 在过去的五年中，他一直在DocDoc公司工作，该公司致力于开发医疗Internet服务。 主要产品是与医生的在线约会，已有超过200万患者通过DocDoc签约了医生，此外还有一系列诊断，远程医疗和VHI保险。

当质量和业务不是朋友时

没有质量保证，从长远来看，企业将很难赚钱。 需要一堆质量和业务。 如果不是，则可能出现以下情况。

首先，有质量就是为了质量 ：在一个小型启动中使用所有已知类型的测试时。 您可以立即考虑在负载下进行自动化和测试，但是如果您超负荷使用，则该产品可能仍无法投入生产。 因此，您需要：

• 了解业务-目前最重要的是：赚钱，进入市场或迅速扩大规模。 业务任务是将这些目标转移给技术部门。
• 在正确的位置和正确的数量提供质量。 有时，您可以发布带有错误的发行版，但了解风险，因此，请考虑到这一点。

其次，还有另一种情况- 没有质量的生意 。 一个IT公司甚至可能有一个测试部门，但是如果QA是轻量级的或以猴子测试的形式存在，那么它会简单地消除回归并在此停止，那么这将不会有太大改善。

注意：质量检查并不是真正的测试，而是一种用于制造优质产品的通用公司级方法。

如何理解您是否正在开发高质量的产品？


客观评估需要显示以下指标：

• 问题的事实。 您基本上有问题，如果没有问题，则需要更仔细地寻找它们。 它们很可能在某个地方，只是您仍然看不到它们。
• 结果的事实。 创建项目是为了赚钱，进入市场，增加转化。 这些结果需要跟踪。
• 当前状态。 您在实现目标的过程中在哪里，当前有多少错误，可以冲刺，移动速度有多快。

如何选择指标

您可以根据三个原则选择指标。

哪里疼。 如果发生事件，则需要对其进行分解，对度量进行加权并查看痛苦：处理的方式，动态情况，错误是否已修复。


通过有针对性的方法，我们显然可以专注于目标，例如加速和自动化。 以前，我们的自动化测试需要两个小时。 我们在10分钟内设定了一个目标，并查看了指标以了解我们是否正在接近该值。


但是，如果度量标准与业务没有联系，只是技术性的，并且业务没有获得结果，就不可能获得健康的项目。 相反，如果没有错误，并且企业亏损，那么就会发生奇怪的事情。


重要的是要记住，项目有不同的业务和不同的阶段。 创业公司，成长中的公司或扩展项目需要不同的指标。 这就像疾病一样-如果您只是咳嗽，就可以测量温度，喝抗坏血酸，一切都会过去。 如果您怀疑患有肺炎，则需要拍照，检查和区别对待。

项目不同阶段的指标

我将告诉您，我们在创业初期就衡量了哪些指标，然后又开始增长和扩展。

创业公司

在此阶段，该产品还处于起步阶段，您正在检验一种假设，调查人们是否需要它。


在企业的启动阶段，重要的是尽快将构想交付给用户并进行验证。 也就是说，您需要衡量产品上市时间-向用户交付想法的速度（即生产，而不只是发布）和客户数量 。

在质量检查部分，我们只有3-5个指标：

• 战斗中的虫子数量；
• 发布的错误数量；
• 错误的严重性。

关于如何收集指标的问题的答案很简单：有手，就有Excel。 大约每月一次，将您的手放在数据表中，这应该足够了。

正在成长

在下一阶段，我们已经学会了站起来，走了一点。


业务需求在不断发展，衡量以下内容变得很重要：

• 交通量 当明确表明用户需要该产品时，会产生尽可能多的流量，例如，出现会员程序。
• 扩展 -从产品方面和开发方面都尽可能地增长。

质量检查已经越来越大：10-15个指标。 例如，如果在一家初创公司中我们根据自己的感受创建了产品，那么创始人说：“我想要一个蓝色按钮”，而每个人都这样做了，那么现在就有了第一个统计数据。 您可以通过A / B测试跳过功能，并记住要测量结果。

出现自动化 。 猴子测试不再足够了，投资扩展很有意义。 此时，将出现自动测试，这将有助于使回归测试更快。 因此，测量了发布测试的速度：证明有多少自动化是合理的。 自动化花费了六个月的时间，由于某种原因，发布速度没有加快，这令人遗憾。

还对发行量进行了测量，以查看例如是否不是15个开发人员，而是15个，但是由于某种原因，发行量并未增加。

为了在成长阶段收集指标，除了动手和Excel外，还会出现专门的系统。 系统是任何有助于创建产品的工具。 如果以前在Google文档中编写了相同的测试用例，则它们将显示在此处：

• 系统管理员，例如TestRail；
• Google Analytics（分析），用于收集用户数据；
• 报告门户，自动化的魅力。

该系统在其内部构建其他度量标准和报告。

胖子

我们进一步成长，“胖子长满了”-我们没有进入自己所坐的办公室，而是开始定期搬家。


对企业来说重要的是什么？

• LTV。 需要留住客户。 如果客户较早记录一次并离开，那么现在显然有必要保留他，以建立用户服务。
• 品牌/声誉。 如果以前联系DocDoc的人们可以认为这是一家诊所，那么现在他们知道他们正在提供帮助。
• 服务水平协议 随着人们开始不断使用服务，服务的可用性变得至关重要，因为任何停机时间都会直接影响金钱。
• 资料。 出现第一个数据，包括产品，技术数据和用户数据，这些数据必须能够处理和存储。 有一个安全问题。
• 转换次数 在扩展阶段，根本不会创建新产品，但是会改进所创建的产品。

质量检查已经包含大约30-50个指标。 我们测量：

• 负载：后端，服务器和前端，并位于不同的片中。
• 安全性
• 释放率。
• 自动化速度。
• 自动化稳定性：自动化的速度和稳定性直接影响发布的速度，因为在项目开发的当前阶段，手动回归并不重要。
• 自动化范围。

我们像以前一样收集数据，但是使用了更多的系统。

难点

一切都不会顺利进行，我们也不例外。 我会告诉您，项目发展到足够程度时，我们遇到了哪些困难。


有很多系统 ，需要以某种方式管理它们。 查看每个系统至少需要很多时间。

杂货店和技术店的方向越来越多 。 此外，每个方向的发展都不同，其中一些方向是作为初创公司推出的，将指标和质量保证都放在这些方向上是错误的。

流程变得更加复杂 ：如果之前有5个人参与该项目，那么很容易达成共识并采取相应的行动，现在我们需要监视流程。 例如，需要逐渐引入新人，否则他们将很难理解系统的累积数量。

数据和报告在服务中是唯一的。 这是因为存在许多系统，因此您需要观看所有系统。 每个服务都会生成自己的报告，您需要全部跟踪它们。 此外，为您自己配置报告变得越来越困难：您要么需要联系技术支持以获取新报告，要么尝试自己使用脚本进行配置。

而且，如果有大量数据，则Excel不会提供帮助 。 尤其是如果有数十个人开始处理一个文件，其中所有文件都按公式设置-某人进行了更改，则所有文件都崩溃了-他们将在一周内看到文件。

也许这就是分析师出现在公司中的方式-收集和维护统计信息和数据的特殊人员，因为合并需要太多时间。

当然，由于又有很多系统要相互关联，因此分析信息变得更加困难 。

对待悲伤

您可以去海边放松一下，再回来看看其他公司的经验。


合理的解决方案是根据数据将所有内容放在一起并将其转换为指标。

我们制定了以下标准：

• 自动收集，以便任何人都可以在任何地方装载任何东西。
• 实现各种数据表示。
• 应该有一堆系统：如果一半的数据来自Jira，一半的数据来自TestRail，则它们必须落入一个存钱罐，然后从中获得唯一的报告。
• 一切都应该易于管理且易于维护。 这意味着人们自己可以在系统的基础上构建必要的报告并对其进行支持。

仪表板

我们有很多仪表板，现在只有活跃的技术人员大约30名，总共大约100名。



仪表板的数据通常从任何地方收集。 事实证明，您可以从大画布上生成必要的报告。 以下是一些示例。

关键漏洞分解



在这里，我们测量并显示特定时期的错误数量以及它们的严重程度。 数据是从Jira提取的。 吉拉本人也许可以构建这样的报告，但是不是很方便的形式。

按自己的领域细分错误

在Jira中，您可以打包任何自定义字段，这些字段可以是分析数据，也可以加载到常规系统中。 例如，下面是组件错误。



团队，人员，方向都有相同的切入点。 这使您可以观看各种切片。

新漏洞和已关闭漏洞的比率

如果我们创建20个bug，并且仅关闭5个bug，那么在某些时候，我们将陷入其中。 因此，您需要遵循数字并努力使比率等于1。



这段时期的错误趋势

我们引入的便捷系统是我们上载了所有历史数据并可以查看动态。



在吉拉（Jira），这有点复杂。 一切都会自动为我们工作，您可以选择任何时间段，看看您是否能够改进某些方面，以及引入的流程和想法是否有效。

发现错误的阶段

如果以前我们只评估战斗中的错误，那么现在我们将努力确保战斗中根本没有错误，并且我们在不同的阶段构建切片：战斗，发布，测试，自动化，审查，需求。



自动化仪表板

对于自动测试，还有一个仪表板。 它非常大，因此下面是两个单独的片段。



它显示错过的错误数量。 如果您拥有90％的覆盖率，但实际上仅将一半的错误注释掉或跳过了，那么这非常关键，因为实际上只有50％的功能可以正常工作。

失败的原因相同：有多少测试崩溃。 我们通常会指出各种导致崩溃的原因：系统崩溃，错误崩溃，功能已更改。 另外，我们共享的崩溃完全取决于系统和环境，而崩溃完全基于测试。 首先是运营团队的工作，其次是自动化。

我们还将研究自动化范围。 我们从TestRial获得所有套件，我们还可以深入研究功能块，例如确定搜索是否覆盖了30％。



此外，有关状态削减的数据还反映在这里：

• 新增-新功能。
• 需要更正-您需要更新案例。
• 不需要-不想涵盖自动化。
• 完成-涵盖。

批评也有自己的切入点。

仪表板性能

我们正在Grafana中构建此仪表板，并通过API，前端，后端和服务器端分别加载指标。 有一块显示最新版本的当前片段。 因此，您可以进入每个指标并查看动态。



所有这些都与网站的不同功能和页面重叠。

继续前进

看来现在一切都很好：它收集自己，并在一个地方收集一堆指标。 您可以安全地继续前进。

但是在此过程中出现了新问题。 图太多了，因此很少有人看。 当有5个时间表时，它们每天都很容易检查。 随着他们的数量增加，每周一次的疗程获得了-也不错。 然后三天前突然出现了一个fakap，没有人注意到。 因此，反应变得很长，指标和仪表板变得过时了。 造成这种情况的原因有很多种，这些原因也需要能够解决。

我们需要制作汇总图 ：在10张图中，我们制作一张将显示这10张状态的图表 。此外，我们将主要指标拉高。 打开仪表板，立即查看所需的值，然后再查看其他所有值，这将更详细地显示指标。

我们共享：业务指标，流程指标，质量检查指标（Web /移动，手动/自动化，性能）。

这就是聚合图（NPS，CSAT）的外观。



最上方是与上一时期相比的值和增量。 在这种情况下，如果箭头为红色，则您需要做一些事情，至少要更详细地看一下图表。 如果箭头为绿色，则表示一切正常，您将无法响应。

此外，图形还可以降低到更低的水平 ，而不会移动到任何地方。



错误与允许错误的人（测试人员或开发人员）有关。 如果您单独单击某个测试器，则会在其上打开一个单独的表-用于执行任务的切片。

下一步是解决图形很少受到控制的问题。 即，我们将扩展使用数据和指标的方案：将通知添加到必要的指标。

警报

我们使用很多警报。 我将举例说明类别和具体情况：

• 性能表现
• 自动测试。 例如，如果错过的错误百分率太高，或者测试未涵盖太多的新功能。
• 传入的错误。 在我们公司，任何人都可以在票务系统中发现错误。 以前，在PM中伴随着一条消息，现在有一个通知新错误的渠道，此外，错误会自动依次分配给执行者。 指定的人必须解析该错误，否则该漫游器将每15分钟提醒一次。
• 测试速度/测试待定。 如果很明显一个人已经将自己埋葬在任务中-没关系，他会对其进行编码，进行审查，测试它-应该会发出警报：“您已经在执行三个任务，也许您已经埋葬了，寻求帮助。”
• 任务/团队存在缺陷。
• 审查测试用例。 这只是过程的自动化，以免手工完成。

警报示例

对于刻录的任务，机器人会写入任务编号，状态，优先级，已测试任务多长时间以及由谁进行测试。



通知以摘要形式列出，发给看自己有什么问题的个人。 这是TestRial发送的测试用例的警报示例。



它指示将哪些案件分配给谁，状态如何以及需要监视谁。

另一个示例是Yabeda机器人，它可以监视进程。



这是配置错误和任务链接过程所必需的。 分析该错误的开发人员必须找到我们错过该错误的任务，以进行进一步分析，以了解为什么我们错过了该错误。 这是对事件的分析，但有延迟。

您需要多少次警报以及多久一次？

如果会有很多警报，那么它们就会产生很大的压力。 因此，我们为自己设置了警报管理规则。

— . 500 , .

— . , , , - .

— . , : , , , . , , , .

: , . , , - , . , :

• — , .
• — , , . , , . .
• — , , , , .

, :

• — , , .
• / . , , .
• . , .
• . , . , . , , .

. , . . , , , , . , , : , .


, :

• . , , , . .

• . , , , . , 10 — .
• . , .

, , . . -, , , , , 15 , . -, , . . -, . , , , , , .

Online

. , . , . , .

QA

, QA .

: , , .

: , , .

:



— , X ( ), () (). , - , ( ) : , . , . , , . , , .

: — , , ( , , ).

: « ». , , , , . - . .

, , . , , . .

-

: , , . , .

: , , , .

, 10 , 500, . , .

. , , .



, , , . , , . «5 », .

, , , .

总结

— , . , . , . , , , — , .


:

• ;
• , ;
• , .

. , , , . .

— . , . , , - .

. , .

:

• ~ 50 QA 100 .
• ~ 30 .
• — , .
• .
• .
• QA must have.

我们的会议结合了开发高质量产品的所有方面，将于明年重生，它将摆脱RIT ++，成为一个独立的大型活动TechLead Conf。我们将很快在电报频道中宣布日期和位置，但是如果您凭自己的经验看到开发过程不是一组未连接的模块，并且希望共享建筑工程过程的解决方案，则无需等待公告即可申请报告。