# 每周 30 分钟演示，免得第八周才出意外

> 前提是让客户用真实数据亲手操作软件，并以商定的改动收尾，而不是听一场汇报。

原文: https://fdetimes.net/zh/guides/weekly-30-minute-customer-demo/

设想项目进入第八周。你共享屏幕，展示一个快要完成的版本，客户的运营负责人却问了一个让全场安静下来的问题：“为什么它读不了附件？我们一半的投诉都是 PDF 发来的。”

这个问题很少说明你的代码写得差。它说明的是：整整七周，客户那边没有一个人碰过这套软件。这段时间里，每个错误假设都叠在上一个之上，到了交付那天，改起来代价很高。

对前线部署工程师（FDE）来说，这是职业风险，不是运气不好。你就坐在客户旁边，需求可能一周一变，所以防止意外最便宜的办法是固定节奏：每周 30 分钟，让客户亲手用上你刚做出来的东西。

## 这个想法比 FDE 岗位更早

《敏捷宣言》的首要原则，是尽早并持续交付有价值的软件，让客户满意。它建议每隔几周到几个月交付一次可用的软件，周期越短越好。它还把可用的软件，而不是文档，视为衡量进展的首要标准。

《Scrum 指南》补充了一点，很多团队会跳过：Sprint 评审会的目的，是检视成果并决定接下来如何调整。指南还提醒，这是一场工作会，团队应避免把它变成汇报。

两者合起来，一次真正的演示需要同时具备三点：真实的软件、客户参与、以改动收尾。缺了任何一点，都只是在汇报。

## 为什么是 30 分钟，为什么每周一次？

《Scrum 指南》规定，一个月的 Sprint，评审会最长四小时。按比例缩小，一周的周期只需要大约四分之一。30 分钟还要更轻：客户的日程里塞得下，谁都不用找上级请示。

《敏捷宣言》希望业务人员和开发人员在整个项目中每天一起工作。在客户现场，这往往很难，因为真正的用户都忙着本职工作。每周演示就是钉在日程里的最低限度接触：哪怕整周都没见面，也保证有一轮反馈。

这个节奏也适合 Sprint 更长的团队。PostHog 的 FDE 团队按两周一个 Sprint 工作，从这周一到下周五。每周演示一次，就能在 Sprint 中途检查一次，那时还来得及调整方向，结束时再检查一次。

## 一场示例演示，逐分钟拆解

假设你在为一家保险公司的客服部门部署一个 Agent，用来分拣投诉邮件。写第一行代码之前，先照 PostHog 的 FDE 团队的做法：把范围写成一份简短的需求简述，在投入开发前发给客户签字确认。这份简述就是之后每次演示的标尺。

| 分钟 | 内容 | 谁握鼠标 |
|---|---|---|
| 0–3 | 根据简述重申本周目标，以及上周的决定 | FDE |
| 3–18 | 客户从自己的收件箱里取 5 封真实邮件来跑 | 客户方用户 |
| 18–25 | 提问、指出问题、一起排优先级 | 双方 |
| 25–30 | 念出决定，商定下周工作 | FDE |

最关键的是第 3 到 18 分钟。你不表演，而是说：“能不能挑这周最难处理的五封邮件，贴到这里？”Agent 分错一封时，先别急着解释，而是问：“换作是您，这封邮件会归到哪一类？依据是什么？”

这个问题的回答，是这一周最有价值的数据。如果她说“看附件就知道了”，你就在第二周发现了本文开头那个场景要等到第八周才暴露的问题。

Insight Partners 引述的一位 FDE 说，一次演示的价值远超多轮交谈。这 15 分钟说明了原因。

最后五分钟用来念出决定：“下周：加一个读取 PDF 的步骤；去掉‘其他’类别，因为没人用；CRM 集成先搁置。”有异议的人当场提出，而不是事后发邮件。

**要点:** 没有以一条记录在案的改动收尾的演示，仍然只是一场汇报。

## 反馈只有传出去才算数

演示结束一小时内，发出一份回顾，分三部分：客户看到了什么，双方决定了什么，下周会有什么。如果某个决定偏离了原始简述，要明确指出，并请客户再次书面确认。今天没记下来的小改动，到了交付那天很容易变成意外。

反馈还要传到你自己的产品团队。PostHog 的 FDE 团队把自己看作客户真实使用方式与产品路线图之间最快的反馈回路。

Insight Partners 同样强调，通往产品的反馈回路必须是有意为之的。每周回顾附上一句“保险客户需要读取附件 PDF”，正是这种有意为之的工作。

## 让演示沦为走过场的五个错误

最常见的错误是放幻灯片而不是展示软件。幻灯片只能说明你打算做什么，可用的软件才是进展的证明。第二个错误是用自己编的样例数据演示：这些数据本来就是为了跑得顺而写的，恰好藏住了客户最关心的疑难情况。

第三个错误是只邀请项目发起人，不邀请每天要用这套系统的人。发起人批准方向，找出问题的却是用户。

第四个错误是隐藏还没修好的部分。给客户看一个做了一半的功能，也好过以“这周没什么可看”为由取消，因为取消一次，很容易变成习惯。

最后一个最隐蔽：演示很顺利，却什么都没决定。如果回顾里“已决定”一栏连续三周都是空的，你就是在汇报，而不是在和客户一起工作。

## 练习：为示例演示写回顾

回到那家保险公司的演示。设想结果如下：组长跑了 5 封邮件，Agent 分对 3 封、分错 2 封，两封的投诉内容都在附件 PDF 里；没人选“其他”类别；她还说 CRM 集成不急。设一个 10 分钟的计时器，先写出三部分回顾，再往下读。

合格的版本大致如此。看到：5 封中 3 封分类正确，两封出错都是因为投诉写在 PDF 里。决定：加一个读取 PDF 的步骤，去掉“其他”类别，CRM 推迟到以后。下周：重跑这 5 封邮件，外加 5 封带附件的新邮件。

然后用三个问题给自己的版本打分。哪个决定偏离了简述，有没有一句请客户再次确认？哪一句需要发给产品团队？没参加演示的人，能否看懂下周要展示什么？

## 把演示节奏变成求职优势

如果你想证明自己能和客户快速迭代，而不只是会写代码，别在简历上写“善于与客户沟通”。

不如写一句话，说清你做了什么、带来了什么结果，例如：“与终端用户进行每周 30 分钟演示；在第二周发现范围变化，并书面重新确认需求简述。”

面试前，准备一个具体的故事，讲某次演示中的反馈让你改变了方向。读职位描述时，留意关于直接与客户合作的段落，那里最值得讲这个故事。

开始做这件事不需要任何人批准。建一个每周重复的 30 分钟会议，邀请将来要用这套系统的人，让他们握鼠标。关于 PDF 的那个问题迟早会来，最好在第二周就听到。

**本周动手试试:**

- 和当前客户约定每周固定的 30 分钟时段，并至少邀请一位每天要用这套系统的人
- 为第一次演示写好 0-3-18-25-30 分钟议程，并从客户数据中挑出 5 个真实案例，让他们亲手跑
- 先为本文的示例演示完成回顾练习，再用同样的三部分格式写第一次真实演示的回顾，一小时内发出

## 信源

- [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html)

- [Scrum Guide | Scrum Guides](https://scrumguides.org/scrum-guide.html)

- [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)

- [A day in the life: How four companies run FDE motions](https://www.insightpartners.com/ideas/a-day-in-the-life-how-four-companies-run-fde-motions/)