一位扑克高手，教 FDE 回答“这能成吗”

一位在世界顶级扑克牌手之列待了二十年的玩家，写了一本关于决策的书。出版社简介里最让人记住的一句话，不是什么制胜秘诀，而是一句坦白：即便是最好的决策，也不一定带来最好的结果。

对前线部署工程师（FDE）来说，这句话几乎就是岗位描述。

你坐在客户现场，手里的数据不完整，面对的遗留系统从没人画过架构图，客户还是会问：“什么时候能做完？能不能成？”Thinking in Bets 不是技术书，但它训练的是很少有工程师学过的一项能力：坦诚面对不确定性，同时守住客户的信任。

作者是谁，这本书押注的是什么？

本书全名 Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts，由企鹅兰登书屋（Penguin Random House）旗下的 Portfolio 出版。精装本和电子书于 2018 年 2 月 6 日上市，平装本于 2019 年 5 月 7 日上市。它面向普通读者，曾登上美国全国畅销书榜。

Annie Duke 不只是扑克牌手。她曾获美国国家科学基金会（National Science Foundation）奖学金，在宾夕法尼亚大学攻读认知心理学，并于 2014 年联合创办了 Alliance for Decision Education。因此，这本书既有牌桌上的经验，也有心理学的功底。

核心论点很简洁。每个决策都受两类不确定性影响：无法控制的运气，以及看不到的隐藏信息。Duke 认为，每次做决定，我们都在押上自己看重的东西，不只是钱。对 FDE 而言，筹码是客户的时间、你的信誉，以及客户对产品的信任。

观点一：好结果什么也证明不了

Duke 把一种错误称为“结果论”（resulting）：倾向于把决策质量等同于结果质量。好结果可能只是运气，这样你从中什么也学不到。

设想一个团队没在真实数据上测试，就把数据管道推进了客户环境，演示却依然顺利。团队由此认定自己的流程没问题。按 Duke 的说法，这就是结果论：下一次数据会更乱，流程就会崩。

反过来同样容易得出错误教训。假设团队在真实数据上做了充分测试，也备好了回滚方案，上线当天却碰上第三方 API 宕机。就团队当时掌握的信息而言，这个决策依然合理；出问题的是团队无法控制的那部分运气。

不要因为一次坏结果就推翻整套流程。

下次复盘时画两栏：一栏写团队做决定时知道什么，另一栏写哪些归于运气。只有第一栏里才有教训。

观点二：用概率说话，别做承诺

Duke 指出，发生概率恰好为 0% 或 100% 的事情极少。她把如实表达自己的认知程度视为好决策的一部分。这个程度往往是“不确定”，说出来并不丢人。

简单算一笔账，就能看出这种说法的好处。与其承诺“Agent 会把工单处理时间缩短 30%”，不如写“六周内缩短 30% 的概率为 70%”。

如果你做了 10 个这样的估算，大约应有 7 个成真。10 个全中，说明你过于保守；只中 4 个，说明你过于自信。

客户也因此有了可以据以规划的依据。知道有 30% 的可能落空，他们就会提前准备备选方案，而不是到第六周措手不及。把各个项目的估算记下来，日积月累就能看出你的数字有多可信。

观点三：见客户之前，先找人质疑你

Duke 建议组建一个“决策小组”（decision group）：一个小团体，帮助每位成员把决策背后的信念明确说出来。FDE 常常独自在客户现场工作，很容易把一个没人检验过的假设带进会议室。

方法很简单：每次周报之前，请另一位 FDE 或产品团队的同事问你一句“为什么是 70，不是 50？”如果答不上来，这个数字就还不能交给客户。

谁该读，怎么读？

这本书适合需要给客户写进度报告的 FDE，也适合想转做 FDE 的软件工程师，因为软件工程很少逼你补上这块短板。别指望在书里找到评测方法或统计技巧；它对 FDE 的价值在于一种心态，让你能诚实地使用那些工具。

在下一个项目开始前读完它。每读完一个观点，就马上用到当周一个真实的决策上。对职业发展而言：面试官问到失败的项目时，要把决策和运气清楚分开。

这样的回答能让面试官看到，你知道该从哪里吸取教训，而不是推卸责任或自我标榜。在简历上，“为部署时间线做概率预测，并跨项目追踪其准确度”这样的描述，如果写明实际追踪了多少个项目，会更有分量。

客户付钱给你，不是要你每次都对。他们付钱，是要你说清楚自己押的是什么，赢面有多大。