“恶意自学”看来工匠精神要灭绝了？

作为一个天天“开车”的不正经TestOps测试技术交流群，每天都能冒出一些让我匪夷所思的时事新闻。

以下内容皆为假设上图为真实内容为基础，个人调侃。“恶意”这个词成为了最近热词，从“恶意”返乡开始，只要和一些东西对不上就可以加上恶意二字，从而从道德层面上升到法律层面。看来“恶意加班”已经不远了，作为圈内客气的“内卷”一词可以用“恶意”替代，并且可以有效的进行打击，从而让行业重新回归轻松自在的理想状态！

一旦“恶意”这个屠龙标准奠定可行，就好比掌握了流量密码，简单套用，一切不好管，不能管，不想管的事情都可以轻松应对。

研发效能也是如此，一旦指标制定成为目标，那么都会成为大家应付的目标，这就是著名的古德哈特定律。为了把工作做得更好，基于热爱琢磨工作，利用工作闲暇时间，这种传统的“工匠精神”从辈调侃的“内卷”这下可以上升到“恶意”二词了。
人家上班能做好的事情，你上班做不好就是“恶意”，因为研发度量的指标上有工作时间，有提交代码次数，有上班查询各类技术网站的记录，还有上厕所离开工位的记录……。
如果要说最“恶意”的度量，莫过于当年的每日提交缺陷数了。每次上线问题都很多，为什么测试不能发现这些bug呢？有些非常基础，那么解决问题的方法不是指导和提高测试团队的能力，加强质量内建，而是丢个每个测试每天必须发现10个bug，而且其中必须要有2个严重bug。这个策略一出一定异议不小，但是总有人能够做到，而能力不够的做不到，从而被淘汰更换适应的人，这样一看这种度量非常有效。而再加上如果研发被发现一个严重的问题，要扣绩效，并且给发现问题的测试基于奖励，构建测试与研发的对立关系，那么在这个指标体系下，会进一步的提升质量。看起来一切都如此的丝滑，然而这套思路很快就下不去了，每天都是开发和测试还有产品扯皮，如何定义这是缺陷还是一个设计问题，如何评估缺陷的级别，最后连代码都不用写了。
最近研发效能如此热门，可以预见在不远的将来，各种“恶意”数据一定会成为管理团队、人员、流程的新宝剑，在OKR+KPI双套指标下，如何成功“努力”而不“恶意”会成为新的热点方向，就好比很快下架的“离职倾向员工”监控系统，“恶意离职”可能早已板上钉钉。