目标与关键结果 (OKRs) 🎯#
什么是 OKRs？#
目标设定框架
OKRs（目标与关键结果）是我们用于协同团队和衡量进展的框架。Google、Intel 和领先的初创公司都在使用它，OKRs 能让每个人专注于最重要的事情。
| 组成部分 | 描述 |
|---|---|
| 目标 (Objectives) | 定性、雄心勃勃的目标，描述我们想要实现“什么” |
| 关键结果 (Key Results) | 3–5 个定量的、有时限的指标，用于衡量实现目标的进展 |
| 行动方案 (Initiatives) | 为实现关键结果而执行的具体项目和任务 |
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 每月下载量从 50 万增加到 100 万”）或二元结果 |
| 有时限 | 季度内的具体截止日期（通常为 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 个会分散精力 —— 必须果断确定优先级 |
| 设限保底 (Sandbagging) | 为了确保成功而设定容易实现的目标 |
| 任务清单 | 将 OKRs 与项目计划混淆（“发布功能 X” vs. “将用户参与度提高 50%”） |
| 缺乏定期签到 | 等到季度末才回顾进展 |
| 缺乏所有权 | 没有明确负责人和问责制的 OKRs |
| 季度中缺乏调整 | 当优先级发生变化时过于僵化 |
| 将 OKRs 作为绩效考核 | OKRs 是衡量团队进展，而不是衡量个人绩效的工具 |
透明度与可见性#
OKRs 在公司范围内可见
| 级别 | 位置 | 节奏 |
|---|---|---|
| 公司 OKRs | 全员大会，Slack | 月度回顾 |
| 团队 OKRs | Notion/Linear 工作区 | 站会 |
| 个人 OKRs | 与主管的 1:1 会议 | 每周 |
| 实时进度 | 实时仪表板 | 持续性 |
| 公开指标 | GitHub 星标，PyPI 下载量 | 持续进行 |
透明度能推动问责制并促进跨职能协作。
工具与资源#
OKR 通过以下方式管理：
- 季度规划会议
- 每周团队站会
- 进度跟踪仪表板
- 领导力评审会议