| name | okr-alignment |
| description | 确保项目对齐 OKR 战略目标时使用。适用于项目启动、季度规划、项目优先级决策。优先使用 Google OKR 方法 + 项目-OKR 对齐检查。 |
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% 完成）
常见坑
- 每个项目硬塞到 OKR——为了"对齐"扭曲项目本质
- OKR 设得太低——总是 100% 完成，失去挑战意义
- OKR 设得太高——总是失败，团队失去信心
- KR 不可量化——"提升用户体验"不是 KR
- 不评分——季度结束没人看 OKR 完成度
- OKR 当 KPI——用于绩效考核会扭曲行为
- 不调整——季度变化但 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 完成情况
