书籍与课程

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

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

Stephane Trinh
FDE Times 编辑2026年11月2日 · 6 分钟阅读

要点速览

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

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

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

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

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

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，现在就可以拿所在团队的待办列表练手。

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

这篇文章对你有帮助吗？

6 个信源