这个行业许多公司，996或者说加班文化似乎成为了一种常态。有赞凭借在年会宣布996工作制把自己推上了风口浪尖，这种跳出来公然996，颇有一种不想让你好好过年的架势。今天我就要把它批判一番，讲讲为什么要反对加班文化。不，其实并没有

“管理一群程序员，就如同放牧一大群猫”

上面这句话出自当年贝尔实验室的manager Barbara E. Moo（感谢评论区sinxccc大佬指正），你应该能发现说得似乎有些道理。很多管理者一再抱怨为什么项目频繁延期，为什么都996了但还是产出低下，为什么优秀的员工纷纷跑路，为什么傻X程序员每天要摸那么久的鱼等等。我相信不只是互联网行业存在这个问题，许多脑力劳动为主的行业都可能有类似的问题。你作为（一个技术团队的）管理者，如果把工程师们视为流水线上可以随时替换掉的工人，那么免不了有上面这些疑问。可是请问你有没有思考过，管理脑力劳动者与管理工人，到底有什么不同呢？

我建议你先在家里养上几只猫，好好体会一下，真的会有所感触。你会发现猫大部分时间都沉浸在自己的世界中，懒得理你

如果你不想养猫，那么可以试着读读这本书——《人件》。我读到此书也是机缘巧合，如果没记错的话那是很多年前我还在实习的时候，感到自己菜得一笔快要找不到工作，周末没事去福州路的上海书城闲逛寻找人生方向，书架上这本书奇怪的书名吸引了我的注意力。本想拿起来随手翻翻，结果居然在书店蹲了一下午，把整本读完了。不能说那时候对于这本书有什么理解，甚至都几乎忘记了书中讲了什么。而近日重温这本书，发现这几年工作下来，书中的各种观点居然得到一一验证。

这本书讲，在一个技术团队中，「人」的因素要比其他因素（比如技术）重要得多。

开发软件不是快餐店制作汉堡

书中最重要的观点就是：你不应该把开发软件项目和快餐店里流水线式制作汉堡视为同样的工作。如果你不幸就是这样认为的，那么你的管理方式将与能使生产力最大化的「最佳实践」背道而驰。

制作汉堡，有固定的生产标准，照着同样的标准做，不管什么人在什么地方都能做出品质和味道相差不多的产品。而你也总能够通过“典型的管理手段”来提高汉堡产量——比如996，比如把总是犯错的员工干掉，比如设立严苛的产量KPI。

但脑力劳动是无法标准化的，如果这个工作能够标准化，那么拿着同样的配方和流程，我们早就应该制造出品质如一的高质量项目了。

“程序员工作中占时间最长的是哪个步骤？” “聚气。”

所以你的工程师为什么每天看起来都在公司里摸鱼？因为他们实际上就是在摸鱼

真相是：对于软件工程师，每天能够集中精力写代码的时间并没有你想象得那么长。那么是不是觉得自己砸在研发上的钱血亏了？还不赶快来一发《创业公司要减员，应该选择前端还是后端？》。

软件开发是一种脑力劳动，大部分时间会花在「想」和「设计」上，而不是花在敲代码上。如果你发现你的程序员从早到晚都在敲打键盘，一刻都没有停歇过，那么你要调查一下他是不是不懂for循环。同理，作家或画家，也没有一刻不停的蹲在家里产出自己的作品。（你可以再去读读《黑客与画家》了）作为创作者，他们更多的时间是去观察，去体会这个世界，最后才以艺术的形式记录下来，而那只是之前所有工作都结束后所凝聚的精华。

“汝果欲学诗，工夫在诗外” ——《示子遹》陆游

当一个讲究的程序员是个挺累的活，即使手上没在写代码在干别的，或者休息日不上班走在路上，说不定由于潜意识的惯性，脑子里都在想着bug怎么修，架构怎么设计。而这可能是你所看不到的，你的眼里只看得到他们在摸鱼浪费工资。（当然也有不讲究的程序员，那确实就是在浪费工资了）

那为什么他们一大早到了办公室就开始摸鱼？因为真的是在聚气啊。你可曾听说过心流理论？简单来说就是你打游戏或者看剧看得入迷忘记了时间，这种完全沉浸其中的状态，就是最基础的心流体验。在这种状态下，工作效率是最高的，而对于软件开发这样的任务来说，心流状态甚至是必不可少的。

所谓的「聚气」就是把心情沉下来，忘记昨晚吃火锅发生了火灾为了逃命结果没吃几口之类的糟心事，再让大脑里那些与项目有关的知识激活起来，打开IDE找到昨天没改完的那段代码，撸起袖子准备开搞——

在这关键时刻，你冲过来吼了一嗓子——“小x啊，我们5分钟之后开个会！”

好嘛，咱这气算是白聚了。

如果你学过计算机，就会知道上下文切换是有开销的。而对于人类大脑这种“湿件(wetware)”，上下文切换花的时间尤其的长——请回想一下上学时你刚打完球，满头大汗地坐回教室里，要多久才能进入学习状态就明白了。

在办公室做开发工作糟心之处在于，随时都可能有人跑过来打断你，这样上下文切换几次，再去掉开会的时间，一天过去，实际的开发时间就没有多少了。

“这是什么？” “记录我被傻X打扰次数的计数器。”（按一下）

因此你可能会发现，有些程序员经常在上班时间躲在没人的角落（比如会议室）工作，或者干脆晚一些来上班，并工作到深夜。当你注意到这类现象时，首先应当思考，他们是否拥有合适的工作环境。

他们这样做并不全是由于程序员特立独行，而是因为他们太需要一个安静的工作空间、一段不受干扰的时间，来完成他们的任务。你应当意识到，他们在如此恶劣的环境下，竟然没有哭出来，而是仍在想方设法去完成工作。

所以不要急于给程序员们贴上自闭症或者夜猫子的标签，他们只是觉得你们太吵闹，甚至无法在这样的环境下完成工作，他们只是想找个地方静一静，把事情做完罢了。

“你们祈求，就给你们；寻找，就寻见；叩门，就给你们开门。” -- 馬太福音 7:7

你觉得不爽，恨不得他们一天24小时都在努力工作。然而，用什么来衡量绩效，你真的就能得到什么。所以996是个坏主意，如果你考察加班时间，就能得到员工拖延工作，使工作时间变长；如果你考察代码行数，就会发现有人开始复制粘贴更多代码进来甚至放弃使用循环语句；如果你考察代码注释覆盖率，说不定能得到一份中文汉化版的代码随源码附送——而这，真的是你想要的结果吗？

绩效考核这件事中有太多“我以为”，然而你以为的并不一定以为得对。在设定目标时，要慎之又慎，因为你真的能得到你想要的。太过形式化的考核，最终只能流于表面，你极有可能走得太远，以致于忘了为什么而出发。

你有一万种方法去压榨生产力，但唯独得不到高质量的产品和高效的团队

我的第一个老板发过一张充满电子包浆的图，我觉得有趣，就一直把这张图存在微信收藏里。

在团队工作时，也总是存在这样令人两难的平衡。但你的时间仿佛永远不够，你总是试图推动团队快一点，再快一点。可工程师是这样一种人，他们对于自己的项目质量有着极高的标准，（如果你发现你的工程师并不是这样的，那么先思考一下你的招聘环节是不是出了什么问题）当你强推进度的时候，他们仍不愿放弃质量，而是通过拼命工作，以一种自我牺牲的方式试图达成目标。

你看到的可能只是这个项目开发需要的结果——我们搞了个产品飞快上线。但你可能没有看到的是——团队被强推进度拖得疲惫不堪，效率低到不行；更严重的后果是团队直接分崩离析；而你本应得到保证的项目质量，由于工程师们长期处于压力之下，在不知不觉中被牺牲掉了。这在《人件》中被作者形容为“赢得战斗，输掉战争”。

我知道我可能没法说服你，但请你有空去看看系列纪录片《空中浩劫(Air Crash Investigation)》，飞行员都是经过了严格训练和考核培养出来的，可是你会发现，即便是如此训练有素的他们，在面对极端心理压力或者长时间超负荷工作的情况下，依然可能会犯下致命错误，酿成悲剧。

996之类的工作模式，在短时间内可能会提升产出，但从长远的角度来讲，带来的损害会比得到的要多得多。它如同一剂灵丹妙药，给深陷生产力不足这种「企业中年危机」焦虑的管理者带来了一个有病乱投医的机会。仿佛这样做就能解决一切问题，然而这只是试图用战术上的勤奋，掩盖战略上的懒惰罢了。

他们可能永远不会明白（或不愿相信），对于脑力工作者而言，时间的质量远比时间的数量重要。

好了，我的段子都讲完了，祝你新年身体健康。不管你是否认为我是在胡说八道，希望你都能去读一下这本《人件》，或许在书中，你能寻觅到这个迷局的破解之道。

我问小火，你以后当了老板会996吗？他说不会。我说，到那时候你说不定就想996了。

毕竟，真香是人类的本质。