当别人要求你更快、却不给你更多人手时，你会怎么做？

Question

Accepted Answer

反正在短期内加人也很少能让团队更快，所以真正的问题是：团队的*时间实际花到哪去了*，以及我能对此改变什么？我把“更快”当作一个寻找杠杆的提示，而不是一个加班更久的要求。

## 我从哪里寻找速度

- **削范围，而非偷工减料。** 更快交付最快的办法是少造。我和 PM 一起无情地排优先级，找到那个能交付价值的最小版本。大多数功能是用 20% 的工作交付 80% 的价值。
- **消除摩擦和等待时间。** 瓶颈往往不是编码速度 —— 而是慢 CI、不稳定的测试、痛苦的部署、慢 review，或等待审批。修好一个 30 分钟的构建或两天的 review 周转，能免费买来真实的 velocity。
- **减少在制品。** 同时玩十件事的团队什么都做不完。专注于更少的并行项能让东西更早交付。
- **自动化重复劳动。** 手工测试、手工发布、手工环境搭建 —— 投入一次，永久省下。
- **偿还那些正在主动拖慢你的 debt。** 不是全部；只是团队每天绊到的那部分。
- **保护专注时间。** 更少的会议和打断，可能比任何工具都是更大的胜利。

## 我如何回应这个要求

我不会只说“不可能”，也不会默默接受。我以一个**取舍**来回应：“如果我们砍掉功能 A 和 B，或者接受测试上更高的风险，我们能赶上那个日期。这是我的建议。”这把速度变成一个共同的、有意识的决定，而不是一场悄悄的质量赌博。

## 需要避免的陷阱

- **强制加班。** 它买来一段短跑，却用 burnout、bug 和流失来偿还。
- **悄悄跳过测试和 review。** 今天的速度，下个月的宕机。
- **对日期说是却什么都不改** —— 那只是在指望运气，而指望会误期。

## 为什么这很重要

可持续的速度来自消除浪费，而非压榨人。一位以清晰取舍和流程改进来回应压力的 Tech Lead，会建立一个真正快速且耐久的团队 —— 而不是一个冲刺、崩盘、并失去其最好工程师的团队。