Aily Doc Project Kickoff Report

---
name: aily-doc-project-kickoff-report
label: 项目启动报告
description: 项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。
---

# SKILL: aily-doc-project-kickoff-report

项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。

---

## 1) Overview

### ⚠️ 输出形式（强制）
- **本 skill 被触发即代表用户期望生成飞书云文档**，主 Agent 无需询问用户是否需要写成文档，也不得以对话文本替代文档作为最终交付物。
- 数据收集完成后，必须通过 `task`（subagent_type: writer）委托 Writer Agent 创建飞书云文档。

### 飞书工具优先（必须遵守）
- 所有飞书相关信息获取与写作，先参考 `feishu-use-skills-map` 并按其指引调用对应技能
- 需要访问飞书文档/群消息/会议/任务时，必须先 `get_skills` 获取对应飞书技能说明

### 工具/Skill 明确清单（执行前先 get_skills）
- 必须先参考 `feishu-use-skills-map` 并调用对应技能
- 主要技能：

| 工具 | 用途 | 适用场景 |
|------|------|---------|
| `aily-doc` | 搜索/读取飞书云文档 | 需求文档、立项文档、历史启动报告 |
| `aily-calendar` | 查询日历/会议 | 项目相关会议、排期信息 |
| `aily-im` | 获取群消息/群成员 | 项目群成员列表、历史讨论 |
| `knowledge_answer` | 查询内部知识库 | 项目背景、技术栈、组织信息 |
| `file` | 将素材写入 draft.md（append 模式） | 每个数据步骤完成后 |

### 证据与时间约束（与主/写作agent一致）
- 任何数据/结论必须来自可追溯来源；不确定则明确标注"需补充资料"。
- 若用户指定时间范围，必须严格筛选在时间窗内的资料，过期内容不得使用。
- 不可编造事实、链接或来源；引用必须有明确出处。

### 可读性规则（强制）
- 并列项>=3：优先使用无序/有序列表或表格
- 单段>150字必须拆分（列表/小节/Callout）
- 连续两段无列表且信息密度高：插入列表或 Callout

### 触发方式（Triggers）
- "项目启动"
- "kickoff"
- "启动会"
- "帮我写一份项目启动报告"
- "准备 kickoff 材料"
- "启动XX项目"

### 输入（Inputs）
- **必选**：项目名称、项目目标、项目范围
- **可选**：
  - 干系人列表（项目负责人、核心成员、利益相关方）
  - 资源需求（人力、预算、设备）
  - 初步计划/排期
  - 技术约束/系统依赖
  - 风险预判

### 核心输出（Deliverables）
- **飞书云文档项目启动报告**：目标清晰、范围明确、分工到人、里程碑可追踪、风险有预案

### 质量标准
- **共识明确**：项目目标、范围、成功标准在报告中统一表述，无歧义
- **执行可落地**：每个里程碑有明确的时间节点、交付物和责任人；RACI矩阵完整
- **风险可控**：识别主要风险并附带应对措施和Owner
- **沟通有机制**：例会、信息同步、升级机制三者齐全

---

## 2) 任务分解示例（todo_write）

主 Agent 收到项目启动报告请求后，使用 `todo_write` 分解任务：

```json
{
  "todos": [
    {"content": "A1. 获取项目背景资料（需求文档/立项文档/项目背景）", "status": "in_progress"},
    {"content": "A2. 获取干系人信息（项目群成员/相关会议参与人）", "status": "pending"},
    {"content": "A3. 搜索历史参考（类似项目启动报告）", "status": "pending"},
    {"content": "A4. 查询技术约束与系统依赖", "status": "pending"},
    {"content": "B. 结构化整理：目标/范围/里程碑/分工/风险/沟通", "status": "pending"},
    {"content": "C. 调用 writer agent 生成项目启动报告飞书云文档", "status": "pending"}
  ]
}
```

---

## 3) Module A — 资料获取（主 Agent 执行）

> **核心原则**：优先使用飞书工具获取内部资料，`knowledge_answer` 作为补充和兜底。每个步骤完成后，将结果结构化写入 `draft.md`。

### A1. 项目背景

**目标**：获取项目的来龙去脉、立项原因、业务目标。

**工具与策略**：

1. **`aily-doc` 搜索需求文档/立项文档**：
```
aily-doc(
  action: "search",
  query: "{项目名称} 需求文档 立项 PRD",
  filters: { doc_type: "docx" }
)
```

2. **`aily-doc` 读取关键文档**（搜索到后深度阅读）：
```
aily-doc(
  action: "read",
  doc_token: "{文档token}",
  prompt: "提取项目背景、业务目标、核心需求、发起原因"
)
```

3. **`knowledge_answer` 查询项目背景**：
```
knowledge_answer(
  query_list: [
    "{项目名称} 项目背景 立项原因",
    "{项目名称} 业务目标 核心需求"
  ],
  explanation: "获取项目背景信息和立项依据"
)
```

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## A1. 项目背景

### 立项背景
- 业务驱动因素：...
- 市场/客户需求：...
- 战略对齐：...

### 核心需求
| 需求编号 | 需求描述 | 优先级 | 来源 |
|---------|---------|--------|------|
| R001 | ... | P0 | PRD文档 |
| R002 | ... | P1 | 客户反馈 |

### 相关文档
- [需求文档](飞书链接)：核心要点...
- [立项文档](飞书链接)：核心要点...

### 数据来源
- 来源1：{文档名称}（飞书文档）
- 来源2：knowledge_answer 查询结果
```

---

### A2. 干系人信息

**目标**：明确项目组织结构、核心成员、利益相关方。

**工具与策略**：

1. **`aily-im` 获取项目群成员**：
```
aily-im(
  action: "get_group_members",
  query: "{项目名称}",
  prompt: "获取项目相关群组的成员列表及其角色"
)
```

2. **`aily-calendar` 查询相关会议**：
```
aily-calendar(
  action: "search",
  query: "{项目名称} 启动 评审 规划",
  time_range: "近30天"
)
```
- 从会议参与人中补充干系人信息
- 识别高频参与者，推断核心成员

3. **`knowledge_answer` 补充组织信息**：
```
knowledge_answer(
  query_list: [
    "{项目名称} 项目负责人 团队成员",
    "{项目名称} 相关团队 组织架构"
  ],
  explanation: "获取项目组织与人员信息"
)
```

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## A2. 干系人信息

### 项目群成员
| 姓名 | 群角色 | 推断项目角色 |
|------|--------|-------------|
| @XX | 群主 | 项目负责人（推测） |
| @XX | 成员 | 核心开发（推测） |

### 相关会议参与人
| 会议名称 | 日期 | 关键参与人 |
|---------|------|-----------|
| XX项目规划会 | YYYY-MM-DD | @XX, @XX, @XX |
| XX需求评审会 | YYYY-MM-DD | @XX, @XX |

### 高频协作对象
- @XX（出现 N 次）—— 可能角色：...
- @XX（出现 N 次）—— 可能角色：...

### 待确认
- [ ] 项目负责人需用户确认
- [ ] RACI矩阵中的具体分工需用户补充
```

---

### A3. 历史参考

**目标**：找到公司内部类似项目的启动报告，作为结构和内容参考。

**工具与策略**：

1. **`aily-doc` 搜索类似项目启动报告**：
```
aily-doc(
  action: "search",
  query: "项目启动报告 kickoff",
  filters: { doc_type: "docx" }
)
```

2. **`aily-doc` 搜索同类型项目文档**：
```
aily-doc(
  action: "search",
  query: "{项目类型关键词} 启动 立项 规划",
  filters: { doc_type: "docx" }
)
```

3. **读取参考报告**（如搜索到）：
```
aily-doc(
  action: "read",
  doc_token: "{参考文档token}",
  prompt: "提取该启动报告的结构、里程碑设置方式、分工方式、风险识别方法"
)
```

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## A3. 历史参考

### 参考项目启动报告
| 项目名称 | 文档链接 | 参考价值 |
|---------|---------|---------|
| XX项目启动报告 | [链接](url) | 里程碑设置方式可参考 |
| YY项目Kickoff | [链接](url) | RACI矩阵结构可参考 |

### 可复用经验
- 里程碑粒度：按双周/月划分阶段
- 分工模式：使用RACI矩阵
- 风险管理：概率-影响矩阵 + Owner

### 应避免的问题
- XX项目启动报告中未明确沟通机制，后续沟通混乱
- YY项目里程碑过于粗放，无法追踪进度
```

---

### A4. 技术约束

**目标**：了解项目涉及的技术栈、系统依赖、架构约束。

**工具与策略**：

1. **`knowledge_answer` 查询技术栈/系统约束**：
```
knowledge_answer(
  query_list: [
    "{项目名称} 技术栈 技术架构",
    "{项目名称} 系统依赖 接口依赖",
    "{项目名称} 技术约束 非功能性需求"
  ],
  explanation: "获取项目的技术约束和系统依赖信息"
)
```

2. **`aily-doc` 搜索技术方案文档**：
```
aily-doc(
  action: "search",
  query: "{项目名称} 技术方案 架构设计 系统设计",
  filters: { doc_type: "docx" }
)
```

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## A4. 技术约束

### 技术栈
- 前端：...
- 后端：...
- 基础设施：...

### 系统依赖
| 依赖系统 | 依赖类型 | 负责团队 | 当前状态 |
|---------|---------|---------|---------|
| XX系统 | 接口调用 | XX团队 | 已就绪 |
| YY平台 | 数据依赖 | YY团队 | 需对齐 |

### 技术约束
- 性能要求：...
- 兼容性要求：...
- 安全合规：...

### 关键假设
- 假设1：XX系统接口在M月前可用
- 假设2：XX团队能提供N人支持
```

---

## 4) Module B — 结构化整理（主 Agent 执行）

> **核心原则**：将 Module A 收集的原始资料，按照启动报告的框架进行结构化分析和整理，形成"目标-范围-计划-分工-风险-沟通"完整链条。

### B1. 项目目标与成功标准

**分析要点**：
- 从 A1 中提取并提炼项目目标，区分业务目标和技术目标
- 将模糊目标转化为可量化的成功标准
- 每个目标配备验收维度和目标值

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B1. 项目目标与成功标准

### 项目目标
- **业务目标**：...（从需求文档/立项文档中提取）
- **技术目标**：...（从技术方案中提取）
- **用户目标**：...（从用户反馈/PRD中提取）

### 成功标准
| 维度 | 指标 | 目标值 | 衡量方式 |
|------|------|--------|---------|
| 业务 | XX转化率 | 提升X% | 数据看板 |
| 技术 | 系统响应时间 | <Xms | 监控系统 |
| 用户 | 用户满意度 | >X分 | 用户调研 |
| 进度 | 按时交付率 | 100% | 里程碑检查 |

### 非目标（明确排除）
- 本项目不追求...
- 本阶段不涉及...
```

---

### B2. 范围界定（做什么/不做什么）

**分析要点**：
- 从 A1 的需求文档中提取范围边界
- 明确 In Scope 和 Out of Scope，避免范围蔓延
- 列出关键假设与约束条件

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B2. 范围界定

### 项目范围（In Scope）
1. **功能范围**：
   - 功能模块1：...
   - 功能模块2：...
   - 功能模块3：...
2. **用户范围**：目标用户群体...
3. **平台范围**：Web/App/API...

### 不在范围内（Out of Scope）
1. XX功能（计划在二期实现）
2. XX平台适配（当前仅支持XX）
3. XX场景（不在本次需求内）

### 关键假设
| 编号 | 假设内容 | 影响 | 验证方式 |
|------|---------|------|---------|
| H001 | XX团队能按时交付接口 | 影响集成阶段排期 | 周会同步 |
| H002 | XX方案技术可行 | 影响架构设计 | 技术验证 |

### 约束条件
- 时间约束：必须在YYYY-MM-DD前上线
- 资源约束：团队N人，无额外HC
- 技术约束：必须基于现有XX架构
```

---

### B3. 里程碑与排期

**分析要点**：
- 结合 A1 的需求和 A4 的技术约束，规划合理排期
- 参考 A3 的历史项目排期经验
- 每个阶段有明确的交付物和负责人

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B3. 里程碑与排期

### 整体排期
| 阶段 | 时间 | 交付物 | 负责人 |
|------|------|--------|--------|
| 需求确认 | MM.DD - MM.DD | 需求文档终稿 | @产品经理 |
| 技术设计 | MM.DD - MM.DD | 技术方案文档 | @技术负责人 |
| 开发实现 | MM.DD - MM.DD | 功能代码 | @开发团队 |
| 测试验收 | MM.DD - MM.DD | 测试报告 | @测试负责人 |
| 上线发布 | MM.DD | 线上版本 | @项目负责人 |

### 关键里程碑
| 里程碑 | 日期 | 标志事件 | 检查方式 |
|--------|------|---------|---------|
| M1：需求冻结 | MM-DD | 需求文档签字确认 | 评审会议 |
| M2：技术方案评审通过 | MM-DD | 方案评审通过 | 评审会议 |
| M3：开发完成/提测 | MM-DD | 代码合入主分支 | CI/CD |
| M4：测试通过 | MM-DD | 全量用例通过 | 测试报告 |
| M5：正式上线 | MM-DD | 线上发布成功 | 监控确认 |

### 关键路径
- 需求确认 → 技术设计 → 核心模块开发 → 集成测试 → 上线
- 关键路径预估工期：XX 工作日
```

---

### B4. 组织与分工（RACI矩阵）

**分析要点**：
- 结合 A2 的干系人信息，明确角色分工
- 使用 RACI 矩阵（Responsible/Accountable/Consulted/Informed）
- 确保每项关键活动有且仅有一个 A（Accountable）

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B4. 组织与分工

### 项目组织架构
- **项目发起人（Sponsor）**：@XX —— 资源协调、重大决策
- **项目负责人（PM）**：@XX —— 整体推进、风险管理
- **技术负责人（TL）**：@XX —— 技术方案、代码质量
- **产品负责人（PD）**：@XX —— 需求管理、验收标准
- **测试负责人（QA）**：@XX —— 测试策略、质量保障

### 角色与职责
| 角色 | 人员 | 核心职责 |
|------|------|---------|
| 项目负责人 | @XX | 项目计划制定与跟踪、风险管理、干系人沟通 |
| 技术负责人 | @XX | 技术方案设计、Code Review、技术难题攻关 |
| 产品负责人 | @XX | 需求管理、优先级排序、验收确认 |
| 前端开发 | @XX, @XX | 前端功能开发、联调 |
| 后端开发 | @XX, @XX | 后端功能开发、接口设计 |
| 测试 | @XX | 测试用例设计、执行、缺陷跟踪 |
| 设计 | @XX | UI/UX设计、设计稿交付 |

### RACI矩阵
| 活动 / 角色 | PM | TL | PD | 开发 | QA | 设计 |
|-------------|----|----|----|----|----|----|
| 需求评审 | A | C | R | C | I | C |
| 技术方案设计 | I | A | C | R | I | - |
| UI/UX设计 | I | C | A | I | - | R |
| 功能开发 | I | A | - | R | I | - |
| 代码Review | I | A | - | R | - | - |
| 测试执行 | I | C | C | C | R/A | - |
| 上线发布 | A | R | I | R | C | - |
| 项目进度汇报 | R/A | C | C | I | I | I |

> R=Responsible（执行）, A=Accountable（负责）, C=Consulted（咨询）, I=Informed（知会）
```

---

### B5. 风险与依赖识别

**分析要点**：
- 从 A4 的技术约束中提取技术风险
- 从 A2 的干系人信息中识别资源风险
- 从 A3 的历史经验中借鉴风险管理方法
- 每个风险有概率、影响、应对措施、Owner

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B5. 风险与依赖

### 风险清单
| 编号 | 风险描述 | 概率 | 影响 | 风险等级 | 应对措施 | Owner |
|------|---------|------|------|---------|---------|-------|
| R001 | XX接口交付延期 | 高 | 高 | 严重 | 提前对齐排期，准备降级方案 | @XX |
| R002 | 核心开发人员请假 | 中 | 高 | 高 | 关键模块安排backup | @XX |
| R003 | 需求变更频繁 | 中 | 中 | 中 | 需求冻结后变更需评审 | @XX |
| R004 | 性能不达标 | 低 | 高 | 中 | 提前做性能测试 | @XX |

### 外部依赖
| 依赖项 | 依赖团队 | 预计就绪时间 | 当前状态 | 对接人 |
|--------|---------|-------------|---------|--------|
| XX系统接口 | XX团队 | MM-DD | 开发中 | @XX |
| YY平台权限 | YY团队 | MM-DD | 待申请 | @XX |
| 设计稿交付 | 设计团队 | MM-DD | 设计中 | @XX |

### 风险应对策略
- **规避**：提前识别并消除风险源
- **缓解**：降低发生概率或减轻影响
- **转移**：将风险转移给更合适的责任方
- **接受**：低概率低影响的风险可接受并监控
```

---

### B6. 沟通机制设计

**分析要点**：
- 基于项目规模和团队分布设计沟通机制
- 参考 A3 历史项目的沟通方式
- 覆盖例会、信息同步、升级三个层面

**写入 draft.md**（使用 `file(path: "/home/workspace/draft.md", mode: "append")`）：
```markdown
## B6. 沟通机制

### 例会安排
| 会议类型 | 频率 | 参与人 | 目的 | 时间 |
|---------|------|--------|------|------|
| 项目站会 | 每日 | 全体项目成员 | 同步进展、暴露阻塞 | 每天 10:00（15分钟） |
| 项目周会 | 每周 | 全体 + 干系人 | 里程碑检查、风险评审 | 每周X 14:00（1小时） |
| 技术评审会 | 按需 | TL + 开发 | 方案评审、技术决策 | 按需安排 |
| 项目汇报会 | 双周/月 | PM + Sponsor | 项目状态汇报 | 按需安排 |

### 信息同步方式
| 渠道 | 用途 | 频率 |
|------|------|------|
| 项目飞书群 | 日常沟通、快速响应 | 实时 |
| 飞书文档（项目看板） | 进度追踪、里程碑状态 | 实时更新 |
| 邮件/飞书通知 | 重要决策、变更通知 | 按需 |
| 周报 | 项目进展总结 | 每周 |

### 升级机制
| 升级条件 | 升级层级 | 响应时限 |
|---------|---------|---------|
| 阻塞超过1个工作日 | TL / PM | 4小时内响应 |
| 影响里程碑的风险 | PM → Sponsor | 1个工作日内决策 |
| 需求变更（P0） | PD → PM → Sponsor | 2个工作日内评审 |
| 跨团队协作问题 | PM → 对方PM/TL | 1个工作日内对齐 |
```

---

## 5) Module C — 写作生成（Writer Agent）

### 任务分发

主 Agent 完成 Module A（资料获取）和 Module B（结构化整理）后，将所有内容写入 `draft.md`，然后调用 `task` 工具分发给 Writer Agent：

```json
{
  "description": "生成项目启动报告飞书云文档",
  "prompt": "基于 /home/workspace/draft.md 中的项目启动报告素材，生成一份结构完整的飞书云文档项目启动报告。\n\n要求：\n1. 严格按照项目启动报告模板结构\n2. 项目摘要放在最前面，3-5条核心要点\n3. 所有数据来源于 draft.md，不要编造\n4. RACI矩阵必须完整\n5. 风险清单必须有应对措施和Owner\n6. 沟通机制必须包含例会、信息同步、升级机制\n7. 表格优先，确保可读性\n\n报告模板见下方。",
  "subagent_type": "writer"
}
```

### Writer Agent 执行流程

```
Writer Agent 收到任务
      ↓
1. file_read: 读取 /home/workspace/draft.md
      ↓
2. outline_generator: 基于模板生成结构化大纲
      ↓
3. document_write: 生成 项目启动报告.feishu.md
      ↓
4. feishu_doc_create: 转换为飞书云文档
      ↓
5. end: 返回飞书文档链接
```

### Writer Agent 写作规则
- 严格遵循下方文档模板结构
- 所有内容来源于 `draft.md`，不得编造
- 表格内容不可省略，宁可标注"待补充"
- 并列项>=3 使用列表或表格
- 每个章节有导言说明该章节目的

---

## 6) 详细文档模板（Writer Agent 遵循）

Writer Agent 使用 `document_write` 生成飞书云文档时，**必须遵循以下模板结构**：

```markdown
# {项目名称} 启动报告

> 启动日期：YYYY-MM-DD | 项目负责人：@XX
> 文档状态：草稿/评审中/已确认
> 生成时间：YYYY-MM-DD HH:MM

---

## 项目摘要

<!-- 3-5条核心要点，高度概括整个项目 -->

1. **项目目标**：一句话概括项目要达成什么
2. **项目周期**：YYYY-MM-DD ~ YYYY-MM-DD，共N个工作日
3. **核心团队**：N人，涉及XX、XX、XX团队
4. **关键里程碑**：M1需求冻结(MM-DD)、M2提测(MM-DD)、M3上线(MM-DD)
5. **主要风险**：XX风险需重点关注

---

## 一、项目背景与目标

### 1.1 项目背景

<!-- 说明项目的来龙去脉、发起原因、业务背景 -->

- **业务背景**：...
- **发起原因**：...
- **战略对齐**：...

### 1.2 项目目标

- **业务目标**：...
- **技术目标**：...
- **用户目标**：...

### 1.3 成功标准

| 维度 | 指标 | 目标值 | 衡量方式 |
|------|------|--------|---------|
| 业务 | XX指标 | 提升X% | 数据看板 |
| 技术 | 响应时间 | <Xms | 监控系统 |
| 用户 | 满意度 | >X分 | 调研问卷 |
| 进度 | 按时交付 | 100% | 里程碑检查 |

---

## 二、范围与边界

### 2.1 项目范围（In Scope）

1. **功能范围**：
   - 功能模块A：...
   - 功能模块B：...
   - 功能模块C：...
2. **用户范围**：...
3. **平台范围**：...

### 2.2 不在范围内（Out of Scope）

| 排除项 | 原因 | 后续计划 |
|--------|------|---------|
| XX功能 | 非本期需求 | 计划二期实现 |
| XX平台 | 资源限制 | 视情况扩展 |

### 2.3 关键假设与约束

**关键假设**：
| 编号 | 假设内容 | 影响范围 | 验证方式 |
|------|---------|---------|---------|
| H001 | ... | ... | ... |
| H002 | ... | ... | ... |

**约束条件**：
- 时间约束：...
- 资源约束：...
- 技术约束：...

---

## 三、里程碑与计划

### 3.1 整体排期

| 阶段 | 时间 | 交付物 | 负责人 | 验收标准 |
|------|------|--------|--------|---------|
| 需求确认 | MM.DD - MM.DD | 需求文档终稿 | @XX | 需求评审通过 |
| 技术设计 | MM.DD - MM.DD | 技术方案文档 | @XX | 方案评审通过 |
| UI/UX设计 | MM.DD - MM.DD | 设计稿 | @XX | 设计评审通过 |
| 开发实现 | MM.DD - MM.DD | 功能代码 | @XX | 提测标准达成 |
| 测试验收 | MM.DD - MM.DD | 测试报告 | @XX | 用例通过率100% |
| 上线发布 | MM.DD | 线上版本 | @XX | 线上验证通过 |

### 3.2 关键里程碑

| 里程碑 | 日期 | 标志事件 | 检查方式 | 负责人 |
|--------|------|---------|---------|--------|
| M1 需求冻结 | MM-DD | 需求文档签字确认 | 评审会议 | @XX |
| M2 设计完成 | MM-DD | 设计稿交付 | 设计评审 | @XX |
| M3 开发完成 | MM-DD | 代码合入/提测 | CI/CD | @XX |
| M4 测试通过 | MM-DD | 全量用例通过 | 测试报告 | @XX |
| M5 正式上线 | MM-DD | 发布上线 | 线上监控 | @XX |

---

## 四、组织与分工

### 4.1 项目组织架构

```
项目发起人（Sponsor）: @XX
        |
项目负责人（PM）: @XX
        |
  ┌─────┼─────┬──────┐
  |     |     |      |
产品    技术   测试   设计
@XX    @XX   @XX    @XX
       |
   ┌───┼───┐
   |       |
 前端    后端
 @XX    @XX
```

### 4.2 角色与职责

| 角色 | 人员 | 核心职责 | 投入度 |
|------|------|---------|--------|
| 项目发起人 | @XX | 资源协调、重大决策 | 10% |
| 项目负责人 | @XX | 计划制定、进度跟踪、风险管理 | 50% |
| 产品负责人 | @XX | 需求管理、验收确认 | 40% |
| 技术负责人 | @XX | 方案设计、技术决策 | 60% |
| 前端开发 | @XX, @XX | 前端功能开发 | 100% |
| 后端开发 | @XX, @XX | 后端功能开发 | 100% |
| 测试 | @XX | 测试设计与执行 | 80% |
| 设计 | @XX | UI/UX设计 | 30% |

### 4.3 RACI矩阵

| 活动 | Sponsor | PM | PD | TL | 开发 | QA | 设计 |
|------|---------|----|----|----|----|----|----|
| 项目立项 | A | R | C | C | I | I | I |
| 需求评审 | I | A | R | C | C | I | C |
| 技术方案设计 | I | I | C | A | R | I | - |
| UI/UX设计 | I | I | A | C | I | - | R |
| 功能开发 | - | I | - | A | R | I | - |
| 代码Review | - | I | - | A | R | - | - |
| 测试执行 | - | I | C | C | C | R/A | - |
| 上线发布 | I | A | I | R | R | C | - |
| 进度汇报 | I | R/A | C | C | I | I | I |

> **R**=Responsible（执行），**A**=Accountable（负责），**C**=Consulted（咨询），**I**=Informed（知会）

---

## 五、沟通机制

### 5.1 例会安排

| 会议类型 | 频率 | 时间 | 时长 | 参与人 | 目的 |
|---------|------|------|------|--------|------|
| 每日站会 | 每日 | 10:00 | 15分钟 | 全体项目成员 | 同步进展、暴露阻塞 |
| 项目周会 | 每周 | 周X 14:00 | 1小时 | 全体 + 干系人 | 里程碑检查、风险评审 |
| 技术评审 | 按需 | 待定 | 1-2小时 | TL + 开发 + QA | 方案评审、技术决策 |
| Sponsor汇报 | 双周 | 待定 | 30分钟 | PM + Sponsor | 项目状态汇报 |

### 5.2 信息同步方式

| 渠道 | 用途 | 更新频率 | 负责人 |
|------|------|---------|--------|
| 项目飞书群 | 日常沟通、即时响应 | 实时 | 全体 |
| 项目看板/文档 | 进度追踪、任务状态 | 实时更新 | PM |
| 项目周报 | 进展总结、风险通报 | 每周 | PM |
| 邮件/通知 | 重要决策、正式变更 | 按需 | PM |

### 5.3 升级机制

| 级别 | 触发条件 | 升级对象 | 响应时限 | 处理方式 |
|------|---------|---------|---------|---------|
| L1 | 阻塞超过4小时 | TL / PM | 4小时内响应 | 协调资源、调整优先级 |
| L2 | 影响里程碑节点 | PM → Sponsor | 1工作日内决策 | 评估影响、制定补救方案 |
| L3 | 需求P0变更 | PD → PM → Sponsor | 2工作日内评审 | 变更评审会议 |
| L4 | 跨团队协作阻塞 | PM → 对方PM | 1工作日内对齐 | 联合会议、资源协调 |

---

## 六、风险与依赖

### 6.1 风险清单

| 编号 | 风险描述 | 概率 | 影响 | 风险等级 | 应对措施 | Owner |
|------|---------|------|------|---------|---------|-------|
| R001 | XX接口交付延期 | 高 | 高 | 严重 | 提前对齐排期；准备降级方案 | @XX |
| R002 | 核心人员变动/请假 | 中 | 高 | 高 | 关键模块安排backup人员 | @XX |
| R003 | 需求变更频繁 | 中 | 中 | 中 | 需求冻结后变更需评审流程 | @XX |
| R004 | 性能不达标 | 低 | 高 | 中 | 提前做性能基准测试 | @XX |
| R005 | 第三方服务不稳定 | 低 | 中 | 低 | 设计降级和熔断机制 | @XX |

> 风险等级 = 概率 x 影响：严重(高x高)、高(高x中/中x高)、中(中x中/低x高/高x低)、低(低x中/低x低)

### 6.2 外部依赖

| 依赖项 | 依赖团队 | 对接人 | 预计就绪 | 当前状态 | 备选方案 |
|--------|---------|--------|---------|---------|---------|
| XX系统接口 | XX团队 | @XX | MM-DD | 开发中 | Mock接口先行 |
| YY平台权限 | YY团队 | @XX | MM-DD | 待申请 | 提前走审批流程 |
| 设计稿交付 | 设计团队 | @XX | MM-DD | 设计中 | 先用线框图开发 |

---

## 七、资源需求

### 人力资源

| 角色 | 人数 | 投入周期 | 来源 |
|------|------|---------|------|
| 前端开发 | N人 | MM.DD - MM.DD | 现有团队 |
| 后端开发 | N人 | MM.DD - MM.DD | 现有团队 |
| 测试 | N人 | MM.DD - MM.DD | 现有团队 |
| 设计 | N人 | MM.DD - MM.DD | 需协调 |

### 其他资源

| 资源类型 | 需求描述 | 预算/成本 | 审批状态 |
|---------|---------|----------|---------|
| 服务器/云资源 | XX环境部署 | 待评估 | 待申请 |
| 第三方服务 | XX API调用 | XX元/月 | 待审批 |
| 测试设备 | XX机型覆盖 | 待评估 | 待确认 |

---

## 附录

### A. 相关文档索引
| 文档名称 | 链接 | 说明 |
|---------|------|------|
| 需求文档/PRD | [链接](url) | 详细需求说明 |
| 技术方案 | [链接](url) | 架构与设计 |
| 设计稿 | [链接](url) | UI/UX设计 |
| 项目看板 | [链接](url) | 任务与进度 |

### B. 术语表
| 术语 | 说明 |
|------|------|
| RACI | Responsible/Accountable/Consulted/Informed |
| MVP | Minimum Viable Product，最小可行产品 |
| CR | Concentration Ratio，集中度 |

### C. 变更记录
| 版本 | 日期 | 修改人 | 修改内容 |
|------|------|--------|---------|
| v1.0 | YYYY-MM-DD | @XX | 初始版本 |
```

---

## 7) 执行流程图

```
用户: "帮我准备XX项目的启动报告" / "项目启动" / "kickoff"
          ↓
┌─────────────────────────────────────────────────────────────┐
│                    主 Agent 执行                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 1. todo_write: 分解任务（6个子任务）                          │
│                                                             │
│ 【Module A — 资料获取】                                      │
│ 2. A1 项目背景                                               │
│    ├─ aily-doc: 搜索需求文档/立项文档                         │
│    ├─ aily-doc: 读取关键文档                                 │
│    ├─ knowledge_answer: 查项目背景                           │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 3. A2 干系人信息                                             │
│    ├─ aily-im: 获取项目群成员                                │
│    ├─ aily-calendar: 查相关会议及参与人                       │
│    ├─ knowledge_answer: 补充组织信息                         │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 4. A3 历史参考                                               │
│    ├─ aily-doc: 搜索类似项目启动报告                          │
│    ├─ aily-doc: 读取参考报告                                 │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 5. A4 技术约束                                               │
│    ├─ knowledge_answer: 查技术栈/系统约束                     │
│    ├─ aily-doc: 搜索技术方案文档                              │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 【Module B — 结构化整理】                                    │
│ 6. B1 项目目标与成功标准 → 写入 draft.md                      │
│ 7. B2 范围界定(In/Out Scope) → 写入 draft.md                │
│ 8. B3 里程碑与排期 → 写入 draft.md                           │
│ 9. B4 组织与分工(RACI) → 写入 draft.md                       │
│ 10. B5 风险与依赖识别 → 写入 draft.md                        │
│ 11. B6 沟通机制设计 → 写入 draft.md                          │
│                                                             │
│ 【Module C — 分发写作】                                      │
│ 12. task(writer): 分发给 Writer Agent                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘
          ↓
┌─────────────────────────────────────────────────────────────┐
│                    Writer Agent 执行                         │
├─────────────────────────────────────────────────────────────┤
│ 1. file_read: 读取 /home/workspace/draft.md                  │
│ 2. outline_generator: 基于模板生成结构化大纲                  │
│ 3. document_write: 生成 项目启动报告.feishu.md               │
│ 4. feishu_doc_create: 转换为飞书云文档                        │
│ 5. end: 返回飞书文档链接                                      │
└─────────────────────────────────────────────────────────────┘
          ↓
      飞书云文档项目启动报告
```

---

## 8) Checklist

### 主 Agent — 资料获取检查项（Module A）
- [ ] A1：需求文档/立项文档已搜索并读取
- [ ] A1：项目背景信息已通过 knowledge_answer 补充
- [ ] A2：项目群成员已通过 aily-im 获取
- [ ] A2：相关会议已通过 aily-calendar 查询
- [ ] A3：类似项目启动报告已搜索
- [ ] A4：技术约束/系统依赖已查询
- [ ] 所有获取的资料已写入 draft.md

### 主 Agent — 结构化整理检查项（Module B）
- [ ] B1：项目目标已明确，成功标准可量化
- [ ] B2：In Scope / Out of Scope 已清晰界定
- [ ] B2：关键假设与约束已列出
- [ ] B3：整体排期表已完成，每阶段有交付物和负责人
- [ ] B3：关键里程碑已标注日期和检查方式
- [ ] B4：组织架构和角色职责已明确
- [ ] B4：RACI矩阵已完成，每活动有且仅有一个A
- [ ] B5：风险清单已完成，每项有概率/影响/应对/Owner
- [ ] B5：外部依赖已列出，有对接人和预计就绪时间
- [ ] B6：例会安排已设计
- [ ] B6：信息同步方式已明确
- [ ] B6：升级机制已设计

### 主 Agent — 分发检查项（Module C）
- [ ] draft.md 内容完整，涵盖 A1-A4 和 B1-B6
- [ ] 已调用 task(writer) 分发写作任务
- [ ] prompt 中明确要求遵循模板结构

### Writer Agent 检查项
- [ ] 已读取 draft.md 完整内容
- [ ] 项目摘要完整（3-5条核心要点）
- [ ] 报告结构严格符合模板（七大章节 + 附录）
- [ ] 成功标准表格完整
- [ ] RACI矩阵完整且正确
- [ ] 风险清单有应对措施和Owner
- [ ] 沟通机制三要素齐全（例会/信息同步/升级）
- [ ] 所有内容来源于 draft.md，无编造
- [ ] 表格格式正确，无空缺（宁可写"待补充"）
- [ ] 已转换为飞书云文档

---

## 9) 常见失败模式与修复

| 失败模式 | 原因 | 修复方法 |
|---------|------|---------|
| 目标模糊 | 直接照搬用户原话，未提炼 | A1 阶段需从需求文档中提炼量化目标，B1 必须有成功标准表格 |
| 范围蔓延 | 未明确 Out of Scope | B2 必须列出"不在范围内"清单，附原因和后续计划 |
| 分工不清 | 只列了团队成员，没有明确职责 | B4 必须完成 RACI 矩阵，每活动有且仅有一个 Accountable |
| 里程碑过粗 | 只写"开发阶段"没有细分 | B3 里程碑需精确到周，每个节点有检查方式 |
| 风险走过场 | 只列风险不列应对措施 | B5 每个风险必须有应对措施和 Owner |
| 沟通机制缺失 | 启动报告中未设计沟通方式 | B6 必须包含例会/信息同步/升级三层机制 |
| 资料获取不全 | 只用了一个工具 | A1-A4 四步均需执行，aily-doc + aily-im + aily-calendar + knowledge_answer 组合使用 |
| 历史经验未参考 | 跳过了 A3 历史参考步骤 | A3 必须搜索公司内已有的启动报告，提取可复用经验 |
| draft.md 内容杂乱 | 原始资料未结构化直接交给 Writer | Module B 必须将原始资料整理为结构化要点后再分发 |
| Writer 输出不符模板 | prompt 中未明确模板要求 | Module C 的 prompt 必须附上完整模板结构 |