还在 996?说白了就是能力问题

前天在我的社群里分享了一篇吐槽国内互联网公司的文章,本意是: 这么吐,姿势有点偏激了。 说起来也是辛酸,大家都在疲于奔命,谁能比谁跑得姿势更帅呢,大部分留给别人的都是狼狈的身影,这也能理解。 结果有个读者再次痛批 996,大意是:

996,互联网行业真的带了很垃圾的头,很多公司都这么明目张胆这么干,没有羞耻心,把程序员真当机器用,好的不学,坏的传播的很快。

这句话是不是政治正确不说,逻辑肯定有问题。 996 泛指长期过载加班状态,这是互联网行业带的头么? 没有互联网之前,我就知道,很多行业比我们这些在办公室敲敲键盘就以为改变世界的工程师辛苦多了。 我哥 94 年大学毕业,进入设计院,从一个工程师做到设计总工程师和院副总工程师,到现在依然不分节假日全国各地跑着做项目。 更多我们不熟悉的行业,比我们辛苦的多的是,只是那些群体不爱发声或者没地方发声而已。

至于把程序员当机器用,我工作了 20 年没遇上,我周边的朋友也没有一个是被当机器用的。 你可以说我是认知偏差,但国内外不少公司都是推崇工程师文化的,这个不是骗人的吧。 如果你没遇上,要么是公司的问题,要么是你的问题。

为什么会 996? 因为有需求,因为正常的工作节奏完不成工作,因为恐慌,就像技术进步、人类进化、社会发展一样,每一种形式都是对应需求出现的。 一棵大树突然出现在你家院子里,肯定不是凭空冒出来的。

996 最根本的原因是什么? 能力不足,或者说没有意识到自己的能力不足。

不仅是企业的能力不足,个人的能力也不足。 当一个公司的研发效率、组织结构、员工能力无法支撑起有效率的研发和产品工作的时候,996 这种畸形的东西就会自然而然的出现。

比如说 Code Review,实践证明了这东西一定可以提高效率和代码质量,但很多企业就是不做或做不好,为什么? 要么是驱动力不够,要么是能力不够。 做了没效果,还不如不做,出了 bug 只能加班解决。 我以前在各种团队里推动过 CR,效果都很一般,终于轮到自己做产品了,我告诉团队,我们必须把这件事做好,否则我们就不要做了。 现在我可以说,Code Review 在我们的团队研发中起到了至关重要的作用。

这只是冰山一角。 通过组织级的工程能力,团队的研发效能可以提升到一个不可思议的程度,比如:

这段话来自极客时间新上线的专栏《研发效率破局之道》中的内容,作者是前 Facebook 内部工具团队 Leader,最上面是我的评论。 看到这里估计你们会说,老池我信你个鬼,又要骗我买专栏了。 其实真不是。

我们在打磨这个专栏的时候就是关注研发效能,试图从效能模型、研发流程、工程方法、个人效率、工程师文化等角度帮助大家远离低效加班的场景。 为什么说不指望大卖呢? 我感觉大部分程序员个人意愿不算强烈,另外,团队 Leader 也可能有心无力,还是自己学好一门手艺要紧啊,所以架构、算法这样的课程会有四五万的订阅,这种类型的就会差不少了。

订阅量不高,那为啥要做呢?

因为以后能活下来的团队,肯定都是高效能的团队,大家在未来一定会越来越认识到研发效能的重要性。 无论是个人还是团队。 事实上无论是硅谷的顶级互联网公司还是国内的阿里华为小米,内部都有研发效能平台,如果你还在泥潭中挣扎,看看别人怎么做的,应该是非常明智的选择。我们希望为大家提供这样一个选择的机会。

扫码免费阅读最新的两篇更新,希望对你有帮助。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章