# 目标与计划

> 目标是「要到哪」，计划是「怎么去、什么时候到、路上可能卡在哪」。多数团队不是不努力，而是目标写成了任务清单，计划里没有风险与取舍。

## 一、目标的层级要接上

| 层级 | 周期 | 回答的问题 |
| --- | --- | --- |
| 方向 | 1—3 年 | 我们靠什么赢 |
| 目标 | 季度/半年 | 这个阶段必须达成什么 |
| 计划 | 月/周 | 谁在什么时候交付什么 |
| 任务 | 天 | 今天做什么 |

最常见的问题是**断层**：上面要「提升客户留存」，团队的目标是「完成 12 个需求」。任务完成了，留存没动——因为没人回答「哪 12 个需求能提升留存，凭什么」。

## 二、好目标的五个标准

1. **可衡量**：能用指标或明确事实判断完成与否；
2. **有时限**：有截止时间，且中间有检查点；
3. **有负责人**：一个目标一个 owner，不能「大家一起」；
4. **有取舍**：明确为了它不做什么；
5. **有验收**：完成后怎么判断「真的成了」，而不只是「做完了」。

反例：「优化系统性能」「提升团队能力」——都无法验收。改成「核心接口 P99 从 800ms 降到 300ms 以内，覆盖下单与支付两条链路」就能判断。

## 三、OKR 的三个常见误用

| 误用 | 表现 | 修正 |
| --- | --- | --- |
| 把任务当 KR | KR 写成「上线 A 功能」 | KR 写结果：「新功能带来 X% 转化提升」 |
| 目标太多 | 一个季度 6 个 O，每个 4 个 KR | 最多 3 个 O，聚焦真正关键的 |
| 只定不跟 | 季度初写完就锁进抽屉 | 双周检查进度，季度末复盘 |

OKR 是沟通工具，不是考核工具。一旦直接挂钩绩效，所有人都会把目标定得保守且容易完成。

## 四、拆解：从结果倒推驱动因素

目标 → 驱动因素 → 举措 → 任务。以「季度新增付费用户 +20%」为例：

```text
目标：新增付费 +20%
  ├ 流量 ×   → 渠道投放、内容获客
  ├ 转化率 × → 落地页、试用流程、定价页
  └ 留存 ×   → 首周激活、关键功能引导
```

拆解的价值在于**知道每个举措影响哪个因子、影响多少**。没有这层，团队只能凭感觉抢需求。

## 五、计划：估算、关键路径、风险

| 要素 | 做法 |
| --- | --- |
| 估算 | 三点估算（乐观/最可能/悲观）取加权，再加 20%—30% 缓冲 |
| 关键路径 | 找出决定总工期的链路，优先保障资源 |
| 依赖 | 列出外部依赖（其他团队、供应商、审批），提前锁定时间 |
| 风险 | 每条风险写「触发信号 + 应对动作 + 负责人」 |
| 里程碑 | 每 2—4 周一个可验收节点，避免最后才发现延期 |

计划里最容易被忽略的是**外部依赖**：内部排得再漂亮，等一个跨部门接口就能拖两周。

## 六、执行：节奏比工具重要

- **周会**：只看三件事——上周承诺完成没、本周关键路径是什么、有什么阻塞需要我处理；
- **看板**：让状态可见，避免「口头同步」造成的信息差；
- **月度复盘**：目标进度、偏差原因、下月调整；
- **季度复盘**：目标是否达成、哪些假设错了、下季度改什么。

会议开成「每个人汇报做了什么」，说明目标和分工没定清楚。

## 七、计划是假设，要允许校准

季度中一定会出现新信息：需求变化、人员变动、技术风险暴露。好的做法是**提前约定校准机制**：什么情况下可以调整目标、谁来批、调整后如何同步。没有校准机制，团队要么硬扛到崩，要么偷偷降低标准。

## 八、自检清单

- [ ] 团队季度目标能用一句话说清，且有明确验收口径
- [ ] 每个目标有唯一负责人，不是「大家一起」
- [ ] 目标里写明了「为了它不做什么」
- [ ] 每个举措都能对应到目标的一个驱动因素
- [ ] 计划里有外部依赖与风险清单，不是只有任务列表
- [ ] 有固定的检查节奏，偏差能在一周内被发现
- [ ] 季度末能说清「哪件事做对了、哪件事白做了」