【AI前沿】有毒职场正在炼成：OKR 变成 KPI，敏捷开发变成切碎的瀑布
Matrix精选2026年07月06日5 分钟阅读简单易懂的有毒职场炼成术主作者关注LOSSESRune 开发者，《当代学生生存手册》作者Your Professional Cyber Rubber DuckLOSSES关注LOSSESRune 开发者，《当代学生生存手册》作者Your Professional Cyber Rubber Duck联合作者关注LOSSESRune 开发者，《当代学生生存手册》作者Your Professional Cyber Rubber DuckLOSSES关注LOSSESRune 开发者，《当代学生生存手册》作者Your Professional Cyber Rubber DuckYour Professional Cyber Rubber Duck5 分钟阅读微信扫码分享以图片分享分享到微博点击下方按钮可复制链接分享收藏举报Matrix 首页推荐Matrix是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。文章代表作者个人观点，少数派仅对标题和排版略作修改。相信很多朋友都非常恨 OKR 和敏捷开发，感觉这东西就是给人找不舒服的。这类指标让人疲劳，有一种很强的失控感。这和我上学期上 Strategy & Management 这门课的感受很不一样。课上我们聊这些工具，它们就只是一个解决问题的工具。如果工具没问题，那么大概率用工具的人出了什么问题。业界比较荒诞的事情是，把 OKR 当 KPI 用，再把 Waterfall 切成 Sprint 假装敏捷开发。先来看 OKR，你应该听说过 OKR By Definition 就是让人感到有点「不舒服的」，因为它的设计初衷是让人只能完成 70%。一些很糟糕的管理者会同时用 OKR 自带的这 70% 特点来做绩效考核，把所有人都搞得非常疲乏。这很明确的是一种误用。在很多人的感受中，OKR 是一个考核框架，但它根本不应该有考核作用，它是一个用来设定目标的框架。目标（Objective）是方向，关键结果（Key Results）是衡量进展的里程碑。这套系统的设计意图是让整个公司都能朝着一个方向努力，避免失焦的出现。它的核心目的是推动业务变化。通常来说，KPI 用来监控公司现有业务的健康状况。一个公司的所有 KPI 指标都可以全绿，这意味着业务运转良好。但公司依然可能没有方向感，这个时候我们需要 OKR。OKR 告诉我们「下一步咱们要去哪」。OKR 系统设定一个组织需要努力的新方向，然后用一组可衡量的关键结果来确保所有人都在朝着这个方向前进。几乎所有管理学的教材都会告诉你，OKR 的员工自评应当与 KPI 考核有足够的间隔，并且明确的让员工知道 OKR 不与绩效挂钩，这才能让整个团队有安全感来进行自我挑战。当 OKR 的完成度和绩效奖金挂钩，员工的安全感荡然无存，它们会立刻开始保护自己。他们会设定自己有百分之百把握完成的目标。本来用来鼓励探索未知、挑战极限的工具，就这样变成表演忠诚的舞台。有野心的人设定了登月目标，完成了百分之七十，在评估体系里成了失败者。精于计算的人设定了踮脚就能够着的目标，完成了百分之百，成了优秀员工。OKR 变成了一种比 KPI 还没效率的东西。反过来也一样。你不应该拿 OKR 那套「完成七成就算成功」的心态去看待 KPI。没人能接受服务器在线率这种硬指标也能打七折（GitHub 除外？）。底线就是底线，这是 KPI 存在的意义。混用二者的结果是信用的破产。没人知道标准到底是什么，所有人都在猜老板的心思。再来看敏捷开发。敏捷开发的核心是短周期迭代、团队紧密协作，并且随时准备拥抱需求变化。「拥抱变化」常常被用来 Justify 产品需求的胡乱变动，这是另外一个让开发工作者感到疲劳的东西。其结果是我们同时得到了敏捷开发和瀑布开发当中最糟糕的东西。瀑布开发是一种自上而下的开发模式。这个模型认为项目的需求可以在动手之前就完全搞清楚，写成一份完美的文档。后续所有工作，就是忠实地执行这份文档。产品经理做产品调研，写需求文档。需求文档变成架构文档，然后开发执行，整个业务流是单向的。与之相反的，敏捷开发认为你不可能在动手之前就知道正确答案。项目的实际需求是在开发的过程中才被逐步发现的。所以敏捷每个 Sprint 结束时产出一个小的结果，都需要拿给用户看。用户体验完毕之后给出反馈，开发团队再用这个反馈来决定下一个 Sprint 该做什么。你可以想象，用户的反馈甚至可能会把之前的想法全部推翻。这是正版的「拥抱变化」。没有一个 Sprint 「被正确地执行了」这么个概念，一切都是边走边看。但在一个有毒的工作环境中，管理者会把瀑布模型切成一个个 Sprint。把一份巨大的计划书，分成了几个月来执行。每个周期结束的时候，汇报计划的执行进度。把瀑布切碎的假敏捷，只试图解决的是计划的执行效率问题。真敏捷要解决的是不确定性，这个不确定性来自外在世界的动态需求。团队要围绕这个事实来组织全部的工作流程。此外，「拥抱变化」常常被用来粉饰产品经理阴晴不变的个人品味、以及想不明白事情胡乱开车。「拥抱变化」这个概念被提出的初衷是允许需求在开发过程中随着「来自用户」的真实反馈调整。请注意，「真实反馈」来自用户，产品经理阴晴不变瞎改主意不是市场反馈，和敏捷开发的设立初衷毫无瓜葛。即使在正统的 Scrum 框架里，「变化」也有一个明确的容纳机制。一个 Sprint 的时长通常固定在两周到四周之间。在这个窗口期内，Sprint 目标和工作范围被严格锁定，任何人都不能在中途更改正在进行的任务。这种锁定的状态帮助开发者保护工作预期。产品经理可以随时更新 Product Backlog，但新的反馈必须在 Sprint 结束后才纳入下一轮，不能直接撞击正在开发的任务。敏捷开发底层是一种渐进式演变的逻辑，这种逻辑不会假设你在项目初期就能设计出完美的架构（of course you can’t）。它做出了更务实的假设，期待在每一个 Sprint 中通过持续重构来维护架构。重构是开发活动的组成部分，像呼吸一样频繁发生。开发者在实现新功能时，如果发现当前架构难以承载，会先通过重构调整代码结构，让架构长出支持新功能的能力。因此，每个 Sprint 都要做重构。在敏捷的定义里，一个功能只有在通过测试、完成重构、符合代码质量标准的情况下，才能算作「完成」。如果一个 Sprint 只顾着堆砌新功能而推迟重构，代码库会迅速产生技术债。这些债务会导致代码变得僵化，下一次需求变更的成本会呈指数级增长。持续关注技术卓越是敏捷的重要原则之一，重构就是保住这种卓越的具体手段。为什么简中圈子里很多人痛恨 OKR 和敏捷？我认为痛恨的标的并不是这两个概念本身，人们痛恨威权结构。OKR 和敏捷尝试向开发引入人本因素，但是一个原本就威权的体系里扭曲了这些人本追求的意含，将其转化为持续压榨的工具。开发者在成为人力「资源」之前，他们首先得是人。但很明显的，一些有毒的工作场所把人当成了 AI，又期待 AI 变成人。> 下载少数派 2.0 客户端，解锁全新阅读体验 📰> 简单、好用、专注的写作软件，少数派为你呈现 🚀Matrix首页推荐本文责编：@Lotta© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。31位派友已充电
By 大出海网采编
read more