为什么很多公司（团队）会考核工时

听起来荒诞，但往下看完你会发现，这不是个别管理者的癖好，而是很多组织在考核和汇报压力下反复出现的选择。

没活也要 996：工时考核到底在证明什么

在程序员这个行业干久了，谁还没听过「考核工时」「卷工时」这种都市传说。

我自己在上家公司就经历过两个月的 996。

更魔幻的是：那段时间其实没那么多活。但部门负责人仍要求实行 996。后来小道消失听说是公司老板（一号位）觉得我们部门工作不饱和，部门领导为了证明我们很忙，要求大家**周六加班，并且每日有效工作时长不低于 9 小时（午休 2 小时 + 晚饭 1 小时排除不算）。

我印象特别深：没有邮件，没有公告，没有制度文件，就是悄摸摸把大家叫进会议室，口头传达。

后来周六来公司，也完全没工作的气氛，大家「齐刷刷摸鱼」，甚至摸得还挺有团队氛围。现在回想起来，有点好笑，但当时真挺无语。

笑过之后细想：这种明明没有产出的加班，为什么会被强推？后来我给它找到了名字——表演式加班。

对负责人来说，这甚至可能是一种自保：如果团队看起来不够忙，下一步可能就是缩编、削预算，或者被质疑管理失职。于是，员工是否真的创造了价值不再重要，重要的是团队必须呈现出「满负荷运转」的样子。

它表演的不是生产力，而是组织饱和度；观众也不是客户，而是更上一级管理者。

研发不是不能评价，而是不能用一个数字评价

我想，多数管理者至少在原则上承认：工时是投入，产出才是结果。但一进入实际管理，组织很容易又会退回到对投入的考核。

需要区分的是，记录工时并不一定不合理，把工时当成绩效才是问题。 咨询、外包、运维和值班岗位可能需要用工时核算成本或安排覆盖，但这不等于「工作时间越长，个人贡献越大」。

那么，用产出考核行不行？问题在于，研发工作很难找到一个既客观、又公平、还不容易被操纵的单一指标。

历史上很多人尝试过很多种考核方式，最后都失败了。用代码行数，会奖励冗余；用需求数量，会鼓励拆分任务；用 bug 数，会诱导隐瞒问题，或者惩罚那些主动接手复杂系统的人；用业务收益，又很难剥离产品、市场、销售和行业环境的影响。

这背后有一个普遍规律，即古德哈特定律：当一个指标成为目标，它就不再是好的指标。 人不会被动接受指标，而会主动适应指标，甚至围绕指标重新组织行为。

所以，研发产出不是完全不能评价，而是很难被压缩成一个数字。

需求交付、故障率、用户反馈、业务收益、系统稳定性，都可以成为评价证据，但没有任何一个指标能够单独代表研发人员的价值。更现实的做法不是寻找一个完美数字，而是使用一组相互制衡的证据：目标是否完成、交付质量如何、解决了什么问题、承担了多大复杂度、是否降低了长期风险，以及是否提升了团队整体效率。

管理者为什么偏偏抓住工时：量化焦虑

那么，既然单一指标靠不住，为什么公司还是抓住了工时？答案要到考核的执行者身上找。尤其是大厂的中高层管理者，普遍面临一种我称之为量化焦虑的东西。这种焦虑来自多重压力，而且每一条都挺现实：

1. 向上汇报。 老板要「数字」，不要「感觉」。当老板问「你们部门这个季度做了什么」时，「解决了很多问题」很难用于争取预算。在资源竞争中，无法被清晰呈现的价值，很容易被视为没有价值。

2. 绩效排序。 绩效体系需要区分员工，但研发工作又缺乏统一标尺。工时因此成为一种看似客观的证据，哪怕它和真实贡献之间的关系很弱。没有可量化的东西，完全凭印象，很容易被质疑不公平，甚至引发劳动纠纷。

3. 成本核算和团队保编。 工时还能帮助管理者证明团队处于饱和状态。如果工作量看起来不足，部门可能面临缩编和预算削减。因此，一些负责人不仅容忍工时膨胀，甚至会主动制造「全员很忙」的景象——这也正是我上文中那段 996 经历的由来。

   4. 控制感和责任规避。 结果往往滞后、复杂且充满不确定性，而工时可以实时监控。当项目失败时，「大家已经很努力、投入了很多时间」也能成为一种责任解释。工时提供的不只是数据，还有控制感和免责空间。

工时未必「最不坏」，但一定最省管理成本

既然产出难以量化，管理者在这种压力下就会抓住工时这根稻草。他们心里也很清楚：一个人坐在电脑前 10 小时的成果，甚至可能不如另外一个人认真干 2 小时（10X 工程师这个概念相信很多人都听过）。

但工时对管理者来说有几个非常具有诱惑性的优点：看得见、摸得着、好统计、好汇报。

在缺乏成熟评价体系的组织里，与其说工时是「最不坏」的选择，不如说它是管理成本最低的选择：不用理解任务差异，不用判断工作质量，也不用承担复杂评价带来的争议。

但管理者节省下来的评价成本，可能最终会以低效率、表演式加班、人才流失和错误激励的形式，由整个组织买单。只不过对于管理者来说，这笔账不记在自己名下，自然也就不那么心疼了。

用一个更贴近工程的类比，可以把这件事说得更直白：

工时考核有点像用「CPU 占用率」当作系统吞吐量的指标。CPU 占用率可以帮助发现系统负载，却不能单独说明系统创造了多少业务价值。同样，工时可以用于观察团队是否过载，却不应该直接用来评价个人贡献。

AI 会让旧指标进一步失真

这几年 AI 有了大跃进式的发展。有人可能会期待：AI 都能写代码了，量化是不是终于有解了？

我觉得答案恐怕是否定的。AI 正在显著降低部分代码的生成成本，但没有让可靠软件的交付成本趋近于零。需求澄清、架构设计、系统集成、测试验证、安全审查、线上维护和责任承担，仍然需要大量成本。AI 降低的主要是「生成代码」的门槛，而不是「交付可靠结果」的门槛。

一个 prompt 就能生成几千行代码，「代码行数」「需求数」瞬间失去意义——它们衡量的只是模型的吞吐量，不是人的价值。相比单纯实现，问题定义、方案取舍、结果验证和风险判断会变得更加稀缺。

而判断力这种东西，比产出更难量化。你没法统计一个人「做对了多少个决策」，即使统计了，对错也要三个月后才显现。

AI 让「生成」越来越便宜，却让「选择、验证和负责」越来越重要，而后者恰恰更难通过数量统计。

于是大概率出现的局面是：管理者比任何时候都渴望数字，而数字比任何时候都更不反映真实价值。在缺乏新的评价方式时，一些组织可能会更依赖在线时长、任务数量等旧指标来获得控制感。但这恰恰会进一步放大指标与真实价值之间的偏差——而且这种偏差，已经不只是某一家公司内部的管理问题。

把视角从单个公司往外拉，会发现工时问题并不只是考核方法选错了这么简单。即使一家公司完全明白上述道理，它也未必敢率先放弃工时考核——因为在行业竞争的环境里，工时膨胀早已不只是组织内部的管理选择，而变成了企业之间相互施加的外部压力。

工时膨胀为什么需要制度约束

「表演式加班」只是一个切面。从更宏观的角度看，至少在劳动者议价能力较弱、加班成本没有被企业充分承担的行业，工时膨胀仍然具有很强的惯性：

• 市场竞争激烈，企业竞相压成本、提效率，而延长现有员工工时是成本核算下「看起来最便宜」的选项——招聘意味着固定的薪酬和管理成本，但在加班成本没有被严格计算和支付时，多让人干几小时几乎不花钱。长期来看，疲劳、错误、返工、事故和离职会把这部分成本重新还给企业
• 手机电脑让工作无处不在，「下班」在概念上逐渐消失
• 就业供需失衡，企业话语权更强

于是出现恶性循环：企业发现员工能接受更长工时，就继续加码；其他企业看到同行加码，也跟进；最后整个行业的「默认标准」被抬高。

那身在其中的人该怎么办？话说回来，作为一个个人，说实话没有办法改变什么，因为我们本身也是这套规则和制度下的内卷受害者。我在之前的一篇文章（关于内卷，几个值得深想的洞察）中也写到了：

你在循环内部，能做的只是「更聪明地卷」，但很难做到「让大家都不卷」。因为只要你一个人退出，系统就会惩罚你。你可以说你定力强、没追求、不想卷。没事，规则会帮你「找到追求」。

工时内卷也是同一个结构：别人 996 而你准点下班，考核面前你就先输一半；「少干活」在个体层面几乎等价于「自愿吃亏」。这不是心态问题，而是博弈结构问题——系统把退出的代价压在了个人身上。

所以，指望员工用「个体觉醒」去对抗结构性的工时压力，本身就不现实。真正有效的改善，通常需要多种力量共同作用：法律明确工时边界并提高违法成本，劳动监察和司法保证规则得到执行，劳动者通过集体协商提升议价能力，企业内部则建立更合理的目标管理和申诉机制。

法律提供底线，组织治理决定日常，而个人选择只能在两者提供的空间内发挥作用。换句话说：让个体不再被迫卷，从来不是个体自己的功课，而是制度应该交出的答卷。

---

写在最后

公司考核工时，不只是因为研发产出难以量化，工时还满足了过程控制、成本核算、向上汇报和责任规避的需要。而程序员只是缩影，正如开头所说，很多岗位都面临同样的困境。

它对管理者来说简单、清晰、容易解释，却可能对组织产生错误激励：奖励低效率，惩罚高效率；鼓励表演，压缩真正思考和创造的空间。

研发工作确实无法被一个数字完整评价，但困难不等于不可能。目标、质量、业务影响、任务难度、协作贡献和长期价值，都可以构成评价证据。真正成熟的管理，不是找到一个完美指标，而是建立一套有证据、可校准、能申诉的判断机制。

工时可以用于观察负载，却不应该用来定义价值。

当组织无法衡量价值时，确实容易退而衡量时间；但这不是管理的必然，而是管理需要解决的问题。

推荐阅读

关于内卷，几个值得深想的洞察 https://mp.weixin.qq.com/s/vFuruhNRjL0MJHjEeM9aWg