OKR 对齐（Project-OKR Alignment）

参考来源：Google OKR Playbook、Intel OKR

适用场景

• 项目启动时验证战略对齐
• 季度规划时筛选项目
• 项目优先级决策
• 向用户/利益相关者解释"为什么做这个项目"

核心原则

项目计划必须能回答：
  "这个项目服务于哪个 OKR？"

如果答不上来：
  - 项目可能不该做
  - 或者 OKR 体系不完整

OKR 是"为什么做"
项目计划是"怎么做"
任务列表是"具体做什么"

OKR 结构

Objective（目标）
  - 定性的、鼓舞人心的目标
  - 描述"我们要去哪里"
  - 不可量化（量化的是 KR）

Key Results（关键结果）
  - 定量的、可衡量的结果
  - 描述"怎么知道我们到了"
  - 必须可量化（具体数字）

示例：
Objective：让新用户在第一天就理解产品价值
KR1：D1 激活率从 30% 提升到 50%
KR2：新用户首次完成核心操作的比例从 40% 到 70%
KR3：新手引导完成率从 25% 到 60%

Google OKR 规则

- 每个层级最多 5 个 Objective
- 每个 Objective 最多 5 个 Key Result
- 50%+ 的 OKR 来自下而上（不是全部老板定）
- 70% 完成率算成功（目标要有挑战性）
- 季度评估，不是月度

AI 工作流适配：
  - 项目层级：1~2 个 Objective
  - 每个 Objective 2~4 个 KR
  - 每周/每个里程碑评估进度

项目-OKR 对齐检查

启动前检查：
  □ 项目目标能映射到至少一个 OKR
  □ 项目完成后能推动 Key Result 进展
  □ 推动的幅度是可估算的

对齐检查矩阵：
  - 强对齐：项目直接推动 KR（贡献 30%+ 进展）
  - 弱对齐：项目间接支持 KR（< 30% 进展）
  - 无对齐：项目和任何 OKR 都对不上 → 质疑是否应该做

如果项目不对齐任何 OKR：
  → 问：这个项目真的要做吗？
  → 可能是技术债 / 紧急修复 / 探索性
  → 这些是合理的，但要明确标注"非 OKR 驱动"
  → 不能把所有项目都伪装成 OKR 驱动

项目 OKR 模板

## 项目 OKR 对齐声明

### 服务的公司/产品 OKR

**Objective**：[公司/产品级目标]

**Key Results**：
- KR1：[具体数字目标]
- KR2：[具体数字目标]

### 本项目的贡献

**项目目标**：[一句话描述项目]

**对齐的 KR**：
- KR1：本项目贡献预估 60% 进展
  - 预计影响：D1 激活率从 30% 到 45%（KR 目标 50%）
- KR2：本项目贡献预估 30% 进展
  - 预计影响：核心操作完成率从 40% 到 50%

### 验证机制

- 上线后 1 周复盘：实际数字 vs 预估
- 上线后 1 个月：完整 KR 进展评估

### 非 OKR 收益

- 改善代码质量（重构受益）
- 减少客服工单（次要收益）

项目级 OKR（独立项目）

某些项目本身可以有 OKR，特别是 XL 级项目：

## 项目 OKR：[项目名]

### Objective

让新用户在第一天就理解产品价值

### Key Results

| KR | 当前 | 目标 | 评估时间 |
|----|------|------|---------|
| KR1: D1 激活率 | 30% | 50% | 上线后 2 周 |
| KR2: 核心操作完成率 | 40% | 70% | 上线后 1 月 |
| KR3: 新手引导完成率 | 25% | 60% | 上线后 1 周 |

### 行动项映射

| KR | 任务 | 工作流 | 工期 |
|----|------|--------|------|
| KR1 | 注册流程优化 | frontend + backend | 2h |
| KR1 | 新手引导改造 | UI/UX + frontend | 4h |
| KR2 | 首次价值瞬间设计 | product-manager | 1.5h |
| KR3 | 引导步骤简化 | UI/UX + frontend | 1h |

OKR 评分规则（Google 标准）

完成度评估：
  0.0 ~ 0.3：失败（红色）
  0.3 ~ 0.7：进行中（黄色）
  0.7 ~ 1.0：成功（绿色）

例：
  KR：D1 激活率从 30% 到 50%（增加 20 个百分点）
  实际：达到 44%（增加 14 个百分点）
  完成度：14 / 20 = 0.7 → 成功

如果总是 1.0（100%）：
  → OKR 设得太低
  → 没有挑战性

如果总是 < 0.3：
  → OKR 设得太高，或方法不对

工作流程

1. 项目启动时：
   - 找到对齐的公司/产品 OKR
   - 写出对齐声明
   - 估算贡献度
   ↓
2. 如果不对齐任何 OKR：
   - 明确标注"非 OKR 驱动"
   - 记录原因（技术债/合规/紧急）
   - 决定是否要做
   ↓
3. 项目执行中：
   - 不需要持续看 OKR（专注执行）
   - 只在大变更时检查是否还对齐
   ↓
4. 项目完成后：
   - 评估实际 KR 进展
   - 对比预估
   - 沉淀经验（高估/低估的原因）
   ↓
5. 季度评估：
   - 所有项目对 OKR 的累积贡献
   - OKR 完成度评分
   - 调整下季度 OKR 和项目优先级

质量自检

□ 是否找到了对齐的 OKR
□ KR 是否可量化（不是"提升"而是"从 X 到 Y"）
□ 项目对 KR 的贡献是否可估算
□ 是否设置了验证时间点
□ 不对齐 OKR 的项目是否明确标注了原因
□ 评分是否真实（不是 100% 完成）

常见坑

1. 每个项目硬塞到 OKR——为了"对齐"扭曲项目本质
2. OKR 设得太低——总是 100% 完成，失去挑战意义
3. OKR 设得太高——总是失败，团队失去信心
4. KR 不可量化——"提升用户体验"不是 KR
5. 不评分——季度结束没人看 OKR 完成度
6. OKR 当 KPI——用于绩效考核会扭曲行为
7. 不调整——季度变化但 OKR 一年不变

配套模板

• templates/okr-alignment-template.md — 项目 OKR 对齐声明模板
• templates/project-okr-template.md — 项目级 OKR 模板
• templates/okr-review-template.md — OKR 复盘模板

与其他 skill 的协作

上游：
  公司 / 产品 OKR

平行：
  shape-up-cycles → 用 OKR 指导 Cycle 主题
  risk-management → OKR 风险（达不成的风险）

下游：
  retrospective → 复盘 OKR 完成情况