---
name: report-kickoff
description: 生成横向协作项目启动文档（KO文档）。当用户说"横向协作"、"写KO文档"、"项目启动会"、"拉通文档"、"跨团队对齐"、"写协作方案"、"项目KO"、"拉齐文档"时触发。核心逻辑：先建立「为什么大家都需要这件事」的共同目标，再明确各方角色、贡献和收益，最后建立协作机制。必须照顾到所有参与方的利益，不能只从主导方视角讲。
metadata:
  author: archon
  version: "1.0"
---

# report-kickoff — 横向协作 KO 文档

## 零、TL;DR（所有 KO 文档必须有）

KO 文档在会前发给多个参与方——每个团队负责人看到的第一件事是"这件事和我有什么关系"。TL;DR 必须在30秒内回答这个问题。

**TL;DR 内容构成**（5行以内）：

```
🎯 共同目标：[一句话说清楚这件事要实现什么，用"我们"而不是"我"]
👥 参与方角色：[列出各团队的核心角色，1行每方]
📅 关键里程碑：[2-3个最重要的时间节点和交付件]
⚡ 为什么现在：[一句话说清楚时机判断——不做的代价]
🚦 需要决策：[在KO会上需要确认的事项，如有]
```

**TL;DR 写作原则**：
- 每个参与方看完 TL;DR 后，应该能回答：「这件事我需要做什么，我能得到什么」
- 不能只写主导方的目标——所有参与方的角色和收益都要可见
- 「共同目标」必须用「我们」开头，不能是「我方需要...，请各方配合」

---

## 核心原则：对方的 gain 优先于我方的 need

横向协作最常见的错误：从主导方视角出发，把 KO 文档写成「我要做X，需要你们配合」——这会让协作方感觉是在被动支持别人的项目。

**正确视角**：先说清楚「为什么大家都需要这件事」，让每个参与方看到「这件事对我有什么好处」，才能建立真正的协作意愿。

**关键问题**：如果一个协作方问「这件事如果我不参与，对我有什么影响」，你能回答清楚吗？

---

## 写作前必须收集的信息

向用户确认以下内容：

1. **项目背景**：这件事要解决什么问题，为什么现在要推
2. **参与方清单**：哪些团队需要参与，每个团队的负责人是谁
3. **各方角色**：每个参与方在这个项目里做什么（不能都是「配合」）
4. **各方 gain**：这件事对每个参与方有什么具体好处
5. **各方 cost**：每个参与方需要投入什么（人力/时间/资源）
6. **决策机制**：谁是决策者，分歧怎么解决，升级路径是什么
7. **里程碑**：关键时间节点和每个参与方的交付件

---

## 文档结构

### 一、背景与共同目标

📌**核心要求**：用「我们」而不是「我」，体现这是一件大家共同需要的事。

**1.1 为什么要做这件事**

- 现在的问题是什么（对所有参与方都有影响的问题）
- 不做的代价是什么（对各方分别意味着什么）

**1.2 共同目标**

> 「通过[项目名]，我们共同实现：[目标]。」

量化：[目标值 / 衡量方式]

**1.3 为什么现在做**
- 时机判断：为什么是现在，而不是更早或更晚

---

### 二、各方角色与利益

⚠️**每个参与方都要有自己的「收益」，不能只有「责任」。**

| 参与方 | 在项目中的角色 | 主要贡献 | 获得的收益 |
|-------|-------------|---------|---------|
| [团队A] | [角色] | [具体贡献] | [具体好处] |
| [团队B] | [角色] | [具体贡献] | [具体好处] |
| [团队C] | [角色] | [具体贡献] | [具体好处] |

**收益要具体**，不能写「提升协作效率」这类空话，要写「[团队B] 现在做X需要Y天，这件事做完后可以减少到Z天」。

---

### 三、项目范围与边界

**3.1 做什么（In scope）**
- [明确列出]

**3.2 不做什么（Out of scope）**
- [明确列出，防止范围蔓延]

**3.3 依赖和前提条件**
- [做这件事需要什么前提条件已满足]

---

### 四、执行计划

**4.1 里程碑**

| 里程碑 | 时间 | 交付件 | 负责方 |
|-------|------|-------|-------|
| [M1] | [日期] | [交付物] | [团队] |
| [M2] | [日期] | [交付物] | [团队] |
| [M3] | [日期] | [交付物] | [团队] |

**4.2 各方交付件清单**

**[团队A] 需要提供**：
- [交付件1]：[说明 + 时间]
- [交付件2]：[说明 + 时间]

**[团队B] 需要提供**：
- [交付件1]：[说明 + 时间]

---

### 五、协作机制

**5.1 决策方式**

| 决策类型 | 决策者 | 参与方 |
|---------|-------|-------|
| 项目总体方向 | [Owner] | 所有参与方 |
| [子领域]技术方案 | [Team] | 相关方 |
| 资源调配 | [Owner] | 各方负责人 |

**5.2 沟通机制**
- 例行同步：[频率 / 形式 / 参与方]
- 进展通报：[方式 / 频率]
- 文档沉淀：[在哪里]

**5.3 升级路径**
- 分歧解决：[先在哪个层级解决，解决不了升级到哪里]
- 风险上报：[什么情况需要上报，上报给谁]

---

### 六、风险与应对

| 风险 | 影响方 | 概率 | 应对策略 |
|------|-------|------|---------|
| [风险1] | [团队] | 高/中/低 | [具体应对] |
| [风险2] | [团队] | 高/中/低 | [具体应对] |

---

## 技法适配

KO场景对通用技法有特定的适配方式。当你在帮用户撰写某个章节并需要决定技法使用方式时，读取 [技法适配参考](../references/technique-adaptation.md) 中「横向协作KO」部分。不要在启动时加载。

如需了解某个具体技法的完整说明（含示例、适用受众、常见陷阱），读取 [技法详解](../report-planning/references/techniques.md) 中对应技法编号的内容。按需加载，不要一次性读完。

**常用技法参考编号**（KO场景）：
- 技法2（辩证表达）— 挑战+机遇双framing
- 技法3（闭环叙事弧）— 协作文档的结构骨架
- 技法5（论证深度）— 为什么大家都需要这件事
- 技法10（OKR/战略对齐）— 各方目标对齐

---

## 常见陷阱

- ❌ 只从主导方视角写，其他方感觉是在「被拉来配合」
- ❌ 各方收益不具体，只有「共同受益」这种空话
- ❌ 职责划分模糊，多方都写「参与」，没有明确 owner
- ❌ 没有决策机制，遇到分歧不知道谁说了算
- ❌ 范围不清晰，项目推进过程中不断扩大

## 参考文件

- [通用风格规范](../references/style-guide.md)
- [汇报对象适配](../references/audience-guide.md)
- [KO文档模板](assets/templates/kickoff-template.md)