效能度量 质量度量之 “三级指标体系”

Mr 老J · 2022年02月10日 · 最后由 CalvinXiong 回复于 2023年05月09日 · 37369 次阅读
本帖已被设为精华帖!

管理学大师彼得 - 德鲁克曾说过:无数据不管理。

数字是人们快速认知事物的一种有效方式。无论在生活还是工作,对事还是对人都息息相关。碰上难以的用数字描述事物或现象肯定是没有找对适用的指标和度量方式。尤其对于质量工程方面的工作,定量的呈现远比定性描述更有说服力。而 “三级指标体系” 就是在这一年的反复打磨中,逐渐清晰并成型的,能够将工程质量加以体系化度量的一种最佳实践。

为什么是三级?而不是四级或者更少?

通过一级指标,直观反馈在工程化过程中某个方面的水准,具有结果性质的指标,类似 “后视镜” 的作用,但也具有较大之后性且粒度较大;从而引入二级指标,对大颗粒度的一级指标进行拆解,分而治之以获取改善。由于粒度的均匀程度问题,需进一步纳入三级指标才具备可操作性,以便着手改善以最终影响到结果。通常情况下,三级指标即可起到有效的下钻分析并落入改进闭环的效果。

通过实践归纳,选取效率、质量、稳定、资源四个方面共同构建三级指标体系。四个方面的关系可描述为质量是立命之本,稳定是有效质量活动的自然结果;业务方期望的是有质量地(约束条件)快速交付,且尽可能少的资源投入,其中也隐含着对资源的高效利用的诉求。

简而言之就是 “多、快、好、省” 地把活干了。三级指标分别指的是:

  • 一级指标,即结果指标。起到 “后视镜” 的作用,有一定的延迟性。
  • 二级指标,即拆解指标/改善指标。对结果形成进行构成拆解或者直接可以作用以改善结果。
  • 三级指标,即改善指标。可以对应到一个或一组改进行为以获取对结果的部分改善。

下文针对上述四个方面一一展开相应三级指标构成、内在逻辑及应用说明。

一、效率

效率是工程团队与业务团队沟通的热点话题,也是工程团队被诟病的高频方面。从面向高效交付的质量保障工作为切口,进行应用说明。

效率方面,通过业务交付能力、计划保障能力以及过程协同能力自底向上逐级支撑与保障以实现高效的目的,也就是用数据呈现 “多” 与 “快”。

业务交付与响应,通过吞吐率这一相对值体现;绝对值方面采用总需求数对照观测,而需求上线率、需求分布体现的是对计划的保障能力。指标方面反映了业务方提了多少需求,排上了多少需求,排上了多少大需求,排上的按时完成了多少。

进而下钻到协同效率体现,其依赖于估时精准性,而过程中准时提测率作为契约支撑,自动化率以及工程配套可用率影响着测试执行效率。这趴指标侧重实施过程的能力说明,属于 “肌肉” 展示。解释了为什么能以及如何能保障效率。此处隐去了众多三级指标,以便清晰说明(下同)。

二、质量

软件的质量是开发出来的,程序(制品)一旦流转至测试流程后即被固化。这里指的是内建质量,是客观的程序质量。所有的测试行为是对这一客观质量的挖掘。因此,测试行为是通过场景覆盖尽可能地逼近这一客观的质量活动。

通常情况下,设置合理的准入标准有利于提前终止不达标制品的流转,保障流程的顺畅性,将提测质量独立度量,并对提测前进行延展收集成因数据以便形成结论。

提测质量是质量门禁的卡尺,是让研发流水线中的质量活动顺畅进行的必要保障。工程上,对于质量活动的投入为被动投入,即不可少,但期望尽可能减少投入。因此质量门禁的设置可以用相对低成本的方式,避免不必要的过渡资源消耗,就好比给汽车上蜡前,先让洗车工把车冲洗干净;否则,上蜡工不得不花费更多的时间去除车上覆盖的尘土,再进入关键工序。如下图,从缺陷成本曲线来看,是笔不划算的投入。

而内建质量,是一系列质量活动之后自然的描述结果。其中,缺陷引入率是最直接的描述。缺陷数这一绝对数量,结合其构成即缺陷分布,能够描述较为清晰的内建质量。

职能的作用是什么?这一灵魂拷问结合上图做必要的说明,从价值视角阐述其内在导向以及良性的促进闭环逻辑。

测试执行从价值视角切入,尽可能体现质量活动投入而产生的价值,从缺陷价值、回归价值两发面着手并形成正向闭环指导测试设计。简而言之:

  • 发现高价值缺陷。结合 PRD 及技术实现,覆盖用户场景的同时,刻意针对技术实现方式设计用例。如幂等校验、异常处理等。并参考覆盖率报告增补用例,确保覆盖相对全面性。
  • 自动化高价值回归用例。抓住核心、稳定两个关键词,随着回归用例的与日俱增,定期 review 进行有效用例增补与无效用例剔除以减少不必要的维护成本。

三、稳定

稳定,一般情况下是有效质量保障的自然结果。往往由运维团队主导,对线上进行实时监控,故障应急响应。生产故障数及其分布是主要核准指标。策略上遵从:不出大问题,小问题快速恢复,将故障影响尽可能最小化,即:故障影响 = 故障严重等级 x 故障修复时长。

具体指标表现为 P1P2 生产故障数减少或清零,P3P4 生产故障数收敛减少。通常故障定级标准,除了影响面作为一个维度,如资损金额、客诉量等,也会将故障恢复时间作为一个必要维度进行阶梯式定义。

另外,由于生产故障的滞后性,针对某次生产故障的复盘而产生的待办项是有效改善上述结果指标的措施,所以,待办闭环率是该方面的改善指标。

此处需要说明的是,系统性的风险累计最终会导致某次生产故障。这是质量保障工作的 “黑天鹅事件”,也是最难解释质保策略有效性的部分。老 J 给出的说法是质量保障和稳定性治理双管齐下,互相补充。局部的优化即使达到炉火纯青的地步,难抵一次结构性的破坏。而生产故障驱动的系统性复盘能够指导局部优化策略的迭代,使其更加夯实与全面。所以,这是整体与局部的二元互补增强的循环过程。

四、资源

提及资源,主要聚焦在人的维度进行最优配置,即:面向目标,将合适的人用在合适的的地方,并发挥出效益。围绕着下面三个方面进行动态调优。

  • 配置多少人?
  • 集中用在哪?
  • 效益如何放大?

这是一个配置策略的问题,而策略本身源于目标,在一段时间内解决一个什么样的问题,应该符合 “SMART 原则” 而设定与开展。

分别引入资源开测比、预实比及直接反馈职能效益的时均用例执行数与上述三个方面一一对应。其中:

  • 资源开测比反映的是增益投入(开发)与被动投入(测试)的结果。
  • 预实比反应的是资源利用率及有效投入情况。
  • 时均用例执行数是反映职能从事质量活动的效率水平。依赖内建质量质量、协同效率、测试策略及配套工程手段的综合情况。

总结

“无数据不管理”。数据是工作过程中的一种低成本沟通方式。定性的描述,故事性的讲解都不如定量的摆事实来的直接与高效。

总结下三级指标指的是:

  • 一级指标,即结果指标。起到 “后视镜” 的作用,有一定的延迟性。
  • 二级指标,即拆解指标/改善指标。对结果形成进行构成拆解或者直接可以作用以改善结果。
  • 三级指标,即改善指标。可以对应到一个或一组改进行为以获取对结果的部分改善。

“三级指标体系” 能够将工程质量加以体系化度量的一种最佳实践。历经基线建立,数据校准,特别是与体感的拟合,这也是体系打磨的主体工作,极为耗时耗力,最后是系统化收集与可视化呈现,让数据实时服务于日常工作。

效率、质量、稳定、资源四个方面的关系可描述为一下三句话:

  1. 质量是职能线立命之本,稳定是有效质量活动的自然结果;
  2. 累加效率这一约束条件,以实现有质量地快速交付;
  3. 同时,尽可能少的投入资源。

三级指标体系是系统化的、体感拟合的、可持续积累的研发数字化资产。随着持续的积累与应用,可以通过局部组合解决特定阶段的工程问题,如组合冒烟通过率、冒烟缺陷率、延期提测率反应提测质量,即门禁质量。而针对其组合指标的改进行为是被验证过的有效措施,通过总结落入一套 “专家意见库”,成为团队的经验与可复制能力,甚至是企业的无形财富。

同样,结合上线前的质量评审机制,通过对测试前、中、后三个阶段,选取组合并通过算法计算而形成质量风险预警效果的 “红绿灯” 提示,是数据可视化应用的一种有效尝试。

综上,设计一套有效的指标体系,并不断积累数据,能帮助我们选取合理、科学的路径实现一个个工程目标的达成。

共收到 19 条回复 时间 点赞

先顶一下,豁然开朗,感觉把之前对指标比较零散的概念立体化了。

很棒的帖子,学习了

49875183 将本帖设为了精华贴 02月11日 14:48

赞~自己比较缺乏相关的理论指导,学习下大佬们的理论分享😎

感谢大佬的整理分享

不错的分享,我们前年开始也建立了质效运营机制,质效指标是质效运营的关键部分。机制建设以来确实对团队各方面有很良好的改进效果。

可以说一下,如果分解三级指标么

无数据、无度量、无管理,手动点赞

确认指标进行度量,这只是起步。后续有大量的工作

大佬,这个书在哪看的呀

ZaZing 回复

😀

pedaloTester 回复

质效一体化的实践具有深度场景化的特征,有共性和交流探探,也有特异性因地制宜。

testrao 回复

从实践中来,到实践中去哦~

大琪 回复

的确如此。理论上的或者学术上的指标客观存在。在实践中,结合技术团队成熟度、研发模式、基础设施完善度等选取几个着实能量化问题本身的指标才有意义(指标能落地);另外,在指标的定义上也会存在不同的口径,甚至自主定义造 “概念” 都是合理的。

目前学习质量控制相关的知识,还处在眼睛看懂了,但是对于如何应用到自己的项目上还是缺乏实践和总结

质量堡垒的建设任重而道远,感谢大佬分享!

这里的质量体系,更多的是从测试角度进行质量分析,其他虽然也有涉及,但是没有对应详细的内控指标,质量从本质来讲,是产品设计层面和代码设计层面外在呈现,一般抓源头会更加的有效,不过国内的公司要看具体的氛围以及质量内控的决心,否则很多都是做的似是而非。内控测试和结果反馈会更加直接,所以更多公司首先会从测试角度进行抓

首页这篇文章写得牛,也非常赞同无数据不管理,绩效不能凭感觉给。
但是我几个疑惑点,不是质疑作者哈,只是想探讨一下:
一、这些指标数据高度依赖人的意识感知、使用项目管理工具的粒度、搜索数据的完整度、项目实际运作成熟度等。
1、如何保证每个需求都记录在案、且不同产品人员在同一产品线对需求的拆分粒度是相当的? ==>决定了业务交付吞吐率的相对准确性。
2、如何保证评估工时和结果使用工时都记录在案、且记录数据是准确的?
3、测试自动率本身就是一个很大的指标,它的有效率、个数、覆盖率如何保证是相对准确的?提测时间如何保障准确记录在案?
4、开发自测通过率、冒烟前覆盖率、冒烟通过率如何记录在案,且没有受到认为影响?
5、缺陷记录在案是的粒度如何保证不同的测试人员提交的 bug 在同一模型下?例如,有的测试人员同一类的 bug 只提 1 个,有的却提很多个,一旦成为 “业绩” 的衡量标准,整个风向维度就变了。
6、用例设计的粒度也是跟第 5 点一样,缺陷引入率还需要测试主动管理需求,如果乱关联、不关联等。。。
7、用例是否记录到项目管理工具,回归用例选入管理执行计划,是否真的执行?
。。。。。。
以上种种,还有很多因素,在中小公司的研发团队,甚至大公司的研发团队里头都没办法保证这些数据来源的数据准确。
自己活儿都干不完,还为了保证你搜集这些数据投入大量的人力物力来保障效能度量工具的基础数据,这与效能本身的出发点是否就有点背道而驰了?

这种工具忽悠大老板还是相当适用,实际中层管理者落地推行,可能有很多阻塞点。
个人觉得,这些指标可借鉴,但数据源得全部选自于团队自身随意而为的数据,而不是固化这些数据,然后结合团队当阶段实际情况(项目、个人、特性、成熟度等仔细分析),有时候你可能会发现你会得出跟数据完全相反的结论。

个人意见:数据必须有,得分析,仅参考,不直接使用。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册