2 篇博文 含有标签「okrs」

走进一个季度业务复盘（QBR）会议，问问谁的名字写在那个 AI 功能旁边。看看会发生什么。PM 指向平台团队。平台团队指向编写评估工具集（eval harness）的研究工程师。研究工程师指向那个一直在发关于成本图表邮件的 FinOps 分析师。FinOps 分析师又指回了 PM。四个人，一个功能，零个负责人。评估分数已经连续六周下滑，却无人排查，因为监控仪表盘躺在一个上次更新还是发布次日的 Notion 页面里。

这是 2026 年各组织交付 AI 功能最可预见的结果。该功能是由一个攻坚小组（tiger team）发布的，而该小组在发布新闻稿发出的那一刻就解散了。埋点是由一个没有产品授权的基础设施团队生搬硬套上去的。Prompt 是代码库中的一个 prompts/v3.txt 文件，其 Git blame 记录分散在九个工程师身上，谁也不记得为什么第 47 行要写那些内容。面向用户的入口由一位 PM 负责，但他的 OKR 在两个季度前就已经转向了下一个发布项目。这个功能在技术上处于生产环境，技术上有负责人，但在结构上已经沦为孤儿。

团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。

这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。