团队满负荷运转，增长也救不了

周一早上打开电脑，感觉已经是周四了。这不是熬夜之后的困，是另一种累。我认识的很多人都这样。

这让人想起《指环王》里的比尔博·巴金斯。离开夏尔之前，他对甘道夫说自己感觉像涂在太多面包上的黄油，被刮得又薄又撑。小时候读到这句，只觉得是个关于早餐的笑话。现在再看，它是对现代知识工作最准确的描述。托尔金是牛津教授，他懂。

增长本身不是问题

不少公司增长很快，同比两位数。按任何正常标准，这都是好生意。但团队的感觉仍然是在输。

把人当作资源来算，账是这样的：每个人都按100%分配，每周四十小时，全部计费，全部投入客户项目。没有余量，没有缓冲，也没有留给学习的时间。在一个每半年就自我更新的领域，这个选择很奇怪。

增长没有换来喘息空间，只换来了更多面包。黄油还是那么大。

我们不会这样对待一台服务器

没人会运行一个CPU占用100%的生产数据库，还称之为高效。那叫事故。

排队论解释了原因。最简单的模型是单服务器、任务随机到达，也就是M/M/1。在这个模型里，任务在系统中停留的时间随1/(1−利用率)增长。忙碌程度50%时，任务耗时是实际工作量的两倍；90%时是十倍；99%时是一百倍。它不是温和地增长，而是垂直上升。

人不是M/M/1队列，我们更糟。但形状是成立的。分配率达到100%时，任何意外都会变成积压。孩子生病、客户升级问题、周五下午四点五十五分的生产故障，没有容量吸收这些，于是被晚班和周末吸收。

我们给EC2集群留余量，把自动伸缩设在70%。我们知道零余量的系统不是高效，是脆弱。然后我们给团队排班时，好像从没听过这些。

有人会说，生成式AI让一切更快，黄油更多了。我每天都用这些工具，它们确实快。但再看一遍公式。利用率是流入的工作除以完成的工作。速度翻倍，流入的工作也翻倍，你又回到100%。更快的服务器不能解决队列问题，如果你只是更快地喂给它。经济学家称之为杰文斯悖论：蒸汽机效率提高后，英国烧的煤不是更少，而是更多。AI当然可以是更多黄油。但如果它省下的每个小时都变成另一个项目，我们什么也没解决，只是买了一条更大的面包。

零学习时间是带脉搏的技术债

最困扰我的不是工时，是那个零。零小时学习意味着唯一的学习方式是在客户的项目上，或者在自己的时间里。前者有风险，后者不可持续。

我们都理解技术债：为了赶上截止日期跳过重构，以后再付利息。跳过学习也一样。区别在于，利息在人身上复利。技能会过时，好奇心会安静下来。本可以想出下一个大东西的工程师，太忙了，忙着交付上一个。然后有一天，一个非常好的人更新了领英。那就是付款到期。

要么更多黄油，要么更少面包

只有两个办法：得到更多黄油，或者把它涂在更少的面包上。一些想法，都不新，都被忽视：

按80%规划，而不是100%。缺少的20%不是浪费，是吸收意外的余量，让意外不吞噬人。把学习放进日程表。每周四小时，受保护，不是“找到时间再说”。没人能找到时间，时间不在沙发底下。

把恢复算作产能。一个休息好的工程师一小时做的事，抵得上一个精疲力竭的工程师三小时。这不是软性话题，是算术。提前招聘。如果你增长很快，按去年的需求配置人员，保证今年每个人都紧绷。

比尔博没有优化他的黄油。他没有装更好的烤面包机，也没有采用新的面包框架。他离开了。他去了瑞文戴尔，坐在火边，写了一本书。我们大多数人没法跟精灵跑掉。但我们可以停止假装100%的团队是最好的团队。它不是。它离崩溃只差一个糟糕的星期。

如果你认识的人也都在耗尽状态，你没有想象。这不是个人失败，是容量问题。而容量问题，至少我们知道怎么解决。