有错就该罚,这么简单真的好吗?

有一天下午,我正在日常制作页面。忽然上游过来沟通,补报需求。
原来上游整理并提需求时不小心漏了几个,需要我们小组多做几个简单页面。
为了提醒对方细心,我们按规定要求对方发邮件再提需求,并抄送他们总监,这样我们才能接下需求。
需要给他们点压力,不然每次都是这样岂不是乱套了吗?
然后一阵扯皮,大约是在探讨究竟是他提的少了,还是我们收的少了,然后又探讨是否有必要发邮件。
直到临近下班,他终于发了邮件并抄送了总监。我们也不多说接下了几个简单的需求(是真的简单需求)。

事件过后下班了,大家都通畅了,我却纠结了:这件事这么处理真的好吗?

犯错了要求发邮件并抄送总监,为了让犯错的人长记性,应该的啊,还有什么好想的。顶多就是换个惩罚方式或量度。
但是这样的处理过程浪费许多时间啊。因为怕被总监知道,于是他想尽办法隐藏,最终扯皮未果才认命。
反正确实需求简单,要不我们不说那么多,结果也是一样的做。但是又怕对方以后肆无忌惮。
难道我们就真的要这样互相伤害吗?能不扯皮又长记性吗?
究竟我们该怎么对待和处理错误呢?

一、现在的惩罚机制有什么问题吗?

我想到了许多的错误案例以及对应的处理。大多都是错了就该罚下,以示警告,提醒认真细心。
但这些处理总让我不顺畅,总觉得有一种无奈,罚了有问题,不罚更不行。貌似就没有更好的办法了。

在创业公司时,运营人员由于失误打印了旧版本的宣传单,发现后,当时的主管说这是员工的失误,不应该由公司承担,于是他自掏腰包付了这些错误的钱。
(这个处理不妙啊,潜意识里告诉员工:多做多错,不做不错。可是不罚的话,公司也没有错啊,究竟损失谁承担呢?)

在大公司时,我不时会发生代码有bug,写错数据等错误,每次组内被罚请客,也在公司的报障系统上有了几个记录。
(被罚的算是轻了,但是就是不爽啊,特别是那几个记录,听说以后晋升时也会参考的,总觉得像是在警察局留案底一样。
这几个记录让我以后做事非常谨慎,偶尔也会想多做多错,不做不错。少做自然少错,但是想发展就得多做,唉,挺痛苦的。)

同事偶然踩到了一个坑,做的页面出了小问题,但主动提出必然会被罚,甚至会留下记录,于是选择了隐藏错误。这个坑可能大家都会踩到,但谁也不想自己被先罚了一下。
(错了就罚,这可能导致大家倾向隐藏错误,会不会有隐患?如果制度影响到大家对分享错误的积极性,是否于团队成长不利?)

我不小心犯错了,会影响绩效,公司会有记录,然后我就会反省,我就更加的谨慎细心,这样就不会有下次了。
然而后来我又不断犯错,也有许多同事犯错,才终于有人提出,缺少流程或者工具,或者现有流程和工具不够好,我们要改进。然后我们终于大大减少了类似的错误。
这大概是我们大多数的成长之路。

有错就罚,这个措施或制度有效的抑制了肆无忌惮,大家都变得谨慎。哪怕犯错的同时会带来成长,但因为惩罚,我们都害怕犯错。错误似乎是可耻的。
即使常说,失败乃成功之母,错误并不可怕,可怕的是犯同样的错误。
这又有多少人深刻认同呢?错误失败带来的成长成功还遥不可及,惩罚却是即时到来。
错误失败依然如天灾人祸,我们都想避开错误失败,直达成功。即使心里也清楚不太可能,却依然孜孜不倦的这般去做了。

二、没有惩罚是不科学的,那究竟该怎么惩罚呢?

我们平时都知道:犯错后的第一要务是处理错误(如及时阻断错误扩散,补救,恢复等),然后是错误总结反省,如果可以,分享出去就更好了。
但是当我们犯错后,我们懊恼,更担忧接下来惩罚,往往忽略了我们该做的。
即使再优秀,错误仍不可避免,为何还要执着于错误本身,更应该惩罚的是不良的错误原因,不当的处理态度和方法。这些可是可控因素。

如果我们淡化错误本身,转而关注错误原因,处理态度和方法。惩罚的重要依据变成不良的错误原因,不当的处理态度和方法。
犯错后,惩罚还在后面。需要在我们处理完错误,深刻反省总结后再按流程回顾这个错误。
需要综合错误的开始、过程、处理、反省,以及总体结果,然后对错误进行总体评判。
如果错误并不是那么简单,淡化错误本身也是有限度的。
例如错误造成了公司声誉损失,伤害了客户或者他人等,即使是不小心导致的也要坚决的给予应该的惩罚。这些损失,不管原因过程,错了就要承担代价。
然后再对不良的错误原因,不当的处理态度和方法,一一细究并妥当处罚。若错误后续并无不妥,则相应淡化一些惩罚。
惩罚的依据很明确,错误并不直接导致惩罚,错误相关的态度方法才是。

公司更关注处理态度和方法后,我不小心犯错了,我小心处理,争取补救,之后深入反省总结。我不想再做错什么招致更厉害的惩罚。
有了这次反省总结,让同事都有了经验,少了犯错。几次反省总结后,有人提出,缺少流程或者工具,或者现有流程和工具不够好,我们要改进。
淡化错误本身,帮助我们在犯错后尽快忘掉懊恼和担忧,直接过渡到处理态度和方法的思考,有利于减少损失。
当然,我们同时也关注错误处理后的总结反思和分享,积极的发散经验,治未错。

如此,即使不惩罚错误也让人胆战心惊,处理不及时、不认真、不恰当,推卸责任,隐藏错误,反省不深入、不彻底都可能招致重罚。
被惩罚的滋味让人难受,意识到自己犯错,可能正走向惩罚同样让人心惊肉跳。
即使淡化错误本身,我们还是同样担心会犯错,但是我们不再怕影响绩效和评价,不怕留下案底。
也许公司还是有记录,但是记录的不仅仅是错误本身,更有错误带来的经验。这不再是案底,而是经验的分享。
我们认真对待,积极及时处理并反思,错误带给我们更多成长,我们不再怕多做多错。

三、有错就罚依然是主流,我们怎么面对?

至今,关注错误的处理态度和方法,以及后续的反省总结仍然大多数时候都是我们自己的事情。
公司的制度只是在用惩罚抑制错误,用奖励吸引成长,但过程得靠我们个人努力,公司制度并不关注过程。

曾看到过其他对待错误的观点
如这一段英文(据说来自Facebook的新员工手册)
Move fast. We have a saying: “Move fast and break things.” The idea is that if you never break anything, you’re probably not moving fast enough. At Facebook, we’re less afraid of making mistakes than we are of losing opportunities.
Be bold. We have another saying: “The riskiest thing is to take no risks.” In a world that’s changing so quickly, you’re guaranteed to fail if you don’t take any risks. We encourage everyone to make bold decisions, even if that means being wrong some of the time.
再看看一个新闻
Supercell 每砍掉一款游戏,就会举行香槟庆祝分享会 http://developer.51cto.com/art/201604/508377.htm
原来这些极其成功的公司都是不怕犯错失败的。

可惜我们更多听到的是这样的声音:
“上次我们去Supercell,给我们演示游戏的小伙不到30岁,当时演示的游戏是2个人用2个半月做出来的,现在这游戏全球排第一。”(出自史玉柱在2016年首次员工大会)
supercell的成功背后有着更多的失败探索做铺垫。那2个人也许失败不多,但必定受益于团队的失败探索,受益于团队的积累沉淀。
然而如上所说公司并不关注过程。

公司的情况我们并不能影响多少,只希望自己能关注自己应该注意的东西。
希望自己能更正确深刻的认识对待错误,能多一些好的习惯,如对待错误的态度、处理流程,以及后续反省总结。
希望自己能处于对错误谨慎,又能跨过错误放开手脚大胆进取的状态。Be bold,move fast.
也许错误失败并不能让我成功,但成功不必在我,而功力必不唐捐。

时间: 2024-10-12 22:12:25

有错就该罚,这么简单真的好吗?的相关文章

带有“非简单参数”的函数为什么不能包含 "use strict" 指令

非简单参数就是 ES6 里新加的参数语法,包括:1.默认参数值.2.剩余参数.3.参数解构.本文接下来要讲的就是 ES7 为什么禁止在使用了非简单参数的函数里使用 "use strict" 指令: function f(foo = "bar") { "use strict" // SyntaxError: Illegal 'use strict' directive in function with non-simple parameter li

winform 利用 多线程 处理窗体假死,利用 Invoke BeginInvoke 处理子线程调用 UI 控件报错的问题

因为工作需要自己写了一个简单的工具软件,数据库查询每日OA未发送成功流程的日志记录以及批量重处理操作. 开始使用的是单线程,后台查询数据库的时候窗体假死,使用多线程很简单就能解决. private void btnQuey_Click(object sender, EventArgs e) { this.button2.Enabled = false; Thread connectionThread = new Thread(new ThreadStart(connectDB)); connec

hdu 1465 不容易系列之一(错排)

不容易系列之一 Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) Total Submission(s): 16899    Accepted Submission(s): 7037 Problem Description 大家常常感慨,要做好一件事情真的不容易,确实,失败比成功容易多了! 做好"一件"事情尚且不易,若想永远成功而总从不失败,那更是难上加难了,就像花钱总

为什么你学不好java!请你好好思考下,你真的有这么弱吗?

java难学? java难学!是的,没有错!如果java这么简单容易,你觉得还会有它的市场价值吗? 我英语差.我学历低.我理解能力差,能战胜它吗? 整天遇到困难就逃避的人,学什么都学不好!还没有开始就否定自己,大清都亡了,只有天才一出生啥都会的! 做什么事必须要在它的身上付出,你付出的多回报就越丰厚!没有任何人的成功不是不通过自己的努力! 只要下定决心,给自己定个目标,要怎么开始学.每天学习多久.花多久的时间学会!你问问自己你就甘心在这个社会没 有一技之长,就甘心别人的一月的薪资是你一整年的收入

1005acm罚时

ACM国际大学生程序设计竞赛是由国际计算机学会主办的,一项旨在展示大学生创新能力.团队精神和在压力下编写程序.分析和解决问题能力的年度竞赛.参赛队伍最多由三名参赛队员组成,竞赛中一般命题10-13题,试题描述为英文,比赛时间为5个小时,前4个小时可以看到实时排名,最后一小时封榜,无法看到排名.竞赛可以使用C.C++和Java.重点考察选手的算法和程序设计能力,选手可携带任何非电子类资料,包括书籍和打印出来的程序等. 返回结果Accepted表示答案正确,Wrong Anwser表示答案错误,Pr

[小菜随笔]关于monkey报错日志分析

今天小菜在一个测试群内看到群友发出一个monkey的报错信息,其实是一个很简单的报错 个人觉得monkey虽然操作起来比较简易,但其实查看日志分析日志也是很重要的环节,如果对错误分析不够详细,就容易误认为是程序的问题 以下举个例分析一下 这个报错日志其实已经很简单的告诉你错误原因了 解析如下:第一行:monkey因为错误而终止了 第二行:出错的错误事件在第153次 第三行:发送旋转事件,度数为0度 很明显,错误是发生在旋转屏幕的原因,那么是不是软件自身的问题呢,我们往下分析 首先:1.检查自己模

acm2049引出的错排问题

直接讲错排问题 解决了错排问题 代码很简单. 声明:假设共有n个男生 f(n)表示有n个男生选错的情况总数 同理可得 f(n-1)表示n-1男生选错的情况的总数 用逆向递推的思想 第一步.第n个男生可以选的位置有n个 其中错的位置有n-1个 假设他现在选择了错的里面的一个位置K 第二步.此时我们可以先让k来选择 因为他比较特殊(无论选哪都是错的位置) 虽然他选什么位置都是错的 当可以供他选择的位置中还是有特殊的位置 我们分为第n个男生的位置和非第n个男生的位置 1.如果他选了第n个男生原来的位置

kotlin 简单处理 回调参数 加?

Kotlin Parameter specified as non-null is null 2017年10月18日 17:21:49 amiko_ 阅读数:9017 版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/chf1142152101/article/details/78275298 报错信息如下: java.lang.IllegalArgumentException: Parameter specified as non-null is

shell脚本报错

早几天在pc电脑写了一个shell脚本,用来执行springboot项目,然后在centos7执行的时候报错,脚本如下比较简单:start.sh,下面只是列举了一部分脚本代码 2.拷贝脚本到linux服务器执行报如下错误: -bash: ./test.sh: /bin/bash^M: bad interpreter: No such file or directory 后面查了下资料报错原因是: 我的start.sh的格式显示为:fileformat=dos start.sh是我在windows