功能全部按期交付，客户仍可能不买账

一个工程团队可以让每个功能都按期上线，项目却依然失败。Melissa Perri 给这种情况起了个名字：“构建陷阱”（build trap）。陷入其中的公司成败全看产出，为了赶截止日期不停地往外推功能。

她的书《Escaping the Build Trap: How Effective Product Management Creates Real Value》由 O’Reilly 于 2018 年出版。封面上写的是产品管理，但对想做前线部署工程师（FDE）的人来说，这本书更像一份指南：教你别沦为按客户订单开发功能的“功能作坊”。

驻场工作、贴近用户开发时，速度是你最显眼的产出。正因如此，这个陷阱很难察觉：交付得越多，越容易觉得项目进展顺利。

问题出在指标，而不在努力

书中的定义很简短：构建陷阱是指组织困在用产出而非成果衡量成功的状态里。getAbstract 的摘要换了一种说法：公司往往更看重自己交付了什么，而不是客户实际得到了什么价值。

产出是团队做出来的东西：功能、API、界面。成果是这些东西给客户带来的改变。Perri 并没有说产出不好。她在 ProductCon 2022 上称产出是达成目标的手段。据 Dragonboat 的笔记，只有在没有明确目标、团队只顾“构建、构建、再构建”时，陷阱才会出现。

设想你是一名 FDE，正在为一家物流公司上线发票处理系统。六周后，报告显示交付了九个功能，没有一次延期。可会计处理每张发票仍要花大约 40 分钟，和你来之前一样。按产出看，项目很成功；按成果看，什么都没变。

现在把目标在第一周重新定下：把处理一张发票的时间从 40 分钟降到 15 分钟。很可能九个功能里只需要三个，这六周更应该花在坐到会计旁边，看他们卡在哪里。

战略是过滤器，不是计划

对 FDE 重要的第二个观点，是书中对战略的定义。在 Perri 看来，战略是一个可以立即投入使用的决策框架，帮助团队采取行动、达成想要的成果。它不是一份罗列任务的计划。

在客户公司里，这个区别非常实际。回到发票的例子：周中，财务负责人要一个把报表导出为 PDF 的按钮。如果你手里只有计划，你会问：这个需求在不在范围内？

如果你有决策框架，你会问：它能不能帮助降低那 40 分钟？如果不能，你就有了明确的理由把它往后放，而且客户也能理解这个理由。

所以这一课比起坐办公室的产品经理，更适合 FDE。FDE 每天直接听到各种需求，每答应一次，就多一项产出。没有过滤器，待办列表就会变成会上嗓门最大那个人的愿望清单。

用错了，成果也会变成陷阱

读完这本书最容易犯的错误，是把成果当作挡箭牌，拒绝一切需求。那个 PDF 按钮也许正是财务负责人向上级汇报数据所需要的，也就是说，它服务于一个你还没听说的真实问题。在说“暂时不做”之前，先问清楚对方要它做什么。

第二个错误是选了一个无法衡量的成果，比如“让客户更满意”。40 分钟这个数字之所以有用，正是因为它能在前后两个时间点测量。无法衡量的目标，什么也过滤不了。

最后一个错误是自己定下成果，却只放在心里。如果客户没有认可 15 分钟这个目标，你的过滤器就只是个人意见，每次拒绝都会变成一场争论。第一周就和客户把这个数字定下来。

Perri 个人网站上介绍这本书的页面，把终点描述为建立一种以客户为中心、重成果轻产出的文化。FDE 改变不了整个客户公司的文化，但可以把这种思维方式带进每一次会议、每一张工单和每一份周报。

谁该读，怎么读

这本书适合有两到八年经验、习惯了接工单再关工单，现在想转向自己决定做什么的开发者。在第一次驻场部署之前读，因为陷阱最容易出现在前几周：那时你正急于证明自己能交付。

不要一口气读完就放下。读完定义构建陷阱的那一部分，打开当前项目的待办列表，在每一项旁边写上一个可衡量的成果。读到战略那一部分时，试着为当前客户写一句目标，要具体到能拿来当过滤器。

看 FDE 岗位描述时，留意它谈的是对客户的影响，还是只罗列需要掌握的技术。在简历上，把“开发了 12 个接口”换成一句带有用户侧前后对比数字的描述。这样一句话能让读者看出你已经在用成果思考，而这正是这本书要教的。

在客户公司，没人记得你上线了多少功能。他们记得的是你来之后，什么变快了、变便宜了，或者没那么痛苦了。