您的 Demo Slot 是领导机会

Source: Dev.to

传统演示的痛点

每两个月，我站在利益相关者面前，展示团队交付的内容。
多年来，我和大家一样：逐一讲解功能。

“我们在文档里添加了错误页。”
勾选框。勾选框。下一页。

没有人会记住这些演示。大多数演示遵循同样的脚本：

• “本次冲刺我们实现了功能 X。它很高效。”

演示变成了工作已完成的证明——而不是构建共享理解的场所。没有人会明确要求这种框架；你只是被动接受。这就是“专业”演示的样子。

另一种做法

上周五，我为组件库的新功能做了一个 PI 演示。过去的我会说：

“我们添加了一页完整的错误文档，列出了所有错误码及解释。”

这的确准确，但我尝试了别的方式。我讲了一个故事，并给用户起了个名字。

故事

认识一下 Bob。

如果没有我们，Bob 正在面对数周的工作：身份提供者的怪癖、权限矩阵、未记录的边缘案例。使用组件后，他复制了快速入门示例。五分钟后它运行了，却又崩溃了。他按照文档的建议绑定错误回调，收到了这条信息。Bob 发送了邮件。随后他发现了我们的错误参考页，意识到一件重要的事：每一种失败模式都有文档记录。他不再猜测，能够继续构建。

相同的功能，不同的框架。一个是交付物，另一个是故事。

为什么故事有效

功能列表教会的是：

“进展是交付东西。”

而故事教会的是：

“进展是改变某人的处境。”

这些教训不会以提问的形式出现在会议中。它们会在有人提到 “Bob” 时出现——大家都明白这意味着什么。给角色起名是一种压缩机制。在“安全”意味着状态报告和检查清单的环境里，这种做法模型了别的东西：对齐来源于共情，而不是精准的幻灯片。

我并不期待掌声。我在乎的信号是延迟且间接的。几周或几个月后，我会留意：

• “Bob 在这一步卡住了。”

如果 “Bob” 再次出现在工单、会议或待办事项中，我就知道这个框架起作用了。如果 Bob 再也没有出现——这也是数据。

收获

• 实验仍在进行中；尚未有结果。
• 没有人要求我这么做；这个时段是我的，我于是用了不同的方式。
• 我在演示前十分钟才想出这个故事。它出现了笨拙的措辞、粗糙的节奏，我甚至直到后面才给角色起名。
• 只要尝试一次，即使不完美，也已经比“考虑换种方式”要好得多，而后者是大多数想法悄然消亡的地方。

这与我最近写的一篇文章有关：你往往拥有比想象中更多的主动权——但前提是你真的去行动。

下一步

• 在下一个演示中，挑选 一个 功能。
• 不要描述它的功能。
• 给它起个名字。
• 然后观察会有什么反馈。

---

本文所述的观点和实验均为本人观点，不代表我的雇主。