# 2 Todo Planner

> 近期任务规划 — 基于Eisenhower矩阵、MoSCoW法则和时间盒方法制定近期任务计划，生成结构化的TODO.md文档，支持优先级排序、工作量估算、依赖关系管理和进度跟踪

- Skill: `morning-start/2-todo-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add morning-start/2-todo-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/morning-start/2-todo-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: morning-start (https://skillmd.com/u/morning-start)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/morning-start/2-todo-planner

---


# ② 近期任务规划 (TODO Planner)

## 任务目标

帮助用户制定项目的**近期任务计划**（通常为周或双周/Sprint），产出标准化的 `TODO.md` 文件。该文件应清晰呈现：
- **当前周期重点**: 本 Sprint/周的核心目标
- **任务列表**: 按优先级排序的具体待办事项
- **责任与时间**: 负责人、截止日期、预估工时
- **依赖与阻塞**: 任务间的关系和风险点

## 触发条件

当用户说以下任一话术时激活：
- "帮我写 todo" / "制定待办清单"
- "规划本周/本月任务"
- "任务分解" / "拆解任务"
- "优先级排序" / "哪些先做"
- "Sprint 规划" / "迭代计划"

## 前置条件

⚠️ **推荐**（非强制）: 先完成 [① 远期规划](../skills/1-roadmap-planner/SKILL.md)，确保近期任务对齐远期目标。

如果已有 `ROADMAP.md`，TODO 应该是其**近期的具体化拆解**。

## 核心方法论选择

### 方法论对比表

| 方法 | 适用场景 | 核心逻辑 | 输出格式 | 复杂度 |
|------|---------|---------|---------|--------|
| **P0-P3 分级** | 通用任务管理 | 影响力×紧急度 | 4级标签 | ⭐ 简单 |
| **MoSCoW** | 需求/功能排序 | Must/Should/Could/Won't | 4类标签 | ⭐⭐ 中等 |
| **Eisenhower 矩阵** | 个人效率 | 重要×紧急 | 4象限 | ⭐⭐ 中等 |
| **时间盒 (Time-boxing)** | 敏捷Sprint | 固定时间窗口 | 时间约束 | ⭐⭐ 中等 |
| **RICE 评分** | 产品功能优先级 | R×I×C/E | 数值分值 | ⭐⭐⭐ 复杂 |
| **WSJF** | 敏捷开发 | 加权最短作业优先 | 故事点权重 | ⭐⭐⭐ 复杂 |

### 推荐选择决策树

```
项目类型？
    │
    ├── 个人项目 → P0-P3 + Eisenhower ✅（简单高效）
    │
    ├── 小团队 (2-5人) → MoSCoW + 时间盒 ✅（平衡）
    │   └── 如是敏捷开发 → Scrum Sprint Planning 模板
    │
    └── 中大型团队 → MoSCoW + RICE + 看板跟踪 🔄（完整）

> 📖 详细指南: [todo-methods.md](../references/todo-methods.md)
```

## 操作步骤

### Step 1: 收集任务输入

#### 任务来源清单

```markdown
## 任务收集 Checklist

### 从上游文档导入
- [ ] ROADMAP.md 的本季度 KR 拆解
- [ ] 上个周期的遗留/未完成任务
- [ ] Issue Tracker (GitHub Issues/Jira) 的 Open Issues
- [ ] 用户反馈/Bug 报告
- [ ] 团队会议记录的 Action Items

### 新增需求识别
- [ ] 产品经理的新需求
- [ ] 技术债务偿还（代码重构/升级依赖）
- [ ] 学习和探索性任务（调研新技术等）
- [ ] 运营和支持类工作（文档/培训/客服）
```

**快速收集命令**:

```bash
# 从 GitHub Issues 收集
gh issue list --state open --limit 20 --json title,labels,assignee 2>/dev/null

# 从 Jira 收集（如有）
jira jql "project = XXX AND status in ('To Do', 'In Progress')" 2>/dev/null

# 统计现有 TODO
if [ -f TODO.md ]; then
  echo "现有未完成任务:"
  grep '^- \[ \]' TODO.md | wc -l
fi
```

---

### Step 2: 应用优先级方法论

#### 方法 A: P0-P3 分级法（推荐默认）

**定义**:

| 优先级 | 名称 | 含义 | 响应时间 | 占比建议 |
|--------|------|------|---------|---------|
| **P0** | 🔴 必须做 (Must) | 阻塞性问题或核心功能 | 立即 | 10-20% |
| **P1** | 🟡 应该做 (Should) | 重要但不紧急 | 本周期 | 30-40% |
| **P2** | 🟢 可以做 (Could) | 有价值但可推迟 | 有空再做 | 30-40% |
| **P3** ⚪ | ⚪ 未来考虑 (Won't) | 低优先级或暂不做 | 下个周期 | 0-10% |

**判定标准**:

```
任务是否满足以下任一条件？
    │
    ├── 阻塞其他任务？ → P0
    ├── 影响用户体验（线上Bug）？ → P0
    ├── 是本周期承诺的核心功能？ → P0/P1
    ├── 是 ROADMAP 的里程碑交付物？ → P1
    ├── 有明确的外部截止日期？ → P1
    ├── 提升效率/质量但非紧急？ → P2
    ├── 锦上添花的功能？ → P2/P3
    └── 不确定是否需要？ → P3 或删除
```

#### 方法 B: MoSCoW 法则（需求/功能排序）

**定义**:

| 类别 | 全称 | 含义 | 承诺度 |
|------|------|------|--------|
| **Must** |必须有 | 不做就无法发布 | **100% 承诺** |
| **Should** | 应该有 | 高价值但非关键 | 尽量做，允许延期 |
| **Could** | 可以有 | 有了更好，没有也行 | 有时间就做 |
| **Won't** | 不会有 | 明确不做（本轮） | **不承诺** |

**使用场景**: 
- 产品发布规划
- MVP 功能范围确定
- 客户需求谈判

**判定问题**:
1. 如果不包含这个功能，产品还能用吗？→ No → **Must**
2. 用户会因为这个功能不满吗？→ Yes → **Should**
3. 这个功能能让产品更出色吗？→ Yes → **Could**
4. 这个功能现在完全不需要？→ Yes → **Won't**

#### 方法 C: Eisenhower 矩阵（个人效率）

```
                    │
        紧急       │     不紧急
        ────────   │   ──────────
                    │
重要 ↑   │  🔴 第I象限   │  🟢 第II象限
        │  (立即做)      │  (计划做)
        │  P0 任务       │  P1/P2 任务
        │                │  学习/规划/锻炼
        ├────────────────┼────────────────→
不重要 ↓│  🟠 第III象限  │  ⚪ 第IV象限
        │  (委托/简化)   │  (删除/忽略)
        │  干扰/部分会议  │  无意义的事
        │  P3 或外包     │  直接砍掉
```

**应用技巧**:
- **第 I 象限**: ≤ 20% 时间（救火模式不可持续）
- **第 II 象限**: ≥ 50% 时间（重点投资区）
- **第 III 象限**: ≤ 25% 时间（学会说"不"）
- **第 IV 象限**: 0% 时间（果断删除）

> 📖 详细应用指南: [todo-methods.md](../references/todo-methods.md)

---

### Step 3: 编写 TODO.md

#### 标准模板（推荐）

```markdown
# {项目名} 待办事项 ({周期})

> 周期: {start_date} ~ {end_date} | 负责人: {owner}
> 对齐目标: [ROADMAP.md O{N}-KR{M}](./ROADMAP.md#{anchor})

---

## 📍 本周期重点

**核心目标**: {一句话说明本周/本Sprint最重要的1-2件事}

**成功标准** ({Done的定义}):
- [ ] {criteria_1}
- [ ] {criteria_2}
- [ ] {criteria_3}

---

## 🚀 P0 - 必须完成 (Must Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 1: 动宾结构的简短标题}

- **负责人**: @{who}
- **类型**: 🔧Feature / 🐛BugFix / 📝Docs / 🔬Research / 🎨Design
- **优先级原因**: {为什么是P0?（阻塞/核心/承诺）}
- **预估工时**: {X}h (或 {X} story points)
- **截止日期**: {when} (或 Sprint Day {N})
- **依赖**: 无 / 依赖于 #{issue} / 被 #{issue} 依赖
- **验收标准 (DoD)**:
  - [ ] {done_criteria_1}
  - [ ] {done_criteria_2}
- **备注**: {额外信息/链接/上下文}

### [ ] {Task 2: ...}
...（同上格式）

---

## ⭐ P1 - 应该完成 (Should Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 3: ...}
...（同上格式，优先级改为 P1）

---

## 💡 P2 - 可以做 (Could Do)

> ⏰ 预估总工时: {X}h | 任务数: {N}

### [ ] {Task 4: ...}
...

---

## ❄ P3 - 未来考虑 (Won't / Backlog)

> 这些任务本轮不做，放入 Backlog 或下个周期考虑

- [ ] {Task 5: ...} （原因: {为什么推迟}）
- [ ] {Task 6: ...} （原因: {why}）

---

## 🚧 阻塞项 & 依赖关系

### 当前阻塞
| 被阻塞的任务 | 阻塞来源 | 预计解除时间 | 应对措施 |
|-------------|---------|------------|---------|
| #{task} | {what blocks it} | {when} | {workaround} |

### 关键依赖
| 任务 | 依赖项 | 类型 | 状态 |
|------|--------|------|------|
| {task} | {dependency} | 🔗内部/🔗外部/🔗上游 | ✅就绪/⏳等待中 |

---

## 📈 进度概览

| 维度 | 数据 |
|------|------|
| **总任务数** | {N} |
| **已完成** | {X} ({%}) |
| **进行中** | {Y} ({%}) |
| **未开始** | {Z} ({%}) |
| **预估总工时** | {X}h |
| **已消耗工时** | {Y}h |
| **剩余工时** | {Z}h |

### 燃尽趋势（可选）
```
理想线 ────╮
           ╭╯
实际线 ╭───╯  ╰── (手绘或ASCII)
      Day1 Day3 Day5 Today
```

---

## 📝 备注 & 变更记录

### 本周期调整
| 日期 | 变更内容 | 原因 |
|------|---------|------|
| {date} | {change} | {reason} |

### 待确认事项
- [ ] {pending_item_1} (需要谁确认)
- [ ] {pending_item_2}

---

*最后更新: {date} | 下次站会: {standup_time}*
```

---

### Step 4: 工作量估算（可选但推荐）

#### 估算方法

| 方法 | 适用场景 | 单位 | 准确度 |
|------|---------|------|--------|
| **时间估算** | 个人任务 | 小时(h) | 中（受经验影响） |
| **Story Points** | 敏捷团队 | 点数(1/2/3/5/8...) | 相对准确 |
| **T-shirt Sizing** | 快速粗估 | XS/S/M/L/XL | 粗略但快 |

**T-shirt Sizing 参考标准**:

| Size | 含义 | 典型工时（参考） |
|------|------|----------------|
| **XS** | 极小（< 2h） | < 2 小时 |
| **S** | 小（半天） | 2-6 小时 |
| **M** | 中等（1-2天） | 6-16 小时 |
| **L** | 大（3-5天） | 16-40 小时 |
| **XL** | 特大（> 1周） | > 40 小时 |

**估算原则**:
1. **独立估算**: 不要受其他任务影响
2. **包含缓冲**: 增加 20-50% 的不确定时间
3. **区分理想时间 vs 实际时间**: 理想时间 × 1.5 ≈ 实际时间
4. **定期校准**: 记录实际耗时，修正未来估算

---

### Step 5: 质量验证

#### TODO 质量检查清单

```bash
# 基础统计
echo "=== TODO 质量检查 ==="
echo "文件行数: $(wc -l < TODO.md)"
echo "总任务数: $(grep -c '^- \[' TODO.md)"
echo ""

# 优先级分布
echo "=== 优先级分布 ==="
grep -cE '\[P0\]|🔴.*必须' TODO.md || echo "P0: 0"
grep -cE '\[P1\]|🟡.*应该' TODO.md || echo "P1: 0"
grep -cE '\[P2\]|🟢.*可以' TODO.md || echo "P2: 0"

# 关键字段完整性
echo ""
echo "=== 字段完整性 ==="
tasks_with_owner=$(grep -c '@[a-zA-Z]' TODO.md)
tasks_with_deadline=$(grep -cE '(截止|deadline|Sprint Day)' TODO.md)
tasks_with_estimate=$(grep -cE '(工时|story point|h$|SP)' TODO.md)
total_tasks=$(grep -c '^- \[' TODO.md)

echo "有责任人: $tasks_with_owner/$total_tasks ($(($tasks_with_owner*100/$total_tasks))%)"
echo "有截止日期: $tasks_with_deadline/$total_tasks ($(($tasks_with_deadline*100/$total_tasks))%)"
echo "有工时估算: $tasks_with_estimate/$total_tasks ($(($tasks_with_estimate*100/$total_tasks))%)"
```

**通过标准**:
- [ ] 总任务数在合理范围（个人 5-15 个/周，团队 8-20 个/Sprint）
- [ ] P0 任务占比 10-20%（过多则焦点分散）
- [ ] ≥ 80% 任务有责任人
- [ ] ≥ 80% 任务有截止日期
- [ ] ≥ 60% 任务有工时估算
- [ ] 依赖关系已标注

---

## 快速路径（极简模式）

如果只需要一个**简单的 TODO 清单**（如个人每日待办），使用极简模板：

```markdown
# TODO - {date}

## 🎯 今日重点
{最重要的1-2件事}

## ✅ 任务列表

- [ ] 🔴 {紧急重要任务} (@me, 截止: 今天)
- [ ] 🟡 {重要不紧急任务} (@me, 截止: 本周)
- [ ] 🟢 {一般任务} (@me, 有空再做)

## 📌 备注
{任何需要记住的事情}

---
*上次更新: {time}*
```

**适用场景**:
- 个人日常待办
- 会议 Action Items
- 临时性的任务备忘

## 与 ROADMAP 的对齐

### 如何从 ROADMAP 拆解到 TODO？

```
ROADMAP (远期)                      TODO (近期)
─────────────                     ─────────────
O1: 打造卓越的用户体验              │
  KR1: NPS 从 30 → 60             │
    Q2-KR: NPS 提升 15 点          │
      M2: 反馈系统上线 (5/1)      │ → P0: 完成反馈系统前端开发
                                  │ → P0: 部署到测试环境
                                  │ → P1: 编写用户引导文案
                                  │ → P2: 设计感谢页面UI
```

**对齐原则**:
1. 每个 P0 任务应该能追溯到某个 KR 或里程碑
2. P1/P2 任务可以是探索性或优化类的（不一定直接对应 KR）
3. 如果发现 TODO 和 ROADMAP 完全脱节 → 需要重新审视

## 常见问题

**Q: P0 太多怎么办？**

A: P0 应该控制在 **总数的 10-20%**（通常 1-3 个）。如果 P0 过多：
- 重新评估：真的都是"必须"吗？
- 向上升级：是否需要调整 ROADMAP 的期望？
- 拆分周期：将部分 P0 移到下一个周期

**Q: 任务粒度多大合适？**

A: 推荐：
- **个人**: 半天~2天能完成的任务
- **敏捷团队**: 1个 Sprint（2周）内能完成的 Story
- **原则**: 如果一个任务 > 3天，考虑拆分为子任务

**Q: 估算不准怎么办？**

A: 这是正常的！改进方法：
1. **记录实际耗时**：每次完成后记录真实用时
2. **定期校准**：每月回顾一次估算偏差
3. **使用相对估算**：Story Points 比绝对时间更稳定
4. **增加缓冲**：预留 20-50% 的应急时间

**Q: TODO 需要每天更新吗？**

A: 取决于场景：
- **个人**: 每日晨间更新（5分钟）
- **小团队**: 每日站会同步（15分钟）
- **大团队**: 通过看板工具实时更新（Jira/Trello/Notion）

## 注意事项

⚠️ **规划 ≠ 执行**: TODO 是"做什么"，不是"怎么做"。后者需要在执行过程中细化。

⚠️ **保持动态**: TODO 应该**每周或每 Sprint 更新**，不是写完就不变的。

⚠️ **避免过度填充**: 宁可少放任务（留缓冲），也不要填满导致无法完成（挫败感）。

⚠️ **学会说不**: 不是所有任务都必须进入 TODO。P3/Won't 要敢于拒绝或延期。

⚠️ **对齐远期**: 定期检查 TODO 是否还在支撑 ROADMAP 的方向，避免战术上的勤奋掩盖战略上的懒惰。