生产环境出问题了,研发要不要罚钱?

简介: 生产环境出问题了,研发要不要罚钱?

生产环境出问题了,研发要不要罚钱?

这是一个很常见也很有意思的一个话题, 在不同的角度看待这个问题都能得到不同的结果, 公有公的理婆有婆的理。 大多数公司都是采用罚款的制度, 我之前经历过的公司也不例外,

但是我们仔细思考一下, 我们到底要解决什么问题? 这个问题的本质是什么?

制度引发思考

我们在做软件开发的过程中, 总是会遇到各种各样的 Bug, 然后经过一系列的测试验收, 上线到生产环境。虽然技术部门准备得十分充足, 但是线上还是会出现事故 (开发可太难了!)。

然后企业就会制定相关制度, 根据这个错误的严重程度, 给予不同的惩罚(大部分都是罚钱)。

  • 为什么会有这个制度的产生呢?

原因很简单, 线上出现了事故, 领导认为根本原因是负责人不够认真、不够投入, 出了事故就得承担责任。 这个观点中, 事故是现象; 负责人不够认真, 是本质。这样的逻辑清晰吗。

  • 动摇初心

一开始, 我觉得错了就得认, 挨打要立正。但是直到有一天,跟团队一位负责人唠闲嗑, 他说:"你这制度设计不合理。多做多错,少做少错,不做不错,你这是变相鼓励团队少做事"

我一愣,觉得这位负责人说得有些道理。因为,对于大促这种高并发的场景,最容易出问题的往往是最核心的模块。相对来说,一个边边角角的简单系统,就不那么容易暴露问题。

试想一下,一个能力很强的人,包揽了团队最重要、最累的工作,结果出了问题反而被罚了 3000 块钱;一些庸才付出得相对较少,一个月安安稳稳的,反而一分钱没扣。这个逻辑显然是有问题。

于是,我对这件事的本质认知开始动摇,但压力也随之出现: 出了事故就罚钱,好像不太对劲; 但如果不罚钱,那团队是不是就会因此松懈下来?我喜欢看兵法,打了败仗,部队里可是要问责的,这罚钱肯定是问责最直接的方式了。

这时,我意识到,关于 "研发事故的处罚措施" 这件事,有必要重新思考其背后的本质问题。如果管理者只会罚钱,大概率是在将压力转嫁到一线人员身上。

问题的本质

一句 "多做多错,少做少错" ,并不能概括问题的全貌,最好还是广开视听,交叉验证一下。

所以,我很快找到公司的 HR 部门聊了聊,HR 同学惊讶地说道:"话不能这样说呀!核心部门虽然容易出现事故,压力比较大。但他们的奖金额度高,薪资水平也普遍高于其他部门,升职机会也更大。"

听起来也有道理,好像被处罚的员工也并非单纯的 "受害群体" 。围绕这个问题继续思考,我很快发现: 出了事故就罚钱,这与自己提倡的有些企业文化也是相违背的。

比如,我鼓励 "勇于试错",动不动就罚钱,那谁还敢试错?我提倡 团结紧张严肃活泼 的团队氛围,在这种制度下好像也很难实现; 一旦开始罚钱,事故所牵涉的部门就会开始互相推诿,团队协作和氛围就会出现问题,这也不是管理者们希望看到的。

这时候,我停下来,又推演了一下惩罚制度设立的初衷。它不是为了 "恶心员工" ,克扣工资; 而是尽量保证同一个问题不要再犯,或者说,降低犯错的次数。

在大型企业,一个 CTO 级管理者因为位置太高,很容易脱离实际的生产情况。如果不做深入观察,CTO 可能会气恼地发现:IT 部门根本就是不停地犯错!只有当他深入追查问题来源时,才有可能意识到:发生在核心业务上的生产事故,往往涉及多个部门、多个团队,实际情况常是 A 部门刚刚犯错被罚了钱, B 部门又犯错了;B 部门被罚钱没多久, C 部门又犯错了……

其根本问题在于,A 被罚了钱,并不能让 C 免于犯错,甚至也不能让 A 保证不再犯第二次,反而让所有人胆战心惊。

综合所有了解到的情况,我们很容易就能得出结论:罚钱确实让员工更重视问题了,但并不能在本质上解决问题。

最后,我又换位思考,也问了问自己:“换做是自己,自己能不能保证 100% 不出事故?”答案当然也是不能,尽管对自己的工作能力和责任心都很有信心。

生产环境出现事故,与员工的责任心和能力没有绝对因果关系,故而不能靠单一的惩罚条例,其背后本质,是管理者是否能够体系化地解决问题。

从罚钱到不罚钱,在我眼中,变化的是对问题本质的理解。当然,我也围绕新的认知制定了许多相应的体系化措施,包括:

  • 一个事故要有七个改进点:每个改进点保证 100% 不重犯;
  • 犯错的人负责牵头落实复盘,分享失败的经验;
  • 解决问题的手段产品化,人会犯错,但产品不会犯错;
  • 允许每个人犯错、试错;
  • 根据事故统计定期颁发 "烂草莓奖""金苹果奖";
  • 管理产品化、系统化、数据化;

一旦对问题本质形成了新的认知,解决方案就会自然而然地涌现出来。在新制度下,事故系统的当事人不会再受到金钱上的惩处,但很可能会收到 "烂草莓奖",激发团队的荣誉感和责任担当。

如何窥探问题的本质

看了上面这个故事, 我觉得本质思考是很有必要的, 但是如何实现本质思考呢?这里也有一个所谓的方法论:

image.png

我们先将上面那个是否罚款的问题利用这个思维模型进行分析.

  • 定义核心问题: 如何避免生产环境经常出现事故
  • 发现问题本质: 工作能力和责任心并不能完全保证事故不发生,犯错后经验没有进行分享
  • 找到本质解: 不能将事故全归到人身上,针对犯错要保证不重犯
  • 解决问题: 允许犯错、试错,及时复盘和分享经验等等

根据这个思维模型或案例, 可以回想一下, 我们之前的决定是否有合理地去思考, 还是随波逐流, 盲目跟风。就拿高考填志愿和定居城市两个问题来说, 我们有找到自己真正的答案吗。

那基于这个思维模型, 我们可以去寻找一下本质解, 来验证一下我们之前的选择。

  • 高考志愿

image.png

  • 城市定居

image.png

目录
相关文章
|
SQL 监控 网络协议
线上故障如何快速排查?来看这套技巧大全
有哪些常见的线上故障?如何快速定位问题?本文详细总结工作中的经验,从服务器、Java应用、数据库、Redis、网络和业务六个层面分享线上故障排查的思路和技巧。较长,同学们可收藏后再看。
线上故障如何快速排查?来看这套技巧大全
|
运维 监控 数据库
线上服务故障处理原则
墨菲定律 任何事情都没有表面看起来那么简单 所有事情的发展都会比你预计的时间长 会出错的事情总会出错 如果担心某个事情发生,那么它更有可能发生 墨菲定律暗示我们,如果担心某种情况会发生,那么它更有可能发生,久而久之就一定会发生。
2272 0
|
5月前
|
Java 中间件 Spring
开发与运维应用问题之应用启动提速如何解决
开发与运维应用问题之应用启动提速如何解决
|
5月前
|
数据采集 算法 API
开发与运维命令问题之安装和使用ToolLLaMa如何解决
开发与运维命令问题之安装和使用ToolLLaMa如何解决
42 0
|
5月前
|
测试技术 数据库 开发者
开发与运维测试问题之高代码覆盖率意味着高代码质量如何解决
开发与运维测试问题之高代码覆盖率意味着高代码质量如何解决
|
5月前
|
中间件 测试技术 数据库
开发与运维测试问题之AIR原则如何解决
开发与运维测试问题之AIR原则如何解决
|
7月前
|
运维 Devops 开发工具
生产环境缺陷管理
在一个大型团队中,bug协同管理是一件复杂的事情,发布经理要追版本bug,运维同学要评估bug影响范围,开发同学要在多个开发分支同时修复同一个bug,很容易出现bug漏提交、漏确认等生产安全问题。
|
SQL 弹性计算 运维
|
SQL 设计模式 监控
自动化测试中对数据恢复的思考与实际业务改造实践
基于接口自动化测试过程中、产生的测试数据如何恢复的一点思考与实际业务改造实践。
自动化测试中对数据恢复的思考与实际业务改造实践
|
运维 Prometheus 监控