# 一道除法，决定先做客户的哪个需求

> Edmond Lau 称之为杠杆，即每小时投入创造的价值；驻场时人人都说自己的事最急，它帮你排出先后。

原文: https://fdetimes.net/zh/books-courses/effective-engineer-fde-leverage/

Goodreads 上的图书简介给出了一个大胆的承诺：最优秀的工程师能产出别人 10 倍的影响，却不必多花 10 倍的工时。如果这周你手上有 12 个客户需求，时间却只够做 4 个，那么最值得问的问题是：这种差距从何而来？

Edmond Lau 在 2015 年 3 月出版的 *The Effective Engineer* 中给出的答案只有一个词：杠杆率。该书官网把它定义为单位投入时间创造的价值，全书约 250 页，都围绕这个框架展开。

这本书写给所有软件工程师，套用到前线部署工程师（FDE）的工作上，需要自己转换。不妨把它放进驻场的一周里：提需求的人就坐在你旁边，每个人都说自己的任务很急，而先做什么由你决定。

## 一道除法，凭什么撑起一本书？

Lau 在这个观点上始终如一。2015 年接受 Glitch 采访时，他建议优先做那些相对投入时间影响更大的工作。两年后在 Intercom 的播客上，他对杠杆率的定义仍然没变：用投入的时间创造了多少影响。

假设你正处在一个 12 周项目的第 3 周，为客户部署一套记录处理系统。每天进来 300 条记录，其中 30%，也就是 90 条，需要人工修正。手上有三项任务，下面的数字都是假设的估算，统一用一个单位：到项目结束时节省的工时。

| 任务 | 投入工时 | 节省工时 | 杠杆率 |
|---|---|---|---|
| A. 按部门主管的要求修改报表格式 | 3 | 0 | 0 |
| B. 写脚本检查每周都会出问题的输入文件 | 8 | 4 小时 × 9 周 = 36 | 4.5 |
| C. 修复导致一半人工修正记录的 bug | 16 | 3 小时 × 45 天 = 135 | 约 8.4 |

C 行的假设是每天少 45 条需要修正的记录，每条耗时 4 分钟。B 和 C 都按“开工当天修复即生效”计算。耗时最多的任务杠杆率最高，而最可能换来一句感谢的任务排在最后。

这些数字不必精确，它们只用来排序。但不妨故意把它们算错：如果 C 节省的工时只有估算的一半，杠杆率就降到约 4.2，低于 B 的 4.5。无论 A 的投入工时怎么估，它都排在最后，因为它根本不节省工时。

所以 B 和 C 的先后取决于“45 条、4 分钟”这个假设。投入 16 小时之前，先数一数今天 90 条人工修正的记录里，有多少正是这个 bug 造成的，再给其中几条计时。

## 驻场的杠杆率有保质期

把 Lau 的除法用在有截止日期的项目上，会看到更多东西。还是任务 B：如果第 11 周才开始做，只剩 1 周来回本，投入 8 小时、节省 4 小时，杠杆率降到 0.5。

任务 C 也降到约 0.9：3 小时 × 5 天 = 15 小时节省，对应 16 小时投入。实际情况还要更低，因为 8 到 16 小时的开发时间本身就占用了最后这一周。到了项目后期，值得做的任务可能已经不是修复，而是一份交接文档，让客户团队自己处理这个问题。

反过来，如果脚本 B 能在下一个客户那里复用，分母不变，分子却在增长。所以动手写之前，先问一句：你离开之后，它还能用多久？

**要点:** 任务的杠杆率随驻场剩余周数而变化。

## 值得记住的三个观点

第一，寻找放大点，而不是做更多。Lau 把高效工程师描述为善于寻找能放大投入的那些点的人。在客户现场，接下需求之前先问：有没有办法只用一小部分工时达到同样的结果？

第二，用共同指标说“暂时不做”。在 Intercom 的播客上，Lau 建议把优先级与团队使命和一个共同指标挂钩，让每个人无论专长是什么，都瞄准同一个数字。

在上面的例子里，这个指标可以是无需人工修正的记录占比：任务 C 能把它从 70% 提到 85%，任务 A 则完全不影响它。

第一周就和客户定下这个指标，这样拒绝就不再只是你的个人意见。即便如此，也不要机械套用：如果那位部门主管在上线当天有话语权，花 3 小时做任务 A 仍然值得。把它当作维护关系的成本，严格控制在 3 小时以内，别把它误当成高杠杆的工作。

第三，把难做的事放在状态最好的时段。Lau 建议把精力最充沛的时间留给那些你总想往后拖的高杠杆任务。

任务 C 正是这一类：需要 16 小时专注，短期内没人会感谢你，很容易被会议和消息吞掉。把上午留给它，客户会议挪到下午。

## 谁该读，按什么顺序读？

这本书最适合那些整天忙个不停、到了晚上却说不出自己改变了什么的人。准备从软件工程师（SWE）转做 FDE 的人也该读一读，在第一天驻场之前先练习安排自己的工作。

官网称它是许多团队的必读书，并承诺能加速你的职业发展，但更可靠的检验在你自己的任务清单里。

据一位读者的总结，全书第一部分讲的是如何给工作和项目排优先级：先读这一部分，给手上未完成的需求打分，然后再往下读。

每章末尾都总结了可以马上采用的习惯。在每个项目开始时把这几页当作检查清单，一次只挑一个习惯。

也别指望这道除法包办一切。它能给已知的任务排序，但找出客户真正的问题，仍然要靠需求调研。

## 把它变成求职时的案例

简历上写一个书名，证明不了你会挑活；有数字支撑的决策才可以。所以别把书名写进简历，而是写一行包含三部分的内容：你选择做的任务、你搁置的任务，以及发生变化的指标。

阅读职位描述时，留意“ambiguous priorities”或“multiple stakeholders”这类说法，然后准备一个按上面表格结构组织的例子，一个就够。如果你还不是 FDE，现在就可以拿所在团队的待办列表练手。

下次客户那边有人发消息说“这个很快”，你会有一个比“什么时候要？”更好的问题：在剩下的几周里，它能创造什么？

**本周动手试试:**

- 列出客户那里所有未完成的需求，标注估算工时和到项目结束时创造的价值，再按这道除法排序。
- 与客户对接人定下唯一一个共同指标，标出那些对它毫无影响的需求。
- 把你最想往后拖的高杠杆任务，放进明天头脑最清醒的时段。

## 信源

- [The Effective Engineer (official site)](https://www.effectiveengineer.com)

- [The Effective Engineer – Book (official site)](https://www.effectiveengineer.com/book)

- [The Effective Engineer – Goodreads](https://www.goodreads.com/book/show/25238425)

- [Quip's Edmond Lau on how to become a more effective engineer (Intercom)](https://www.intercom.com/blog/podcasts/quip-edmond-lau-the-effective-engineer)

- [How to Maximize Your Impact as a Software Engineer (Glitch)](https://blog.glitch.com/post/how-to-maximize-your-impact-as-a-software-engineer)

- [[Book Summary] The Effective Engineer, by Edmond Lau](https://learningcube.substack.com/p/book-summary-the-effective-engineer)