先有冲突, 再有语境

回顾过往项目, 我们通常采用这种方式:

提出宏大问题背景
前向和历史回溯
定位切入点
尝试不同切入点, 失败则重复步骤 2
成功则定义为解决方案的进展
展望影响

这种方法对工程师来说很自然, 类似可执行的伪代码. 大多数 STEM 背景的人都会采用, 因为它有效. 唯一的问题是: 它难以快速说服他人相信解决方案的有效性.

但是这个小问题会导致你的方案在充满了竞争者的市场上失去哪怕一星半点的曝光机会. 而这种忽视和随之而来的反馈缺失, 对接下来其他项目的热情和方向选择都可能构成打击.

解决之道可以向编剧学习. 他们面对固定的故事类型 (The Thirty-Six Dramatic Situations), 却要吸引厌倦套路的观众. 基本技巧是: 先展示冲突, 在冲突中凸显人物特点, 在情节进行到一个小高潮以后, 再介绍大背景. 简言之: 先有冲突, 后有语境. 为了验证这一点, 我们看一个经典的例子: 《亮剑》. 在《亮剑》中, 故事是从一场小规模的战斗开始的. 当战斗顺利结束以后, 对李云龙的背景才慢慢展开. 由于观众在战斗的指挥中已经对李云龙的人物特点产生了兴趣, 后续的背景展开才不至于过分无聊, 尽管这些展开是了解其性格的必要路径.

用对直观的洞察构建冲突

将 "先有冲突, 后有语境" 应用到技术展示并不容易. 很多技术方案需要复杂背景才能理解其效果. 对很多技术问题的改进 / 解决方案而言, 抛开其原理不谈, 要理解其效果都需要一个复杂的技术背景. 例如, 向不懂沙盒和容器的人解释 Docker 如何改变软件交付方式就很困难, 因为在普通人眼里, 程序不就是和一把铲子一样吗？一把铲子在厨房能用, 在客厅就不能用了？在这一点上, 编剧面对的任务的难度可能比一个项目的介绍小, 因为理解日常生活总是可以直观进行的.

技术领域构造 "冲突" 需要类似的 "直观性". 这要求我们洞察听众的普遍经验, 发现他们习以为常的事物 (直观), 并将其映射到解决方案上 (对直观的悖逆, 即冲突).
以 Docker 为例, 可以将软件比作电器, 不同国家有不同电压标准. 构建通用软件就需要匹配环境的转换件 (容器). 如果你的解决方案有社会影响, 这种冲突就一定存在, 关键是如何表达出来. 应地, 如果你解决的问题在本质上不会立即产生社会影响 (比如解决一个重要的数学猜想), 那么你应该专注于把这个事情讲清楚, 而不是不负责任地寻找一个比喻.

如何切换到语境

构建冲突后, 切换到语境有两种主要方式, 我叫它们 魔术揭秘 和 Detour 路牌.

魔术揭秘适用于简单的灵感型解决方案, 此时你用来解决这个问题的技巧其实就是一层窗户纸. 因此呈现冲突后直接展示原理即可. 意, 这时候千万不要故意去拖长解释的部分, 解释越简短, 听众的恍然大悟感越强.

Detour 路牌适用于多个技巧组合的复杂方案. 此时, 你需要先警告听众需要绕路, 然后逐步解释. 幸好, 由于你的冲突足够强, 你已经从听众那里买来不少的注意力持续时间. 但你要注意控制绕路时间, 对不同层级背景设定不同颗粒度, 并定期提示当前进度, 毕竟人的耐心是有限的.

我们应该根据项目类型选择合适策略, 实际情况可能需要混合应用.

想法

其实道理大家都懂, 从小我们也听过不少相关的营销故事. 但是往往在一个项目中浸泡太长时间以后, 我们的思维方式已经被塑造成了解决问题而不是讲故事的方式. 同时, 我们接受的训练又使得比起构建, 我们更喜欢 trivialize. 再加上大多数人提出的解决方案少有石破天惊的, 多为改进型方案, 似乎难以从中提取出冲突. 这些因素都导致我们很少选这个简单的”先有冲突, 后有语境“的呈现方式. 可是, 如果你想要要抵达更多的人, 想要改变大家对待一个问题的方式, 对自己的方案进行类似的处理是必不可少的.