目标与关键结果（OKRs）🎯#
什么是 OKRs？#
目标设定框架
OKRs（目标与关键结果）是我们用于协调团队和衡量进展的框架。Google、Intel 以及众多领先初创公司都在使用 OKRs，它能让每个人专注于最重要的事项。
| 组成部分 | 描述 |
|---|---|
| 目标 | 描述我们想要实现的内容的定性且有挑战性的目标 |
| 关键结果 | 用于衡量目标进展的 3–5 个量化且有时限的指标 |
| 行动计划 | 为实现关键结果而执行的具体项目和任务 |
OKR 结构#
公司 OKRs
由领导层制定，明确季度或年度的战略重点。公司 OKRs 会逐级分解到团队和个人。
团队 OKRs
每个团队都会制定与公司目标一致的 OKRs，重点关注其领域对整体目标的贡献。
个人 OKRs
团队成员与经理协作设定个人 OKRs，同时支持团队和公司的目标。
OKR 周期#
graph LR
A["Planning\n(Week 1)"]:::start --> B["Execution\n(Weeks 2–12)"]:::proc
B --> C["Review\n(Week 13)"]:::proc
C --> D[Retrospective]:::proc
D --> A
classDef start fill:#4CAF50,color:#fff
classDef proc fill:#2196F3,color:#fff| 阶段 | 时间安排 | 行动 |
|---|---|---|
| 规划周期 | 第 1 周 | 为即将到来的季度设定 OKRs |
| 执行 | 第 2–12 周 | 通过每周检查跟踪进展 |
| 复盘 | 第 13 周 | 为 OKRs 评分并分析结果 |
| 回顾总结 | 复盘后 | 总结经验、进行调整，并将洞察延续到后续工作中 |
年度战略：公司层面的目标为季度 OKRs 提供指导 → 年终复盘评估年度进展 → 制定下一年度的战略规划。
OKR 最佳实践#
设定有效的 OKRs#
OKR 设计原则
| 原则 | 指导原则 |
|---|---|
| 有挑战但可实现 | 目标完成度设为 70–80%——如果达到 100%，说明目标设定得不够大胆 |
| 可衡量 | 明确的数值目标（例如，“将 PyPI 下载量从每月 500K 提升至 1M”）或二元结果 |
| 有时限 | 在季度内设定明确的截止日期（通常为 13 周） |
| 保持一致 | 目标从公司 → 团队 → 个人逐级分解 |
| 聚焦 | 每个层级最多设定 3–5 个目标，每个目标包含 3–5 个关键结果 |
| 鼓舞人心 | 每个人都应理解 OKR为何重要 |
| 透明 | 所有 OKRs 对全公司可见，以促进跨职能协作 |
评分等级#
| 得分 | 状态 | 解读 |
|---|---|---|
| 0.0–0.3 | 未达标 | 与目标相差甚远 |
| 0.4–0.6 | 取得进展 | 取得了有意义的进展，但未达到目标 |
| 0.7–0.9 | 成功 | 已实现或基本实现——这就是目标 |
| 1.0 | 超额完成 | 下一周期可能需要设定更具挑战性的目标 |
评分理念
得分 0.7 代表成功，而不是失败。如果你的团队持续得到 1.0 分，说明 OKRs 设定得不够有挑战性。
应避免的常见陷阱#
OKR 反模式
| 陷阱 | 失败原因 |
|---|---|
| OKRs 过多 | 超过 5 个目标会分散注意力——必须果断确定优先级 |
| 压低目标 | 设定轻易就能实现的目标，以确保成功 |
| 任务清单 | 将 OKRs 与项目计划混为一谈（“发布功能 X”与“提升用户参与度 50%”） |
| 检查频率过低 | 等到季度末才复盘进展 |
| 缺乏负责人 | OKRs 没有明确的负责人和问责机制 |
| 季度中途不做调整 | 在优先级发生变化时仍过于僵化 |
| 将 OKRs 用作绩效评估 | OKRs 衡量的是团队进展，而不是个人绩效 |
透明度与可见性#
OKRs 对全公司可见
| 级别 | 位置 | 周期 |
|---|---|---|
| 公司 OKRs | 全员会议、Slack | 每月复盘 |
| 团队 OKRs | Notion/Linear 工作区 | 站会 |
| 个人 OKRs | 与经理进行 1:1 沟通 | 每周 |
| 实时进展 | 实时仪表板 | 持续进行 |
| 公开指标 | GitHub stars、PyPI 下载量 | 持续进行 |
透明度推动问责，并促进跨职能协作。
工具与资源#
OKR 通过以下方式进行管理：
- 季度规划会议
- 每周团队站会
- 进度跟踪仪表板
- 领导层评审会议