最近程序员界出了一个新鲜事，github上出现了一个名为996.ICU的项目，以非常快的速度突破了1万星，目前的记录是夸张的18万颗星。这个事件引发了互联网界的广泛讨论，甚至引起了众多中国互联网企业的关注：

(众多国产浏览器屏蔽了对该项目的访问)

什么是996

中文维基百科对996的定义如下：

996工作制，是指一种早上九点上班，晚上九点下班，每周工作六天的用工制度，有时也被用来指代一系列资方要求劳方延长工时而不额外给薪的工作制度。

按照《中华人民共和国劳动法》的规定，劳动者每日工作时间不超过八小时，平均每周工作时间不超过四十四小时，而996工作制每周工作时间为七十二小时，远远超过劳动法规定的标准工时。

澄清几个概念

笔者要在这里澄清本文所描述的几个基本概念。笔者并不反对公司安排员工加班，事实上互联网行业是少数几个目前还在迅速发展的行业，几乎每年都会有新的技术、新的商业模式，这么多的技术方向、商业模式要实践，要验证，必然是会有加班的情况。

然而最近几年的996工作制已经不是简单的加班了。他们和普通的进度冲刺加班的区别在：

• 996是强制性的，进度冲刺加班则多数是自愿的

• 996是没有加班工资，没有调休的，进度冲刺加班则有加班工资或是调休

• 996的团队并没有节奏，而是要求持续地实行加班制度，而进度冲刺加班则是在项目需要赶进度时偶尔为之，DeadLine过去之后则要安排放慢节奏一段时间来舒缓

• 996的团队没有明确可执行的加班目标，进度冲刺加班有明显的可执行的加班目标

笔者反对996工作制，是反对前者，而非后者。

功利主义的反996

目前发起996.ICU运动的程序员以及大多数996工作制的反对者们立论的出发点都是捍卫劳动者权益、人权等，而同时又有不少996工作制的捍卫者们的观点认为高速发展的资本主义必然会带来长时间劳动，强有力的工会是产业乃至国家发展的障碍。

本文认为这两个人群完全不是讨论同一个问题，所以彼此没有认同对方的基础。笔者想站在功利主义的角度出发来谈谈为什么996工作制本身才是互联网产业乃至国家发展的障碍。

互联网行业本质上是软件行业的子范畴

互联网出现在上世纪90年代初，于千禧年发展到第一波高峰，中国互联网的大发展则是在那之后，以BAT为代表的互联网企业逐步成长成为巨头，进而渗透到社会的方方面面。但是互联网的本质依然是软件技术，它最依赖的仍然是软件开发技术。虽然很多公司团队都会说，互联网公司不可能像传统软件公司那样一板一眼地做事，互联网公司做事的速度必须更加快，但是软件工程领域积累了近半个世纪的规律、经验和教训，互联网行业也是适用的，它无法跳出规律自行运转。

焦油坑

上世纪70年代软件工程领域的恢弘巨著《人月神话》就探讨过相关的问题，为什么大量的软件项目都会延期交付？为什么向一个人手不足导致要延期交付的项目增派人手只会加剧延期的程度？为什么大量的软件团队就像是陷入沥青坑的史前巨兽一样，越是拼命挣扎越是深陷泥潭？

这部书的作者佛瑞德·布鲁克斯在十多年后的论文《没有银弹》当中更加清楚地阐明了道理：软件工程是人类迄今为止最为复杂的工程类别它的复杂性不仅来自于实现软件的技术或是框架，更来自于软件所要解决的问题本身蕴含的必要复杂度。就好比今天如果要开发一个财务软件，即使这种财务软件已经在历史上不知道被实现过多少个版本了，即使我们的开发团队都是久经战阵的资深开发人员，即使我们所使用的技术、框架、语言都是最好的，然而开发团队要理解的财务知识的复杂度是不会变化的，开发团队要学习这些知识，并且正确理解客户提出的需求所需要的努力也是不会变化的。所以任何单一的方法、工具都无法显著提升软件开发的效率。

为什么向一个可能延期的项目增派人手只会加剧延期？

原因很简单，软件工程有别于传统的工程学，软件开发成本很大的一个组成部分是沟通成本，团队成员之间的沟通，团队与客户的沟通，软件工程是一个重视人与人之间沟通的工程学。向一个可能延期的项目增派人手，只会进一步增加沟通成本，从而加剧项目的延期。

996的本质

996看上去是增加了技术团队的工作时长，从而提高了软件的交付速度，实际上并不是加速。996的本质是通过延长劳动时间，变相地向项目增派人手。在996的气氛下，技术团队成员由于疲劳，会倾向于减少彼此之间的沟通，闭门造车。我们都会有这样的经验，即与一个疲劳并且心情不佳的人进行有效沟通，难度远大于与一个精力充沛心情愉悦的人进行有效沟通。996实际上会以管理者意想不到的方式影响项目的如期交付。

质量——隐性因素

这是著名的“项目三角形”，意为一个项目在低成本、快速交付以及功能丰富这三者之间存在矛盾，不可能三者兼得。但是很多管理者会说，我们通过实施996工作制，在不增加人手（成本）的前提下，如期（时间）交付了我们预期的产品（范围），这怎么是不可能呢？

这是因为，项目三角形有一个隐性因素——质量被忽视了。在三者都要的前提下，团队势必只能通过忽视质量来满足三边要求。996团队看上去是“如期”交付了，但是质量由于是最难直观衡量的（相对于三角形三边来说），所以质量是最容易被偷偷牺牲的。交付一个低质量产品，算不算“交付”呢？

质量问题

软件质量重不重要？我们看一下几个案例：

• 1985年到 1987年期间，Therac-25 医疗放射治疗装置让成百上千的患者暴露在大量过量的辐射之中，少数患者接受了高达预期 100 倍的放射剂量。2000 年，巴拿马城也发生了同样的辐射剂量误差。原因是基于输入数据的顺序，治疗计划软件计算出并提供双倍剂量的辐射。

• 1998年美国宇航局发射了火星气候探测者号空间探测器，用于研究火星的大气层、气候以及表层变化。发射后第 286 天，进入火星轨道时失去了通讯。导航故障让火箭过于靠近火星大气层，从而导致燃烧并解体。任务失败的主要原因是人为失误。火星气候探测者号上的飞行系统软件使用公制单位牛顿计算推进器动力，而地面人员输入的方向校正量和推进器参数则使用英制单位磅力。这个因计量单位混淆的错误在此后的所有任务中被 NASA 小心地避免。

• 1999年英国护照办事处启用了一种新的计算机系统，而这种新系统无法及时向超过 50 万公民发放护照。后来办事处赔偿了数百万，员工也加班为在雨中排队等候护照的人们提供雨伞。办事处没有经过适当的测试，没有对员工进行有关新系统的培训，就推出他们的软件。另外，（与新系统同时发布的）新法律要求所有 16 岁以下的儿童在出国旅行时都要拥有一个护照密码。这就导致了护照需求瞬间激增，从而致使新软件系统负载过重。

• 2003年，黑暗在美国的八个州蔓延开来，影响了 5000 万人。该问题的源头是一个并发问题，这是一个单一操作中的两个独立线程使用同一个代码中元素的结果。

• 2012年8月1 日，美国股市开盘1 小时期间，纽交所的交易员感觉股票走势异常，部分股票的价格出现异常剧烈波动。当市场寻找原因之际，骑士资本便发表声明称，该公司的做市部门出现交易技术问题，影响了纽交所约150 只股票。美国做市商骑士资本由于技术故障在45 分钟内损失4.4 亿美元。事故的起因是当日纽交所NYSE 对交易系统升级，启动了Retail Liquidity Program 新交易系统。在收到通知后，骑士资本的开发部门更新了执行系统的相关代码，但在上线前并没有通过全面测试。骑士资本的系统中存在着一个已经被废弃不用了很长时间的软件模块，但是始终存在于交易系统之中没被删除掉。通常，这样的废弃模块在软件行业中被称为“死”模块。骑士资本的技术人员在为系统升级时本应该用新的软件模块替换“死”模块，但是阴错阳差的没有更换。8月1日早上交易系统开始运行的时候，在某一特定条件下触发计算机执行了这个 “死”软件模块，导致了事件的发生。

• 2015年9月1日阿里云出现大规模故障，客户的所有基本命令都不能运行。这次的故障是由于阿里云工程师粗心大意写错了一行代码，从而将所有新启动的可执行文件都当成了恶意文件进行隔离。

• 2016年2月17日，被日本寄予厚望的 X 射线天文卫星“瞳”成功发射升空，但仅仅一个月后，“瞳”与地面的通信出现严重故障，经地面光学望远镜测控发现其运行轨迹出现多块太空碎片。4月28日，日本宇宙航空研究开发机构（JAXA）正式宣布，无法恢复对X射线卫星“瞳”的操控，事故原因经初步调查源自底层软件错误。卫星的控制系统在发现飞行姿态失控时，采取了错误的调整，推进器点火时朝向了错误的反方向，导致自身旋转更加严重，最终彻底失控。

• 2018年6月13日上午，上海多家医院突遇医保卡无法结帐，患者只能自费付费。经组织紧急抢修，系统于14点10分恢复正常。

• 2019年1月20日凌晨，拼多多平台出现“优惠券Bug”，有媒体报道称，专职羊毛党发现了这个Bug，使用该优惠券后，可实现用0.46元充值100元话费，且可以通过新账号的方式无限制领券。直到20日上午9点，该优惠券的领取通道才被官方正式下架。

• 2019年3月10日，一架埃塞俄比亚航空公司客机从首都亚的斯亚贝巴起飞后不久坠毁，机上157人全部罹难。波音董事局主席米伦伯格首次明确承认了驾驶软件MCAS 有错。他通报说，根据埃塞俄比亚空难的初步调查结果，似乎是错误的传感器数据导致该软件系统被不必要激活。专为节油型波音737Max新款系列开发的MCAS软件程序原意在遇到特定飞行状态时-如飞机陡直上升-自动修正飞行迎角。然而，迄今的事故调查结果显示，该软件系统被错误激活，最终导致坠机。

软件质量很重要，并且有越来越重要的趋势。这些年互联网已经深度渗透到社会生活的方方面面，我们生活在一个被软件包围着的世界，软件控制了我们的吃穿住行，控制了城市的基础设施，控制了经济的运转，控制了人与人的沟通交流，控制了医院里病人的生死，控制了学生的人生前途，软件看不见摸不着，却又无处不在，软件就像空气一样不可或缺。

软件吞噬世界，而云正在吞噬软件。公有云，私有云，越来越多的系统被部署到了虚无缥缈的云端，越来越多的数据被存储到了云端，云计算厂商号称要做新时代的自来水厂、发电站，那么也要参照现实世界自来水厂、发电站的安保等级。

在中国一个非常有趣的现象是，我们一年当中几乎很难遇到几次大范围电力故障，但是我们每年必定会遇到几次全国范围的软件故障。可能是大范围断网，可能是公有云瘫痪，可能是聊天软件无法正常工作。其实“先进”的互联网公司的质量工程，是远远不如看似传统的国家电网的。

我们看到过自动驾驶的汽车撞死路人，我们看到了波音客机的死亡下坠导致两起惨烈的空难，我们看到了数十亿美元的资金由于软件问题瞬间灰飞烟灭等等等等。软件质量问题与你我其实息息相关。

996的根源

很多团队号称为了提升效率增加产出所以实施996工作制，实际上笔者了解下来，这当中很多的团队遇到的情况是这样的：集团或者母公司在当前的经济大环境下压力很大，很有可能要裁员。团队负责人害怕被裁撤，所以强制自己的团队实行996工作制，想着没有功劳也有苦劳，没有苦劳也有疲劳，希望能够通过玩命表现让裁员的注意力不要集中到自己身上。本质上还是因为业务或者产品不盈利，处在公司业务的边缘地带。

为什么要反对996

要实施996，应该先问一下自己，以下这些措施我们都做了没有：

• 自动化测试

• 持续集成

• 持续部署

• 持续交付

• 代码静态分析

• 代码审查

……

如果一样都没做就实施996的团队，你们的管理者是蠢货，一个蠢货带领的团队能有什么样的战斗力呢？

如果你的部门、产品不盈利，处在公司业务的边缘地带，是不是团队996工作就能扭转这个局面呢？

我们的产品设计流程是否科学？是不是拍脑袋拍的需求？我们在团队培训上投入了多少资源？我们的开发团队是否用的是最好的工具？我们的方法论是否高效率？

强制执行996工作制，一方面使得团队陷入一种疲劳的状态，一方面暗示团队通过牺牲质量来加速完成目标，最后只能产出低质量的产品。

笔者基本可以肯定地说，996是管理者能够采用的最偷懒的方法，也就是上述所有方法论都懒得学习、实践，单纯地幻想延长团队工时就可以得到更多的产出，本质上是管理者的无能与愚蠢。采用996，就是公开承认自己的管理团队是愚蠢的。采用996，就是公开宣布我们不在乎质量，我们交付的是低质量的产品。

采用996，就是公开告诉客户和用户，软件质量无所谓，我们不在乎你们的死活，我们只想要你掏钱。

当我们反对996的时候，我们实际上反对的是愚蠢和低能。

从为企业考虑的角度，从功利主义的角度，我都认为公开实行996是一次公司公关的灾难，其恶劣影响经久不散。996的企业在发展壮大的过程中，在招聘的过程中，势必要为996付出溢价，而互联网企业最大的成本开支就是人力成本。公开宣布996工作制从长远看长期增加了自身最大的成本开支，降低了自身的竞争力，无疑于买椟还珠，引鸩止渴，自取灭亡而已。

站在客户的角度，不要把关键业务和数据交到实行996工作制的企业的产品上去，因为这些产品几乎无一例外的都是低质量的产品，将来终有一天它的低质量会使你付出代价。

最后

随着5G、物联网技术的成熟和普及，我们的生活势必将要更加依赖于各种各样的软件，我们会深深地陷入一个软件构成的热带雨林里。如果互联网企业软件企业继续朝着996所代表的低质量软件的道路发展下去，那么我们所有人连带这个社会，将会陷入一个越来越糟糕，越来越阴暗潮湿闷热，臭气熏天的热带沼泽式雨林，那将是我们所有人万劫不覆的地狱般的环境。