为什么说执行 996 工作制的脑力劳动者非蠢即坏

转载 Jun 14, 2020
本文转自云风的 BLOG

抱歉我用了这么个吸引眼球的标题。但我其实是想分析一下 996 工作制度到底存在怎样的问题。注意,我说的是身体力行执行 996 工作制的人,而非要求员工进行 996 工作的老板,这是两类人,今天我想骂的是前一类。

如果让我给执行 996 工作制下个定义,我想不能把全身心投入到工作和事业上的工作方式等同。它并不指工作时长;而是指刻意的制度性的把工作安排在非正常工作时间段。对待工作,不是以是否完成计划内的工作为衡量标准;而是本末倒置的先预设工作时长,然后想办法填满这些工作时间。

对于我最熟悉的游戏软件行业,它的工作本应该是脑力劳动为主。尤其对于程序员来说,主要的工作应该是在你的脑子里通过思考完成的,如果你的工作效率受限于每天不停的敲打键盘、移动鼠标、那么就变成了一项体力劳动。不久的将来,猴子和 AI 都能替你把事情干了。体力劳动或许可以通过制度性的延长工作时间来加快进程,可硬生生的脑力劳动变成体力劳动,只能用蠢来解释了。

如果工作的重点是通过大脑思考完成的,那么就不在乎你在什么时间,坐在哪里进行这些思考。甚至入睡前的那段时间都能想很多,限制每天在办公室坐上 10 多小时没有任何意义。那为什么说起来简单,996 反而成了国内程序员工作的普遍状态呢?我以最大的善意揣测人性,若他们不是心眼坏的话,那只能是大多数从业程序员能力欠缺了。

从游戏行业看,投资做游戏的人最期盼的是什么?并不是压榨你用更短的时间把游戏做出来,而是你能给个明确的计划时间表,在这个时间内保证质量的完工。这个时间可以比较长,但只要计划是明确的,就能估算出未来的收支情况。成功的游戏利润率非常之高,如果游戏能成功,用暴力手段压缩制作时间而减少的成本简直无足轻重。所以,游戏产品上线前,一改再改,无限延长开发时间反而是常态。

健康的项目,计划的落实是第一位的。那么最影响计划安排的是什么?不是工作时长,而是开发中的不确定因素:

顺利的情况下,一个人一天产生 300 到 500 行代码游刃有余。一个游戏程序最终的代码量,抛去一些机械产生的东西,由人的智力产生出来的不会超过 10 万行。这样算也就是 10 个人月不到的事。以现在动则十几数十个程序的开发团队,开发几年才能让游戏上线来看,绝大部分的工作都被废弃掉,或是意外产生的额外量。比如 Bug ,为一个 Bug 花掉 2,3 天时间,这种经历我想大部分程序都经历过;更常见的是改需求,不断地废弃掉已经完成的工作。项目完成后复盘的话,肯定会发现,如果一开始走了正确的路,能压缩掉一个数量级的项目开发时间。996 制度能增加多少工作时长?2 倍我觉得是极限了,再增加工作强度,影响到程序员的日常判断力的话,一定会大幅度的增加出错的概率。

所以,如果存在一个工作计划,那么就不可能事前规划出超长工作时间。因为你必须为不确定因素留出时间。因为经验原因未能按计划做完事情,说明能力不足,有改进空间。但既然是意外,就有顺利的时候,无论多糟糕的程序员,都有不出 bug 的日子,制度性延长工作时间对于落实工作计划毫无意义。

除非,程序员干的就不是智力工作。当我们把工作的智力因素无限降低的话,996 工作制度的确可以保障任务以更加稳定的时间周期完成。就好比你用计算器从 1 加到 100 ,只要你肯把 1 2 3 ... 100 依次按下去,总能得到结果,当你按了几十次按钮后,就能大致估计出全部按完 要多长时间;而寻找等差数列的公式、验证其正确性,然后用更快的方法得到结果,反而是不可控的。996 有效的前提就是:一定要找到最笨最机械的方法去执行,通常必须由蠢人来干,如果你不够蠢,就要把自己变得更笨一点;整个团队的智力在工作状态中拉到一条线上,就可以有条不紊的推进了。

我刚刚提到了团队,团队合作正是另一项重大的影响因素。

996 工作制度下,通常就是无休止的讨论、会议、头脑风暴等等。团队的工作相互依赖,你的工作需要我的工作先完成,我的工作需要交给他审核。团队规模越大,分工越细,越需要更多的人长时间待在一起。否则,做了一半的事情找不到上游或下游就无法开展下去。可是,受过基本训练的合格程序员都应该明白一个道理:越是复杂的项目,就越是需要不同部分(工作)模块的解耦。为了模块划分干净,可以不惜增加模块间的沟通成本。工作也是这样,随时可以找到人讨论问题并不是一件好事,它好比两个模块间事无巨细的反复调用对方的 api 。就算你全部实现都 inline ,开到 -O3 的优化,都未必高效。设计问题无法用精巧的实现弥补;工作规划的失误,无法用超长的工作时间抵消。我们应该容忍工作因为沟通延迟或失误造成的工作浪费,但不应该容忍无穷尽的讨论和会议浪费掉的时间。聪明人规划好计划后,会珍惜每次有限的沟通机会。

不轻易打搅别人应该是职业人应该具备的基本素养。这点至少我觉得自己是做到了的。记得 10 多年前,我有项目半夜出了 bug ,因为是非工作时间,即使 bug 不出在我编写的模块中,甚至我连代码都没看过。可我还是忍住不联系相关的同事,花了一个通宵阅读可能有问题的代码,并在天亮前修复;另一个项目在上线发布前一晚,一块关键数据除了问题,但是维护数据的人已经下班,修改数据的专有工具甚至没有人会使用(编写工具的人也下班了),我的选择不是联系负责的人,而是根据数据格式连夜重新编写工具,在用新写的工具修改错误的数据。举这样的例子,一是想说明,全心投入到工作中,和 996 不是一码事;二是想说,有能力有意愿加班做事是一回事,要求别人是另一回事。并没有那么多耽误不起必须在今晚完成的工作,如果你判断事情严重到必须当晚解决,那么就要具备独自解决问题的能力。如果你没有这个能力,第二天天也不会塌下来,好好做好下一段的计划,不要总是陷入这种僵局。

减少工作沟通并不是说不和别人沟通,闭门造车。反而应该在工作外的时间,尽可能地和不同的人交流,了解不同领域的人做了什么,采用了什么方法。这样才能开拓视野。工作中的许多困境往往都是因为陷入了思维定势,需要一个外部灵感帮你跳出来。和影响工作进程的各种偶然因素一样,捷径出现在眼前也是出乎意料的。你无法期待一个灵感能给你节省多少时间,但若你关上了门,每天干到睡觉,起来就奔赴办公室,也就关上了这扇门。


谈完了蠢,就想说说坏了。这个坏或许不是本心,但实质性的伤害了别人。

当人不能通过自身的技能完成任务,又无法提高自身达到要求。或许能做到的就是给自己降级,用更无智力含量,对技能无所要求的方法来做事了。这样对自己是最佳的选择,因为本质上 996 这种制度性工作才是最容易办到的事,无需思考,只用不停的敲打键盘即可,还能获得极大的自我满足。同时,这样可以把身边的同事,同行业的其他人也一起拖入泥沼。我做不过你,但我可以肝死你,恐怕是这一类人的心声了。

聪明的工作方式,需要团队一起都用聪明的方法来做事,每个人都勤于思考,找到高效的途径。通过独立思考,减少自己的错误产出(尤其是会影响到他人工作的产出)。但是,只要有一两个人做了坏事,就很难维持。比如,原本可以由一个人写一个 meta 模块解决一堆类似的问题,可一旦有一个人偷懒写下一坨狗屎只解决其中一个,并要求后面的人依照这个模板复制修改 10 份,那么工作就轻易的拓展到了 10 人份。最终的结果就是劣币驱逐良币,团队所有人都要趋向于用笨方式更稳健的做事。一旦脑力活动从工作中消退,就演化成 996 制度性长时间体力劳动。

不思进取的工作方式还会导致对自己的结果不做进一步思考,设计好的功能扔给别人实现,期待做好了再看效果;写好的代码不仔细自我检查,期待有测试人员把关,对坏味道无动于衷,等出了 bug 再改,反正干什么活不是干呢?debug 也不影响拿工资就是了。

如果一整个团队就这么下去,坏影响会蔓延到同业。因为无论这种工作方式效率多低,但是产出稳定啊。滥产品能做出来也是产品,也能占据市场,至于对市场是否有消极影响就无所谓了。暂时做不出好产品的团队,一旦忍受不了,最便捷的方式就是把自己降低到同一个水准上。正所谓把敌人拉到和自己一个水平,用自己最熟悉的手段击倒对手。这或许才是整个行业都充斥着 996 工作制的真相。

知识共享许可协议
本站文章除特别声明外,均采用 知识共享署名 - 非商业性使用 - 相同方式共享 4.0 国际许可协议 进行许可。
您的支持将鼓励我们继续创作!

Who Am I STEM Club

博罗中学 WAI 科技社官方账号

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.