周末翻阅旧笔记时翻到了几年前写的一篇一直没发布的博客稿子可能是当时工作环境有点敏感吧探讨了一个很有意思的问题——为什么很多公司团队会考核工时。当时主要是从程序员视角写的但今天再看程序员其实只是这个现象的一个缩影从运营到设计从销售到中后台职能很多岗位都在经历同样的事——产出难以被看见工时却可以被统计。所以我把这篇旧稿翻新、扩写了一遍。下面的讨论虽然难免带着程序员的底色但问题的内核是通用的。一句话先说结论很多公司考核工时并不是因为他们真相信「坐得久产出高」而是因为产出难量化而工时又恰好能满足过程控制、成本核算和向上汇报的需要。它未必准确却最容易统计和解释。听起来荒诞但往下看完你会发现这不是个别管理者的癖好而是很多组织在考核和汇报压力下反复出现的选择。没活也要 996工时考核到底在证明什么在程序员这个行业干久了谁还没听过「考核工时」「卷工时」这种都市传说。我自己在上家公司就经历过两个月的 996。更魔幻的是**那段时间其实没那么多活。但部门负责人仍要求实行 996。后来小道消失听说是公司老板一号位觉得我们部门工作不饱和部门领导为了证明我们很忙要求大家周六加班并且每日有效工作时长不低于 9 小时午休 2 小时 晚饭 1 小时排除不算。我印象特别深没有邮件没有公告没有制度文件就是悄摸摸把大家叫进会议室口头传达。后来周六来公司也完全没工作的气氛大家「齐刷刷摸鱼」甚至摸得还挺有团队氛围。现在回想起来有点好笑但当时真挺无语。笑过之后细想这种明明没有产出的加班为什么会被强推后来我给它找到了名字——表演式加班。对负责人来说这甚至可能是一种自保如果团队看起来不够忙下一步可能就是缩编、削预算或者被质疑管理失职。于是员工是否真的创造了价值不再重要重要的是团队必须呈现出「满负荷运转」的样子。它表演的不是生产力而是组织饱和度观众也不是客户而是更上一级管理者。研发不是不能评价而是不能用一个数字评价我想多数管理者至少在原则上承认工时是投入产出才是结果。但一进入实际管理组织很容易又会退回到对投入的考核。需要区分的是记录工时并不一定不合理把工时当成绩效才是问题。咨询、外包、运维和值班岗位可能需要用工时核算成本或安排覆盖但这不等于「工作时间越长个人贡献越大」。那么用产出考核行不行问题在于研发工作很难找到一个既客观、又公平、还不容易被操纵的单一指标。历史上很多人尝试过很多种考核方式最后都失败了。用代码行数会奖励冗余用需求数量会鼓励拆分任务用 bug 数会诱导隐瞒问题或者惩罚那些主动接手复杂系统的人用业务收益又很难剥离产品、市场、销售和行业环境的影响。这背后有一个普遍规律即古德哈特定律当一个指标成为目标它就不再是好的指标。人不会被动接受指标而会主动适应指标甚至围绕指标重新组织行为。所以研发产出不是完全不能评价而是很难被压缩成一个数字。需求交付、故障率、用户反馈、业务收益、系统稳定性都可以成为评价证据但没有任何一个指标能够单独代表研发人员的价值。更现实的做法不是寻找一个完美数字而是使用一组相互制衡的证据目标是否完成、交付质量如何、解决了什么问题、承担了多大复杂度、是否降低了长期风险以及是否提升了团队整体效率。管理者为什么偏偏抓住工时量化焦虑那么既然单一指标靠不住为什么公司还是抓住了工时答案要到考核的执行者身上找。尤其是大厂的中高层管理者普遍面临一种我称之为量化焦虑的东西。这种焦虑来自多重压力而且每一条都挺现实向上汇报。老板要「数字」不要「感觉」。当老板问「你们部门这个季度做了什么」时「解决了很多问题」很难用于争取预算。在资源竞争中无法被清晰呈现的价值很容易被视为没有价值。绩效排序。绩效体系需要区分员工但研发工作又缺乏统一标尺。工时因此成为一种看似客观的证据哪怕它和真实贡献之间的关系很弱。没有可量化的东西完全凭印象很容易被质疑不公平甚至引发劳动纠纷。成本核算和团队保编。工时还能帮助管理者证明团队处于饱和状态。如果工作量看起来不足部门可能面临缩编和预算削减。因此一些负责人不仅容忍工时膨胀甚至会主动制造「全员很忙」的景象——这也正是我上文中那段 996 经历的由来。控制感和责任规避。结果往往滞后、复杂且充满不确定性而工时可以实时监控。当项目失败时「大家已经很努力、投入了很多时间」也能成为一种责任解释。工时提供的不只是数据还有控制感和免责空间。工时未必「最不坏」但一定最省管理成本既然产出难以量化管理者在这种压力下就会抓住工时这根稻草。他们心里也很清楚一个人坐在电脑前 10 小时的成果甚至可能不如另外一个人认真干 2 小时10X 工程师这个概念相信很多人都听过。但工时对管理者来说有几个非常具有诱惑性的优点看得见、摸得着、好统计、好汇报。在缺乏成熟评价体系的组织里与其说工时是「最不坏」的选择不如说它是管理成本最低的选择不用理解任务差异不用判断工作质量也不用承担复杂评价带来的争议。但管理者节省下来的评价成本可能最终会以低效率、表演式加班、人才流失和错误激励的形式由整个组织买单。只不过对于管理者来说这笔账不记在自己名下自然也就不那么心疼了。用一个更贴近工程的类比可以把这件事说得更直白工时考核有点像用「CPU 占用率」当作系统吞吐量的指标。CPU 占用率可以帮助发现系统负载却不能单独说明系统创造了多少业务价值。同样工时可以用于观察团队是否过载却不应该直接用来评价个人贡献。AI 会让旧指标进一步失真这几年 AI 有了大跃进式的发展。有人可能会期待AI 都能写代码了量化是不是终于有解了我觉得答案恐怕是否定的。AI 正在显著降低部分代码的生成成本但没有让可靠软件的交付成本趋近于零。需求澄清、架构设计、系统集成、测试验证、安全审查、线上维护和责任承担仍然需要大量成本。AI 降低的主要是「生成代码」的门槛而不是「交付可靠结果」的门槛。一个 prompt 就能生成几千行代码「代码行数」「需求数」瞬间失去意义——它们衡量的只是模型的吞吐量不是人的价值。相比单纯实现问题定义、方案取舍、结果验证和风险判断会变得更加稀缺。而判断力这种东西比产出更难量化。你没法统计一个人「做对了多少个决策」即使统计了对错也要三个月后才显现。AI 让「生成」越来越便宜却让「选择、验证和负责」越来越重要而后者恰恰更难通过数量统计。于是大概率出现的局面是管理者比任何时候都渴望数字而数字比任何时候都更不反映真实价值。在缺乏新的评价方式时一些组织可能会更依赖在线时长、任务数量等旧指标来获得控制感。但这恰恰会进一步放大指标与真实价值之间的偏差——而且这种偏差已经不只是某一家公司内部的管理问题。把视角从单个公司往外拉会发现工时问题并不只是考核方法选错了这么简单。即使一家公司完全明白上述道理它也未必敢率先放弃工时考核——因为在行业竞争的环境里工时膨胀早已不只是组织内部的管理选择而变成了企业之间相互施加的外部压力。工时膨胀为什么需要制度约束「表演式加班」只是一个切面。从更宏观的角度看至少在劳动者议价能力较弱、加班成本没有被企业充分承担的行业工时膨胀仍然具有很强的惯性市场竞争激烈企业竞相压成本、提效率而延长现有员工工时是成本核算下「看起来最便宜」的选项——招聘意味着固定的薪酬和管理成本但在加班成本没有被严格计算和支付时多让人干几小时几乎不花钱。长期来看疲劳、错误、返工、事故和离职会把这部分成本重新还给企业手机电脑让工作无处不在「下班」在概念上逐渐消失就业供需失衡企业话语权更强于是出现恶性循环企业发现员工能接受更长工时就继续加码其他企业看到同行加码也跟进最后整个行业的「默认标准」被抬高。那身在其中的人该怎么办话说回来作为一个个人说实话没有办法改变什么因为我们本身也是这套规则和制度下的内卷受害者。我在之前的一篇文章关于内卷几个值得深想的洞察中也写到了你在循环内部能做的只是「更聪明地卷」但很难做到「让大家都不卷」。因为只要你一个人退出系统就会惩罚你。你可以说你定力强、没追求、不想卷。没事规则会帮你「找到追求」。工时内卷也是同一个结构别人 996 而你准点下班考核面前你就先输一半「少干活」在个体层面几乎等价于「自愿吃亏」。这不是心态问题而是博弈结构问题——系统把退出的代价压在了个人身上。所以指望员工用「个体觉醒」去对抗结构性的工时压力本身就不现实。真正有效的改善通常需要多种力量共同作用法律明确工时边界并提高违法成本劳动监察和司法保证规则得到执行劳动者通过集体协商提升议价能力企业内部则建立更合理的目标管理和申诉机制。法律提供底线组织治理决定日常而个人选择只能在两者提供的空间内发挥作用。换句话说让个体不再被迫卷从来不是个体自己的功课而是制度应该交出的答卷。写在最后公司考核工时不只是因为研发产出难以量化工时还满足了过程控制、成本核算、向上汇报和责任规避的需要。而程序员只是缩影正如开头所说很多岗位都面临同样的困境。它对管理者来说简单、清晰、容易解释却可能对组织产生错误激励奖励低效率惩罚高效率鼓励表演压缩真正思考和创造的空间。研发工作确实无法被一个数字完整评价但困难不等于不可能。目标、质量、业务影响、任务难度、协作贡献和长期价值都可以构成评价证据。真正成熟的管理不是找到一个完美指标而是建立一套有证据、可校准、能申诉的判断机制。工时可以用于观察负载却不应该用来定义价值。当组织无法衡量价值时确实容易退而衡量时间但这不是管理的必然而是管理需要解决的问题。推荐阅读关于内卷几个值得深想的洞察 https://blog.csdn.net/xindoo/article/details/161368883