---
name: report-okr
description: 生成团队OKR文档，完整覆盖三种场景：①OKR制定（新周期O/KR/KA拆解）、②OKR进展汇报（双周/月度执行状态同步）、③OKR复盘（周期结束回顾与洞见提炼）。当用户说"写OKR"、"制定OKR"、"写季度OKR"、"OKR进展汇报"、"双周进展"、"月度OKR检查"、"OKR复盘"、"写KR分解"、"季度OKR复盘"时触发。注意：个人述职中的年度总结请使用 report-review；本 skill 专注于团队/组织维度的OKR文档。核心逻辑：OKR不是任务清单，而是方向判断+结果承诺+执行信号的结合体；好的OKR能让读者5分钟内明白"这个团队在做什么、做到什么程度、为什么这么做"。
metadata:
  author: archon
  version: "2.0"
---

# report-okr — 团队OKR文档

## 先弄清楚你要写什么

OKR 这个词在不同场景下指三件完全不同的事，写法差异很大：

| 场景 | 你要产出什么 | 典型触发词 |
|------|------------|----------|
| **OKR 制定** | 一份新的季度/年度OKR（含目标定义+KR拆解+KA分解） | 写OKR、制定OKR、定季度目标 |
| **OKR 进展汇报** | 反映当前执行状态（含数据指标+双周/月度进展+归因） | 双周进展、月度OKR汇报、OKR进展 |
| **OKR 复盘** | 周期结束时的回顾（含达成vs目标+根因+经验沉淀） | OKR复盘、季度复盘、OKR总结 |

**入口问题：** 先问用户是哪种场景，再进入对应流程。

---

## 场景一：OKR 制定

### 核心原则

OKR 制定最常见的问题：**把任务清单写成了OKR**。

区别在于：
- ❌ 任务清单：「完成X功能开发」「推进Y项目上线」「做Z调研」
- ✅ OKR：「[方向判断] → [结果承诺/量化指标] → [核心打法]」

好的O（Objective）必须回答：**我们为什么要做这件事？做成了之后，团队/用户/业务会发生什么变化？**

好的KR（Key Result）必须回答：**怎么证明O达成了？** KR是可观测的结果，不是动作。

好的KA（Key Action）是KR的执行路径，是动作而非结果，用来说明"我们打算怎么做到KR"。

### Step 1：信息收集

向用户确认：

1. **周期**：季度？半年？年度？
2. **受众**：团队内部 / 直属上级对齐 / 公司级评审？
3. **核心方向**：这个周期团队最重要的1-3件事是什么？（用自然语言描述即可，不必是OKR格式）
4. **上下文**：
   - 上一周期的主要成果和未完成项（复用而不是重复出发）
   - 上级OKR是什么？（需要映射对齐）
   - 有哪些已知的外部约束/资源限制？
5. **团队规模和角色分工**：谁负责哪块（影响KA分解的颗粒度）

### Step 2：结构化OKR

#### 整体文档结构

```
[团队名] [周期] OKR

├── TL;DR（如面向高层则必须有）
├── O1：[目标一]
│   ├── 背景与战略对齐
│   ├── KR1.1：[关键结果]
│   ├── KR1.2：[关键结果]
│   └── KA分解
│       ├── KA1：[关键行动] — 负责人 — 关键节点
│       └── KA2：[关键行动] — 负责人 — 关键节点
├── O2：[目标二]
│   └── ...
└── 风险与依赖
```

#### O（Objective）写法

**格式**：`【领域标签】` + `方向判断句`（动词开头，描述变化或达成状态）

写法参考：
- ✅ `【业务效果】通过AI能力驱动核心业务指标提升`
- ✅ `【基础效能】建立AI Native研发范式，显著提升研发效率`
- ❌ `推进AI相关工作` ← 没有方向判断
- ❌ `完成AI项目建设` ← 是动作不是方向

**O 写好的检验标准**：
> 去掉所有数字和技术细节，你的O还能让一个不了解团队的人，理解"这个周期这个团队最重要的方向是什么"吗？

#### KR（Key Result）写法

**格式**：`[指标/状态描述] [量化目标] [可选：基准值]`

写法参考：
- ✅ `AI检测漏洞准确率 ≥ 80%，覆盖23种Java漏洞类型`
- ✅ `研发范式L2占比达45%，L3占比达5%`
- ❌ `推进AI+漏洞检测` ← 是行动不是结果
- ❌ `AI能力有所提升` ← 无法验证

**KR的4个必要属性**：
1. **可观测**：存在明确的数据源或验证方法
2. **有时限**：在本周期内能完成验收
3. **有基准**：知道从哪里出发（现状是什么）
4. **和O强相关**：完成这个KR，O就显著推进了

**KR数量建议**：每个O对应2-4个KR，超过5个说明O太宽泛或KR颗粒度太细。

#### KA（Key Action）写法

KA是对KR的执行路径分解，需要：
- 每个KA对应一个明确负责人
- 有关键节点/里程碑（至少季度内的关键时间点）
- 能说明"这个KA做完，对应KR就完成了"的因果逻辑

**KA分解表格格式**：

| KA | 内容 | 负责人 | 关键指标 | 关键节点 |
|----|------|-------|---------|---------|
| KA1 | [具体行动描述] | [姓名] | [可量化的子指标] | [时间节点+里程碑] |
| KA2 | [具体行动描述] | [姓名] | [可量化的子指标] | [时间节点+里程碑] |

#### TL;DR（面向高层时必须有）

```
📌 核心方向：[一句话概括本周期最重要的方向判断]
🎯 战略对齐：[承接的上级OKR，一句话]
📊 关键指标：[2-3个最能代表成功的数据目标]
⚡ 核心打法：[一句话概括怎么做]
🚦 需要决策：[需要上级拍板的事项，如有]
```

#### 战略对齐声明（面向上级时必须有）

在每个O的开头，用1-2行明确：
> 「本目标承接 [上级OKR/公司战略方向]，核心贡献路径是 [本O → 上级KR的因果关系]。」

---

## 场景二：OKR 进展汇报

进展汇报的核心不是"告诉大家做了什么"，而是：
**让读者5分钟内判断：项目在不在轨、哪里有问题、需要做什么决策。**

### 汇报节奏与格式选择

| 节奏 | 适用格式 | 重点 |
|------|---------|------|
| 双周 | 精简格式（数据+Highlight+风险） | 信号传递，不需要完整叙事 |
| 月度 | 完整格式（数据+进展+归因+调整） | 判断是否需要调整方向 |
| 季度中期 | 深度格式（达成预测+战略重检） | 是否需要重新制定OKR |

### 进展汇报结构

#### 一、数据指标通晒

**1.1 核心KR达成情况总览**

| KR | 目标值 | 当前值 | 达成率 | 状态 | 趋势 |
|----|-------|-------|-------|------|------|
| [KR描述] | [目标] | [当前] | [%] | 🟢/🟡/🔴 | ↑/→/↓ |

状态说明：
- 🟢 在轨：按预期进展，无需干预
- 🟡 有风险：偏差可控，需关注
- 🔴 不在轨：需要介入决策或调整策略

**1.2 各子团队/FT数据分布（如有）**

| 子团队/FT | 负责人 | 关键指标 | 当前值 | 归因说明 |
|----------|-------|---------|-------|---------|
| [FT名] | [负责人] | [指标] | [数值] | [归因] |

归因说明的写法原则：
- ❌ 「数据波动，待观察」← 没有任何判断，等于没写
- ✅ 「本期因[具体原因]导致指标偏低，预计[时间]恢复，判断依据是[X]」
- ✅ 「超预期，归因是[具体动作]带来了[具体效果]，可复制到[Y场景]」

#### 二、各KR/KA进展

每个KR的进展汇报结构：

```
### KR[N]：[KR描述]
负责人：[姓名]

📌 进展Highlight：
- [最重要的1-3个进展，用结果句而非动作句]

KA推进详情：
| KA | 状态 | 本周期进展 | 关键节点完成情况 |
|----|------|----------|--------------|
| KA1 | 🟢/🟡/🔴 | [进展] | [是否按时] |

风险与决策需求：
- [风险描述] → [需要的支持或决策]
```

**Highlight 的写法**：
- ❌ 「完成了X功能开发」← 是动作，不是结果
- ✅ 「X功能上线，当前覆盖N个场景，检出率达到Y%」← 有结果和数据
- ✅ 「完成MVP跑通，验证了[核心假设]，下一步进入[阶段]」← 有里程碑意义的进展

#### 三、整体节奏判断

基于数据和进展，给出判断：

```
### 本周期节奏判断

**整体状态**：[在轨 / 局部有风险 / 需要调整策略]

**核心判断**：[1-2句，说清楚整体进展是否符合预期，最重要的信号是什么]

**需要关注的信号**：
- [信号1]：[意味着什么，建议动作]
- [信号2]：[意味着什么，建议动作]

**需要决策的事项**：
- [事项]：[背景] → [选项A vs 选项B] → [建议选哪个，理由]
```

---

## 场景三：OKR 复盘

复盘的目的不是「交作业」，而是从执行过程中提炼出对下一周期有用的判断。

复盘最大的问题：**成了「流水账式的成果罗列」，没有诚实的根因分析，没有对下一周期的洞见输出。**

### 复盘结构

#### 一、OKR达成总览

| KR | 目标值 | 实际达成 | 达成率 | 自评 |
|----|-------|---------|-------|------|
| KR1 | [目标] | [实际] | [%] | ✅完成/⚠️部分完成/❌未完成 |

**自评标准**：
- ✅ 完成：达到或超过目标值
- ⚠️ 部分完成：达成70%-99%，或完成了主体但有缺口
- ❌ 未完成：低于70%或核心交付缺失

#### 二、关键成果与亮点

**写好成果的原则**：结果 + 量化 + 意义

- ❌ 「完成了X系统建设」
- ✅ 「完成X系统建设，支持N种场景，上线后检出率提升Y%，节省人工Z小时/月」

每个核心成果用以下格式：

```
**[成果标题]**
做了什么：[具体动作]
产出：[可量化的结果]
意义：[对OKR/业务/团队的价值]
```

#### 三、未完成项分析（诚实最重要）

对每个未完成或部分完成的KR，做诚实的根因分析：

**分析框架（选1-2个最真实的根因）**：

| 根因类型 | 典型表现 | 建议复盘问题 |
|---------|---------|------------|
| 目标设定问题 | 目标脱离实际，初始就很难达到 | 目标是基于假设还是已有数据？假设被验证了吗？ |
| 执行节奏问题 | 事情做了但太晚 | 关键路径有没有前置识别？依赖项有没有及时拉通？ |
| 资源问题 | 人力/时间不够 | 资源分配和目标有没有在初始就对齐？ |
| 外部变化 | 外部环境/需求变化导致方向调整 | 这个变化是否不可预见？下次如何早识别？ |
| 优先级冲突 | 被更紧急的事情挤占 | 优先级判断是否合理？哪些事本可以不做？ |

**格式**：

```
**[KR描述]** — ⚠️/❌
现状：[实际达成情况]
根因：[选1-2个最真实的根因，具体不泛化]
经验：[如果重来，哪个决策会不同？]
影响：[对下一周期有什么影响？]
```

#### 四、经验与洞见

这是复盘最有价值的部分，也是最难写的部分。不是「总结了N条经验教训」，而是**团队认知的真实变化**。

格式：

```
**洞见1：[洞见标题]**
之前的认知：[本周期初期我们认为...]
实践发现：[但实际上...]
下一周期的影响：[所以我们会...]
```

#### 五、下一周期的输入

基于复盘，给出对下一周期OKR制定的具体建议（不是口号）：

```
**建议延续**：[效果好、应该继续的方向+策略]
**建议调整**：[方向、指标或打法需要变化的地方，说明为什么]
**建议放弃**：[明确建议不继续投入的方向，说明理由]
**新增关注**：[本周期发现的新机会或新风险，建议下一周期纳入OKR]
```

---

## OKR 写作的通用陷阱

### 结构层面
- ❌ O是任务清单：把「完成X」写成目标，不是方向判断
- ❌ KR是行动：「推进X」「建设Y」是KA，不是KR
- ❌ KR无法验证：没有量化指标或明确验收标准
- ❌ KA没有负责人：集体负责等于没人负责
- ❌ O太多KR：每个O超过5个KR，说明O太宽泛或KR颗粒度太细

### 进展汇报层面
- ❌ Highlight写动作不写结果：「完成了X」vs「X上线，效果是Y」
- ❌ 归因写「数据波动，待观察」：等于放弃判断
- ❌ 风险写了但没有建议动作：读者看完不知道需要做什么
- ❌ 只列进展不给整体判断：读者需要你的判断，不只是信息

### 复盘层面
- ❌ 成果流水账：罗列20个成果，没有重点
- ❌ 未完成项轻描淡写：只说「外部原因」不做内部反思
- ❌ 没有洞见：经验总结都是「要加强沟通」「要提前规划」这种通用套话
- ❌ 下一周期输入和复盘脱节：复盘了一堆，建议里都是新的方向和目标

---

## 参考文件

- [通用风格规范](../references/style-guide.md)
- [汇报对象适配](../references/audience-guide.md)
- [OKR文档模板（制定/进展/复盘）](assets/templates/okr-template.md)
- [OKR写作常见问题诊断](references/okr-diagnosis.md)