当团队超负荷时，你用什么标准来决定先做什么？

Question

Accepted Answer

**首先，我让超负荷变得可见，并停止假装所有东西都装得下。** 当一个团队超负荷时，失败模式是每样都做一点、却什么都做不完。我的工作是强制进行明确的优先级排序，并保护团队免于来回折腾。

## 我应用的标准

- **影响 vs. 投入。** 我按交付的价值对照成本来排序。高影响、低投入的项先做；高投入、低影响的项被公开地砍掉或推迟。
- **可逆性与紧迫性。** 任何不可逆或有时限的事（一个安全修复、一个合同截止日、一个发布依赖）插队。
- **延迟成本。** 有些工作等得越久越贵（不断复利的 **tech debt**、截止日罚则）；有些下个月做也一样。我按成本增长的速度来排序。
- **阻塞他人。** 解除他人或他队阻塞的工作，具有超出其自身价值的乘数效应。
- **风险。** 如果这件事做错了或晚了，代价是什么？先防住代价昂贵的失败。

## 一个简单的框架

| 桶 | 例子 | 行动 |
|---|---|---|
| 关键 + 紧急 | 生产 incident、安全漏洞 | 立刻做，放下其他工作 |
| 高价值、不紧急 | 关键 roadmap 功能 | 排期并保护 |
| 低价值、紧急 | 吵闹但次要的请求 | 顶回去或委派 |
| 低价值、不紧急 | 锦上添花 | 说不，明确砍掉 |

## 我如何推进

- 做**一份排了序的列表**，而不是五个并行的“最高优先级”。如果所有东西都是优先，那就没有优先。
- 用直白的话向 **stakeholder** 沟通取舍：“这个 sprint 我们能做 A 或 B，不能两个都做。哪个更重要？”
- 保护专注：限制在制品、减少上下文切换，并在 sprint 中途屏蔽掉新的打断。

## 陷阱

- 让最吵的 stakeholder 而非数据来定优先级。
- 对所有事都说是，这其实就是说“我让随机来决定吧”。
- 为塞进范围而悄悄削减质量；那只是把成本转移到了生产环境。

## 为什么这很重要

在超负荷下，无情而透明的优先级排序，能把一个紧张、来回折腾的团队，变成一个能交付真正要紧之事的团队；并且它通过对取舍诚实，而不是悄悄地什么都误掉，来维系与 stakeholder 的信任。

桶	例子	行动
关键 + 紧急	生产 incident、安全漏洞	立刻做，放下其他工作
高价值、不紧急	关键 roadmap 功能	排期并保护
低价值、紧急	吵闹但次要的请求	顶回去或委派
低价值、不紧急	锦上添花	说不，明确砍掉