# 演示出错只丢一个流程，慌乱会毁掉整场会议

> 承认一次、不现场修补、按严重程度切换预案，生产环境出故障时也用得上。

原文: https://fdetimes.net/zh/guides/demo-fails-in-front-of-customer/

你点下“运行”。进度条卡住，接着投影上跳出一行红色报错，客户那边所有人都看在眼里。

Reprise 的博客准确描述了这一刻的本能反应：慌乱，然后一连串道歉。但 Reprise 也指出，主讲人一旦流露出慌乱，客户就会不自在，也不再专注于你在讲什么。技术错误让你损失一个演示流程，慌乱却可能让你输掉整场会议。

如果你是前线部署工程师（FDE），不妨把演示失败当作一次预演：系统真正上线运行后，你可能会遇到类似的事故。两种场合要做的事是一样的：说实话，快速决断，兑现承诺。

## 第一分钟只做三件事

第一件事是把问题说出来。MangoApps 建议承认一次问题就继续往下走，赶在沉默变成怀疑之前。关键在“一次”：第三次道歉不会增加任何信息，只会让所有人一直惦记着这个错误。

第二件事是不要在台上修。Atomic Object 博客上的一篇文章说得很直白：演示时不该为了挽回面子去推送代码，或者对环境做有风险的改动。全场等着的时候匆忙写出来的补丁，可能把一个 bug 变成两个。

第三件事是给故障定级、选好路线，因为每一级需要不同的应对方式。一旦知道自己处在哪一级，就不必在脑子压力最大的时候临场想办法。

| 故障等级 | 表现 | 应对方式 | 需要提前准备 |
|---|---|---|---|
| 局部 | 某一步失败，其余部分仍能运行 | 记下问题，换一条路线 | 一条测试过的备选流程 |
| 主流程中断 | 核心步骤跑不起来 | 切换到视频或截图，并明确说明是录制内容 | 视频、截图、文本输出 |
| 全面故障 | 环境无法使用 | 使用点击演示版；必要时干脆收尾 | 点击演示版、一个拟定的下一步 |

## 45 分钟的会议，第 18 分钟出错

假设你在给一家物流公司演示一个发票对账 Agent。流程分三步：上传一批发票，让 Agent 与订单逐一匹配，最后导出一份异常报告。第 18 分钟，匹配这一步返回了 500 错误。这是主流程，所以你处在第二级。

你只说一次。原因还不清楚时，不要把锅甩给 Wi-Fi 或客户的基础设施：

> “匹配这一步刚刚报错了，原因我还不清楚。我的同事会另外排查，我先继续，让大家仍然能看到最终结果。”

Atomic Object 把这位同事称为支援搭档（wing person）：主讲人继续往下讲时，这个人随时准备排查问题或准备数据。他们的观点很明确：不要指望碰巧有人出手，要事先安排好。在会议室里，这个人去翻日志，你去打开录好的视频。

> “这是我会前录的视频，用样例数据跑的同一个流程。请大家关注异常报告，我会在那里暂停。”

要明确说明这是录制内容。如果客户以为自己看的是在线系统，事后才发现真相，你失去的就不再是一个演示流程，而是他们的信任。

接着，财务负责人问：“如果生产环境出现这个错误会怎样？”Reprise 建议，被问住时，平静地表示稍后回复。这里诚实的回答是给出一个期限，而不是一个保证：

> “原因我还不知道，所以没法给您确切答复。今天下午我会发邮件告诉您原因和处理方式。”

## 小错误可能暴露真实需求

几分钟后，支援搭档发来私信：演示文件缺少供应商编码这一列，这是主讲人遗漏的一个需求。Atomic Object 讲过一个类似的情况：看起来像 bug 的问题，其实是用户忘了某个需求；问题被记录下来，团队获得了有用的信息，演示也照常进行。

不要只停在纠正上。先承担自己那部分错误，再把它变成一个了解客户需求的问题：

> “原因找到了：我刚才用的文件缺少供应商编码，是我准备时疏忽了。不过想问一下：你们的真实发票会不会也有缺这个字段的情况？”

在这个场景里，假设财务回答说，小供应商的发票经常缺这个字段。你刚刚发现了一项数据处理需求，如果演示一路顺利，它也许永远不会浮出水面。

现在算一下时间。第 18 分钟出错，还剩 27 分钟。花 1 分钟承认并转向，再放 3 分钟视频，仍有 23 分钟讨论客户的问题。如果对着投影排查 12 分钟，就只剩 15 分钟，而且客户已经干等了这 12 分钟。

**要点:** 演示出错时，你的任务是挽救这场会议，而不是当着客户的面修 bug。

会后，兑现你承诺的期限。Reprise 建议录一段短视频，专门展示当时没能演示的那个功能或问题，你把它连同原因和处理方式一起发出去。一段 5 分钟、恰好展示客户没看到的内容的视频，比一封长长的道歉邮件更有用。

## 备用方案必须前一天就准备好

没有人能在慌乱中想出好的备用方案，所以会议室里的从容，很大程度上是提前准备出来的。ORACLE-BASE 博客建议准备好演示的文本输出、截图，最好是视频。Reprise 还补充了点击演示版，用于极少数全面故障的情况。

每次演示前，可以按这个顺序准备。在你实际要用的环境上把整个流程重跑一遍，并在这次运行时录下视频。写一份简短的输入要求清单，例如必填的数据列、需要提前登录的账号，这样像漏掉字段这类错误就能在会前发现。

接下来，选一条测试过的备选流程，准备一份干净的数据集。指定一名支援搭档，约定一个私信渠道和一句传递消息的暗号。最后给自己定一个时限，比如 60 秒：到时还没有消息，就切换到备用方案，不再等下去。

如果所有备用方案都失败了，不要硬撑。MangoApps 建议干脆收尾，提出最合适的下一步，而不是硬着头皮走完一个坏掉的流程。话可以说得很简单：“没跑起来的部分，我想另约一个简短的时间单独演示。今天剩下的时间，我想多听听你们遇到的问题。”

## 把小错闹大的五种方式

第一种失误是反复道歉，因为每道一次歉，都会把注意力拉回故障上。与之相近的是乱猜原因：先怪网络，没多久又发现错在自己，这次更正损失的信誉比原来的 bug 还多。

第三种失误是被问到难题时硬撑。一个自信但错误的回答可能一路跟到签约，而“今天下午我把答案发给您”只需要一封邮件。

第四种是承诺了却忘了：期限过了还没有任何消息，此前为保持冷静付出的努力就全白费了。

最后一种更隐蔽：让主讲人独自排查。一个人同时讲解和看日志，两件事都做不好，客户在屏幕上也看得出来。

## 把失败变成能力的证明

这项技能很难靠简历上的一行技术栈体现，所以要用行动来展示。与其写“沟通能力强”，不如写你搭建了一套带备用方案和支援角色的演示流程，再举出一项你从事故中发现的具体需求。

面试 FDE 岗位时，准备一个演示失败的真实经历：第一分钟你说了什么，选了哪条路线，会后发了什么。如果你从没给客户做过演示，内部分享是个不错的起点。

## 练习：排练一次故意制造的故障

这周挑一个你已有的演示，请一位同事旁听。让对方在你事先不知道的时刻弄坏点什么，比如关掉一个服务，或者改掉输入文件里某一列的列名，然后扮演客户，在报错后马上问一个难题。

记下从报错出现到你说出第一句话用了多久，到你切换到备用方案又用了多久。再数一数你道了几次歉。第一次数时这个数字可能会吓你一跳，但它能准确告诉你，在真正的演示之前该练什么，因为到那时错误不会提前打招呼。

**本周动手试试:**

- 写两句承认错误、不怪任何人的话，大声读出来，直到你能完全平静地说出口。
- 为下一次演示的主流程录一段视频，放在几秒钟内就能打开的地方。
- 请一位同事在下次演示时担任你的支援人员，并在会前约定好私信渠道。

## 信源

- [Demo Fails: How to Turn Challenges Into Triumphs](https://www.reprise.com/resources/blog/demo-fails-how-to-turn-challenges-into-triumphs)

- [The Art of Failing Forward: Demo Lessons Learned](https://www.reprise.com/resources/blog/the-art-of-failing-forward-demo-lessons-learned)

- [Keep Calm and Carry On… With Your Demo](https://spin.atomicobject.com/carry-on-with-demo/)

- [Public Speaking Tip 4 : Have a disaster recovery plan!](https://oracle-base.com/blog/2014/01/02/public-speaking-tip-4-have-a-disaster-recovery-plan/)

- [Recover a Demo After a Live Glitch Template — Stay Credible | MangoApps](https://www.mangoapps.com/templates/practice_hub/recover-a-demo-after-a-live-glitch)