Project Plan

---
name: project-plan
description: 把一个模糊的目标拆成有负责人有日期的排期表
---

# 项目排期技能

## 一份能用的排期表和一份好看的排期表

好看的排期表：阶段一、阶段二、阶段三，每个阶段列几个漂亮的名词。
**能用的排期表**：每一行都能回答「谁、做完什么算完、什么时候之前、卡在谁手上」。
只做第二种。

## 1. 先把目标问清楚

模糊的目标拆不出靠谱的排期。动手前至少要知道：

- **交付物是什么**，怎么算完成（「上线」不算，「用户能在生产环境下单付款成功」才算）
- **死线**是哪天，是硬的还是软的
- **有几个人**，分别能投入多少（全职还是兼顾别的）
- **有什么已知约束**：等第三方接口、等法务、等对方给素材

缺哪一项就用 `ask_user` 问哪一项。**别自己编一个团队规模出来排期**——排出来是废纸。
用户给了需求文档、会议纪要的，`read_document` 读进来当输入。

## 2. 拆解顺序

1. **先写倒数第二步**：交付前必须做完的那件事是什么？（验收？灰度？备案？）
2. **从后往前倒推**，每一步问「这一步开始之前，什么必须已经好了」，一直倒到今天。
3. 倒完再正着读一遍，补上正向才想得起来的事：环境准备、数据迁移、培训、文档。

倒推能自然逼出依赖关系，正序排容易漏掉「原来这个得先做」。

## 3. 输出结构

```markdown
# <项目名> 排期
目标：<一句话，含验收标准> ｜ 死线：2026-11-30（硬） ｜ 投入：3 人

## 里程碑
| # | 里程碑 | 完成标志 | 日期 | 负责人 |
|---|---|---|---|---|
| M1 | 需求定稿 | PRD 评审通过，无 P0 待议 | 09-20 | 张三 |
| M2 | 核心链路可用 | 测试环境能跑通下单全流程 | 10-25 | 李四 |

## 任务分解
| # | 任务 | 依赖 | 负责人 | 起 | 止 | 人天 |
|---|---|---|---|---|---|---|
| 1 | 接口联调 | — | 李四 | 09-22 | 09-30 | 6 |
| 2 | 支付回调 | #1 | 李四 | 10-08 | 10-15 | 5 |

## 关键路径
#1 → #2 → #7 → M2，共 21 人天。**这条链上任何一环延期，整体就延期**。

## 风险与缓冲
| 风险 | 影响 | 概率 | 怎么办 |
|---|---|---|---|
| 支付渠道审核要 2-4 周 | 直接压 M2 | 高 | 09-15 就提交申请，不等开发完 |

## 需要你拍板的
- 09-15 前要确认用哪家支付渠道，否则 #2 没法开工
```

## 4. 排期的几条常识

- **人天 ≠ 工作日**。一个人一周排 5 人天是排满了，真实产出通常 3.5-4。留出这个折扣，否则第一周就开始欠账。
- **依赖别人的事项要单独标出来**，并且把「什么时候发出请求」也排成一个任务。等法务、等对方给资料，这些是最常见的延期来源。
- **缓冲放在里程碑之间，不要放在每个任务里**。塞进每个任务的缓冲会被无声吃掉。
- **关键路径一定要算并写出来**。不在关键路径上的任务延期两天不用慌，在路径上的延一天就得开会。
- 日期换算用系统提示里的今天，不要用你记忆里的年份。

## 5. 交付与跟进

排期表写成 `.md` 或 `.xlsx` 文件。
接着问用户一句要不要设跟进：`schedule_task` 排一条「每周一早 9 点提醒对照排期表核对进度」，
到点它会自己跑起来，比一份躺在文件夹里的排期表有用得多。
排期表要发给团队就用 `send_email`。

## 红线

- **不许凭空指派负责人**。用户没说谁做的，写「待定」并单列进「需要你拍板的」。
- **不许为了凑死线把人天改小**。排出来超期就如实说超期，并给出三个选项：砍范围、加人、改死线。这是项目经理的核心价值，不是坏消息。
- **不许把「联调」「优化」「测试」这种词单独当一个任务**。写清楚联调哪个接口、优化哪个指标到多少。

## 质量标准

- 每个任务都有明确的完成标志，不是一个动词
- 关键路径被算出来并写在显眼位置
- 至少识别出 3 条真实风险，每条都有具体的应对动作和触发时间
- 如果排出来的总工期超过死线，这件事在文档第一屏就说了