第448章 林眠的发现：加班时长与bug率呈诡异正相关曲线 (2/4)

他顿了顿。

“而刚刚提到的那三个人，过去一周累计产生了47个bug。其中12个是线上bug，已经造成了实际影响。保守估计，修复成本在8万到12万元之间。而他们三人这一周的加班，为公司创造了多少额外价值？”

他调出一张产出统计表。

三个人过去一周的代码产出量：比平均水平高15%。

但有效产出——也就是真正通过测试、能上线运行的代码——比平均水平低40%。

“所以实际上，”林眠总结，“他们不是在加班创造价值，是在加班制造损失。公司支付了1.5倍的加班费，换来了更多的bug和更低的效率。”

会议室里响起低低的议论声。

刘总监脸色难看：“我们产品部那边……最近的需求文档错误率也高了很多。有个产品经理把两个功能的需求写反了，导致开发做完了才发现要重做。”

运营部的一个经理点头：“我们也是。上周的活动策划案，数据算错了一个小数点，差点酿成大事故。”

“所以这不只是技术部的问题。”林眠说，“这是系统性疲劳导致的全方位质量下滑。”

他走到另一块白板前，上面贴着一张更大的图。

“这是我最担心的发现。”他的声音更低沉了，“我把全公司过去一个月的工作数据都跑了一遍，发现了一个……几乎是规律的现象。”

图上画着一条诡异的曲线。

它从零点开始，随着工作时间延长，bug率缓慢上升。但在某个点之后——通常是连续工作10小时左右——曲线开始加速。12小时后，斜率急剧增大。14小时后，曲线几乎垂直向上。

而在16小时处，图上标注了一个红色警告标志。

“连续工作16小时后，”林眠指着那个红标，“bug率是正常水平的6到8倍。更可怕的是，这时候产生的bug往往不是简单的逻辑错误，是架构层面的、可能引发系统级故障的重大缺陷。”

他调出几个案例：

案例一：某员工连续工作18小时后，“优化”了一个核心数据库查询，结果把“where”条件写反了，差点清空整个用户表。

案例二：另一个员工连续工作20小时后，在部署脚本里写错了一个ip地址，把测试环境代码部署到了生产环境，导致线上服务中断两小时。

案例三：销售部有个员工，连续加班三天后，在给客户的报价单上少写了一个零——把100万的合同报成了10万。幸好发现及时。

“这些不是‘不小心’，”林眠说，“是大脑已经丧失基础判断力的表现。就像你累到极致时，会把盐当成糖放进咖啡里——不是分不清盐和糖，是大脑根本没法处理‘分辨’这个指令了。”

会议室里安静得能听到空调出风口的声音。

苏早站在门口，静静听着。她看着林眠——这个穿着皱巴巴衬衫、眼睛里布满血丝的男人，正用最冷静的语气，说着最惊心动魄的真相。

她看到小李在角落做笔记，手有点抖。

看到小张撑着病体坐在后排，眼神复杂。

看到其他部门的人，脸上那种“原来如此”的恍然，和“我们也在经历”的苦涩。

然后她看到林眠转过头，看到了她。

两人的目光在空中交汇了一瞬。

林眠对她点了点头，继续转向白板。

“所以回到最初的问题：为什么‘007’行不通？”他重新打开第一张散点图，“因为人体不是机器。机器可以24小时运转，只要供电、散热、维护跟得上。但人不行——人的注意力、判断力、创造力，是需要恢复期的资源。强行透支，换来的不是更多产出，是更多错误，更多事故，更多……悲剧。”

他说“悲剧”两个字时，声音很轻。

但所有人都听懂了。

那个在icu的实习生，就是悲剧。

小张高烧不退，也是悲剧。

而这样的悲剧，正在以数据可以预测的方式，在全公司蔓延。

“林工，”刘总监开口了，声音干涩，“这些数据……能给我们产品部一份吗？我们需要调整排期节奏。”

“我也要一份。”运营部经理说，“我们要重新评估活动强度。”

“财务部也需要。”老会计推了眼镜，“如果加班反而增加成本，那我们需要重新测算项目roi。”

林眠点点头：“数据我可以分享，但有两个条件。”

所有人都看着他。

“第一，这些数据只能用于内部管理优化，不能外传——不是为了保护公司，是为了保护提供数据的员工。”

“第二，”他顿了顿，“下周一上午九点，陈董要开上市筹备扩大会议。我希望你们——如果认可这些数据的价值——能在会上，说出你们的真实感受。”

会议室再次陷入沉默。

这次沉默更长，也更沉重。

说出真实感受？

意味着要站在王总监的对立面，要质疑公司的“奋斗文化”，要在上市前的敏感时期，提出不和谐的声音。

风险太大了。