相信很多朋友都非常恨 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 变成人。
Loading comments...