研发质量管理指标都有哪些？

研发质量管理指标可以根据不同的维度进行分类。

在《代码大全》中，软件质量被分为外部质量和内部质量。外部质量包括易用性等，内部质量则涵盖了代码质量等。此外，在管理实践中，我们常用RAM（可靠性、可用性和可维护性）评估软件交付性能。

1. 可靠性（Reliability）：系统无故障运行的能力，即使出现软硬件故障、人为错误等问题，系统仍能正常提供正确服务而不发生服务中断的概率。它与故障率、容错率、避错力、冗余度等紧密相关。常见的软件可靠性度量指标包括可靠度、失效率、MTBF 和 MTTF 等。

2. 可用性（Availability）：在一定时间内，系统能够持续且正确提供符合期望水准的服务而不发生故障和中断的概率，通常用 SLA（服务级别协议）来表示。系统可用性可以用系统可用时间占总服务时间的百分比计算得出。

3. 可维护性（Maintainability）：包含可修复性和可改进性两个方面。前者是指在系统发生故障后，不同人员高效修复故障，使之恢复正常运行状态的难易程度，而后者表示当需求或环境变化时，系统接受功能改进或增加新功能的可能性。

对于如何确定MTBF和MTTR的优先级，可以根据可用性公式MTBF / (MTBF + MTTR)进行计算，并了解量化指标的预期增量。

01 

Mean Time To ALL

「MT」是 Mean Time 的缩写，意为平均时间，「MT 家族」则是 LigaAI 对以「MT」开头的一系列量化指标的戏称。

最常用于跟踪研发质量的两个 MT 指标分别是 MTTR 和 MTBF。近几年，随着精细化研发管理需求的攀升，行业也出现了 MTTD、MTTA、MTRS、MTTI 等细分管理指标，旨在帮助技术团队更好地了解生产事件发生的频率以及团队的恢复速度。

02 

共识在前，度量在后

在使用「MT 家族」度量质量水平之前，研发团队需要先就两个基础问题达成共识。

• 如何计算系统的总服务时长？

• 如何定义系统的可用时间（Uptime）和不可用时间（Downtime）？

明确第一个问题有助于规范讨论对象。系统的服务周期是多长？系统维护升级或提前告知的主动停机等特殊事件应否计入服务时长？研发团队应就以上问题达成一致，才能辅助更准确的度量和管理。

讨论第二个问题的意义在于建立内部一致的判断标准。什么样的事件属于完全中断事件？在部分中断事件中，多大程度的阻碍或多大影响范围的故障可以被定义为「系统不可用」？可正常运行但不符合预期水平的系统是否处在可用状态？

如果能将事件的具体量值和标准讨论并确定下来，研发效能管理或许会有一个更加清晰的视图。

03

「MT 家族」全员辨析

有了清晰的定义后，便可以开始今天的「认脸仪式」。下面是单个生产事件从故障发生到修复完成的简要示意图，根据起止时间点的不同，我们将获得若干个 MT 指标。

温馨提示：研发效能管理下的「MT 指标」或与其他领域的定义有所不同。

「MT 家族」一览

速率、质量和价值是研发效能管理的三驾马车。而相较速率而言，研发质量管理对团队共识的要求更高，因为我们需要通过集思广益，描绘一个线条干净、指标区隔清晰的质量评估视图，以进一步支持无歧义的指标量化管理；否则，研发效能管理最终又会回到让人头疼的「定义讨论会」。