研发效能 基于游戏思维的质量能效体系建设

七里外的风车 · 2023年01月10日 · 最后由 蓝蓝 回复于 2023年01月16日 · 11284 次阅读

前言

作为一个资深 DOTA、LOL、王者荣耀玩家(虽然已经退游多年),一直觉得游戏里的竞赛机制设计的非常有意思,能够让玩家乐此不彼的力争上游;比如 DOTA 在 11 平台的天梯积分排名系统、LOL 和王者荣耀的排位赛及巅峰赛机制。在充分的竞争下,把玩家在比赛过程中的表现进行数据量化,相对客观的反映出每个玩家的真实实力。
那如果能把这样富有竞争性质的积分体系引用到质量团队的管理中,会不会也变得很有趣呢?

背景

如火如荼的效能建设

“效能” 一词几乎成为各中大厂绕不开的话题,能效指标、体系建设、能效看板仿佛都成了公司研发管理标配,当然不同的岗位度量的指标或方式会有些许差异,我司在 2022 年也在大力建设效能度量体系。

绩效管理的痛点

如果公司有绩效考核的正态分布机制,那么每年打绩效、谈绩效就成了鬼门关,TL 不想过,普通员工也不想过。
每次的绩效考核,在员工自评环节,往往收到的自我评价和评分都非常的高,但在团队中是要进行排序的;可能会有人说,绩效不就是谁跟领导关系好,谁会舔领导会做向上管理,谁的绩效就好。当然不是,至少在我这儿不是,所以客观的输出量化数据就成了非常重要的参考。
大部分同学都相对只关注自己负责的那部分业务,很少看的到团队的全局,如果业务无交集,那么团队内的交集也变得比较少;团队内部都是这样,更何况不同的团队之间,TL 也都觉得自己负责的团队成员都很优秀,所以每次绩效 PK 也出现了各说各话,变成了拼口才、拼人情世故。

目标管理的盲点

福报厂有个很出名的方法论:定目标、抓过程、拿结果。
实际操作过程中,目标怎么定,基于什么来定,往往最后都是拍一个目标,也不管它的可达性。
过程的把控不用日报、周报的话,有更智能化的方式吗?
拿到的实际客观结果是多少,离目标结果又有多少差距?如果过程管控不到位,那么季度末复盘 OKR 就成了团队一起来开盲盒。

为什么做

  • 能够指导团队各周期 OKR 建设,基于数据定目标,基于目标调指标
  • 能够驱动团队内部成员良性公平竞争,团队顺利拿到结果
  • 能够及时给与团队成员数据反馈,过程公开透明

怎么做

圈定指标的原则

  • 既是一线测试工程师想要的,也是 TL、部门希望拿来拉通做对比的
  • 指标是可被量化的、可线上化的
  • 指标与指标之间需要存在互相制约性,避免出现造指标的风险
  • 指标不宜过多,满足 2/8 原则,20% 的指标覆盖团队 80% 的工作过程与结果
  • 团队成员对于最终指标的确定有投票权,但无决定权,因为众口难调无法满足到每一个人的诉求

经过了 1 次团队工作坊、3 次对齐会,通过匿名收集、共性指标整理、可行性分析、匿名投票的方式,最终确定出 Top10 指标:

  • 有效 bug 数
  • 无效 bug 率
  • 线上问题(bug、故障)
  • 功能用例设计
  • 功能用例执行
  • 专利(受理、通过)
  • 代码量
  • 工具节约成本
  • 自动化工厂用例贡献
  • 自动化用例应用

指标的计分总规则的确定:

  • 方式一:各指标分权重百分比,总分 100
  • 方式二:各指标有计分系数,总分无上限

其他 TL 更倾向方式一,我更倾向方式二;各有利弊。
方式一把每个人按照固定的框架去限定,最后大概率会变成同一类人:各方面能力比较均衡,并且可以预料出最终每个人的得分比较接近,难分伯仲;
方式二能够鼓励同学们发挥自己的优势,长板可以很长,但也有一定的阶梯积分法,在长板足够长的情况下,去补短板,分数区间会被拉的很大,能够一目了然识别出高产的同学和低产的同学。
好在最后我说服了其他 TL 以及团队的小伙伴,让我的天梯计划能够跨出第一步。

指标取数规则、系数、计算逻辑的确定:

即然要做在线化,那么就涉及到指标怎么自动计算与展示;每个指标的规则是否公平客观,数据从哪里取,怎么进行加工。

各指标系数的确定:

同样通过匿名收集的方式,拿到每个同学心目中系数情况(说实话差异太大,每个人都想往对自己有利的方向去定,甚至 TL);统计筛除异常样本、统计往年历史数据表现(做分数模拟),再经过 TL 层面反复讨论,最终定出终版:

数据源:

由于我们自建了测试平台,包含了功能测试管理、自动化测试、工具集成与组装等模块,让我们在取数渠道上少了很多麻烦,大量的过程数据已经有沉淀。只是部分指标上需要特殊处理:专利情况的手动录入(专利并不多)、代码量的获取(基础架构部门在统计代码量,开了个接口在拉取同步)、工具使用增加埋点统计

计算规则:

积分的计算规则按照个数与阶梯系数进行加权,有加分、有减分,即可得到天梯总分;以 T+1 的形式用 job 产出每日分数,可以观测到部门、团队、个人的每日趋势;积分在每年 1 月 1 日清零重新积分

效果展示

(由于 1 月 1 日积分清零,所以整体分数偏低):



结果展示

那天梯积分对于部门目标、团队目标到底有没有指引作用呢?
举个例子:去年部门的年度目标(专业线)是想要拿到自动化建设的结果,希望建设一批稳定的可用于回归的自动化用例(OKR 目标 500 个稳定用例);为了拿到这个结果,经过 TL 层商定,暂时把 Q4 的自动化工厂(稳定用例)系数调高 3 倍,调动了同学们的积极性,从年底拉取的数据来看,部门总共建设了 7500+ 条自动化用例,其中 4700+ 条进入了自动化工厂,拿到超目标 9 倍的结果
而今年(2023 年)我们将向自动化工厂的应用方向进行引导,会把免测贡献、自动化创建 bug、生产业务可用监控(持续跑自动化)、DevOps 质量门禁保障 等等纳入工厂应用且调高系数,期望拿到结果

思考复盘

天梯积分体系在部门跑了快半年了,零零散散收到同学们的一些建议和看法,我们也发现了部分同学在故意造指标刷分的情况出现(送他个 D,哈哈),但从整体来看,磨合的还算成功;
天梯无法收集到团队成员的所有产出,特别是高职级的同学,比如沟通协作管理的输出无法被量化;所以天梯积分对于绩效考核而言,仅做数据的重要参考而不是最终的绩效排名。
在 2023 年,我们会继续增加天梯积分的指标:比如需求评审问题发现数、CR 问题发现数,期望通过这两个指标引导小伙伴们进行质量能力左移;根据 2022 年积分分布对部分指标进行微调,希望这个体系能够越跑越合理,对过程和目标有更清晰的把控。
最后,希望通过这篇介绍能够给读者带来一些思路,也欢迎大家讨论拍砖给建议。

共收到 21 条回复 时间 点赞

其实,只要有排名,就一定会有漏洞。
初衷是好的,不过,我倒希望,这种天梯积分,可以对绩效起到引导作用,而不是决定性的作用。

Smobee 回复

嗯,对个人绩效和团队想要的结果都是引导作用,不会直接与绩效挂钩,这也是我们建设这套体系的出发点

量化是必要的,但问题是不好量化。。
1.量化指标很容易被刷分, 导致结果失真,我看你定的 top10 里大多都可以刷。。
2.各个业务线情况不一导致的不公平,就说第一个 “有效 bug 数”,产品的生命周期、复杂度,开发的能力、质量意识等等各种客观情况不相同, 每个迭代 BUG 数肯定也不一样
3.容易误导测试同学,会有意识地刷分注水,导致目标偏离。
4.“天梯积分对于绩效考核而言,仅做数据的重要参考而不是最终的绩效排名” “失真” 的结果并不能给到靠谱的参考,最后还得靠 TL 主观判断。

这真的好吗,很多时候一旦定了指标,就会引导大家往指标体系意想不到的方向发展。

或者从另一个角度说,只负责搞日常业务测试的同学倒是可以比较好的融入,很多不同角色的同学在这个体系里估计很惨。

我觉得最好的方式,就是完全剥离和工作考核,仅不作为参考,也不作为依据。

可以只作为,兴趣提升平台,可以在月度,季度,年度,对榜上优秀的,奖励一些小礼品什么的。

还可以设计成匿名天梯积分,到年末才会公布具体名单。

一旦剥离了和工作之间的关系,这个就变成纯粹的兴趣爱好,那么,对于个人来说,是有好处的,但对团队是否有益处,这个不好判断;

这种标准化,量化,刷分是不可避免的,所以,就不存在,一定 “准确” 和一定 “公平” 的情况。

最终,我的个人观点,还是一样,天梯积分,要么和考核挂钩,要么和考核毫不相关,因为你一旦出现,要么相关,要么不相关的复杂联系,程序是没办法主观判断(无法做到公平公正),最终还是需要人去主观判断(就一定会出现情绪判断,谁和我关系好,谁和我关系不好),这样还是会回归本质,并没有实质性解决根本问题。

Smobee 回复

匿名的这个思路挺好,可以减少同学们日常对榜单的关注👍

在收集指标的过程中,我们也收到到了大量的指标:接近 50 个,分析过后,能够量化的就比较少,且有些指标属于比较有业务特性、角色特性的,难以去做拉通;所以肯定会出现有很多具体的工作难以被纳入到这套积分体系中,特别是高职级的同学,基础工作往往做的并没有那么多。所以数据量化结果也仅仅是做参考,并不会决定生死;因为工作中除了可定量的结果,还有定性的输出,同样是不可忽视的。

也确实会存在业务性质、复杂度,不同团队不同的开发质量,测试同学个人工作习惯等等的差异性,导致基础数据本身就存在偏差,在参考数据的同时我们也会主观的去判断,当然这部分没办法硬去量化一个系数简单的做加减乘除

要直接通过这个体系去识别谁比谁强,谁比谁产出多,会很难找到答案;但是可以很容易的识别出比较异常的 case(谁在划水)

其实天梯也是可以刷分的,本质上都一样。谁还没带过妹子不是。

我在团队的实践思路是:重点关注生产缺陷、流程改进建议数、效能提升项,这三个是考核的重点内容(60%)。其它的,根据团队反馈来估计,占比 40% 左右。想要出成绩,要么保质量(线上不出问题,过程你们自己定,不管你是点点还是自动化,线上不出问题,怎么都可以。出了问题,有没改进项,是否落地了,是否重复出现等),要么改进过程,提升效能。

绩效本来就不会有绝对的公平。这个世界也没有绝对的公平。这也不是我们要去追求的。平衡才是常态。毕竟软件研发过程,还是没办法直观量化的。和工厂的拧螺丝还是有质的区别。

量化的东西,初期基本都怀着美好期望的,随着人员流动,团队变化,个人诉求转移,久了必失真,如何长期维持下去很考验水平。

哈哈,我觉得,现在越来越内卷了,,滑水摸鱼,似乎变的越来越难了。

这样做,对于团队,企业,提升,是有益处的,总之,优点大于缺点。

不过,我觉得,最难能可贵的是,从构思,到实现,再到落地,并能够在实际工作中展开,是非常不容易的。

离不开,每个小伙伴的支持与配合,我还是相信,你这套体系,会越来越完善。

另外,我个人觉得,你的执行能力很强,从需求场景的构思,再到方案的决策,再到具体的实现,最后的推行实施,离不开一个关键人物,就是这个体系搭建的负责人(你的文章,没有提及,所以,如果你是负责人的),我会觉得,你的能力真的很 OK。

Smobee 回复

哈哈,感谢夸奖,确实在整个构思到开发落地推行,碰到了来自各方的阻力,让我学到了不少😀

你是开发吗?还是项目负责人,,我很好奇,有这样的一种需求场景,,是单独成立一个项目吗?然后你是怎么分配前端和后端的开发任务的?

Smobee 回复

我是测试,也是产品也是开发😂 前端是我们组其他小伙伴做的,集成在我们自己做的测试平台上。这个东西从产品设计开发上线也就用了两三天吧,花时间的是前面的构想、指标收集对齐。不存在项目一说吧,就是一个想法把它实现了而已

楼主,如何实时统计一个接口的覆盖代码范围?

楼主的想法挺好的,最终也落地了,但是质量只研发团队共同的事情,为什么在设计的时候没有产品开发的相关数据的收集和分析呢

xinxjxjxj 回复

有的,产研的质量看板早就做了的,只是没有按天梯的模式来做;
公司建设的能效指标有很多都是测试平台沉淀下来的数据提供出来的,比如:bug 响应速度、千行 bug 率等等
质量看板维度也分了:项目质量看板、团队质量看板、个人质量看板

江乡萌蘖 回复

之前用 jacoco 二开做的染色,也集成在测试平台上了;暂时没重视这块,也没去做更深的改造

楼主啊,“积分的计算规则按照个数与阶梯系数进行加权,有加分、有减分,即可得到天梯总分”
请问你这个怎么设计表的? 我正要做这个计分,但是规则太多,没有一个可以统一的方式去计分

蓝蓝 回复

一个宽表,收纳所有的源数据(T+1 job 每日更新),比如:bug 每个级别的个数(按人维度去落);
另一个积分表,按源数据计算得分每一项的分数;表怎么设计也关乎你想怎么呈现,仅供参考

好的,感谢大佬

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册