白驹过隙,这篇文章距今已有一年以上的历史。技术发展日新月异,文中的观点或代码很可能过时或失效,请自行甄别:)

说一个有趣的是事情.

某天晨会的时候, 前端妹子提了一句: 最近后端接口的质量不是很高呢,有些字段和文档不一致,有些接口也缺失. 于是后端leader拉着其小伙伴到会议室开了一上午会,以为事情就告一段落了. 没曾想下午在前端这边开会时得知, 后端leader立了一个新规定: 如果以后接口质量不高,先从相关负责人开始罚,一次罚200, 两次double, 再找问题造成的实施人员进行罚款, 规则如上. 深感震惊之余, 果断劝退前端这边也想用这种“罚钱”模式来提高“质量”的念头, 采用了每周复盘的方式来达到同样的目的才作罢.

为什么说这件事情很有趣呢? 因为代码质量不高,就用罚钱这种事情来“惩罚”相关的小伙伴的机制和小时候老师为了上课不开小差, 教室吃零食就罚钱请家长没有任何区别. 前者的结果是什么呢? 我想任何一个在国内长大的孩子都很清楚. 不仅没治标, 更别说治本了. 同样的, “罚钱”政策之后会发生什么事情呢?

很明显, 每个人在提意见的时候, 可能都会“害怕”对方扣钱而思考再三甚至都不会再提. 假设提了, 被罚钱的那个人会怎么想呢? 200确实不多, 但是谁会跟钱过不去呢? 况且, “质量低”这种事情,怎么个判断法,衡量的尺度又是啥呢?不知道. 退一万步说, 现有的小伙伴接受了, 当一个新入职的小伙伴听到这种“奇葩”的政策的时候会想什么呢? 还能好好待? ok, 就算呆下来了. 不是代码质量要高呢? 没问题, 原本一天能做完的东西,为了保证质量, 那2天吧, 哦不, 还是3天吧. 长久下来, 团队会变成什么样子呢? 说实话, 我是完全没有看到这种“罚钱”政策带来的任何好处, 也真的震惊为何会想到这种玩法.

代码质量不高其实并不是什么大事, 但是为什么我单独写下这篇文章的原因在于告诫我自己, 一旦出了问题的时候, 第一件事情的问题是解决它, 然后找到原因并且如何优雅的规避, 而不是简单粗暴地一刀切. 不仅适用于管理, 更适用于任何人和事情. 写代码这些年给我最大的感悟就是世界其实真的非常简单, 很多“bug”的产生大多都是我们不遵循这个世界的一些“法则”的后果.

最后, 希望这些“有趣”的政策能够在这个世界上越来越少. 我想, 这个世界也会变得越来越和谐和美好吧:-)