一种将目标、负责人、风险和评审点连接起来的直接方法，而不会将交付跟踪变成沉重的流程。
传统计划的问题
大多数项目计划失败的原因是它们要么过于僵化（无法适应变化），要么过于模糊（无法提供指导）。真实项目需要介于两者之间的方案。
核心原则
1. 跟踪成果，而非任务
与其列出数百个任务，不如专注于交付物：
不好的做法：
- 编写 API 端点
- 创建数据库 schema
- 构建 UI 组件
好的做法：
- 用户可以提交表单并收到确认
- 管理员可以在仪表板中查看所有提交
2. 尽早暴露风险
维护一个活跃的风险登记册：
| 风险 | 影响 | 缓解措施 | 负责人 |
|---|---|---|---|
| 第三方 API 不稳定 | 高 | 构建回退机制 | Alice |
| 利益相关者范围蔓延 | 中 | 每周范围评审 | Bob |
| 关键开发人员可用性 | 高 | 团队成员交叉培训 | Carol |
每周评审，而非每月。
3. 定义明确的决策点
识别项目可能走向不同方向的关键时刻：
第2周：选择数据库技术
第4周：与用户验证核心工作流
第6周：决定自建还是购买报表模块
每个决策点应有：
- 明确的成功标准
- 由谁做决策
- 延迟决策会有什么影响
4. 明确所有权
每个交付物必须有且仅有一个负责人。不是一个团队，不是”待定”——一个人。
交付物: 用户认证系统
负责人: @alice
截止: 第3周
依赖: 数据库搭建完成
成功标准: 用户可以注册、登录和重置密码
5. 有效的评审节奏
每日（15分钟）： 障碍和即时需求
每周（60分钟）： 进展、风险、下周优先级
双周（90分钟）： 演示可用软件，调整计划
跳过不能产生决策或解除阻碍的会议。
模板：一页交付计划
# 项目：[项目名称]
## 目标
- 目标1（负责人，截止日期）
- 目标2（负责人，截止日期）
## 当前冲刺（第X-Y周）
- 交付物A → 负责人
- 交付物B → 负责人
## 前3大风险
1. 风险描述 → 缓解措施
2. 风险描述 → 缓解措施
3. 风险描述 → 缓解措施
## 后续决策点
- 日期: 待做的决策 → 标准
- 日期: 待做的决策 → 标准
## 阻碍项
- 阻碍1 → 谁在解决
- 阻碍2 → 谁在解决
保持这张图始终可见。每周更新。广泛分享。
计划何时会失败
计划失败的原因是：
- 创建后从未更新
- 跟踪的是活动而非成果
- 隐藏坏消息
- 只由项目经理掌控，而非由团队共有
修复方法： 让计划成为团队活动。基于现实而非期望来更新计划。
结论
好的交付计划是帮助团队应对不确定性的活文档。它们不是为了预测未来——而是为了在当下创造清晰。
保持简单、保持更新、保持诚实。