你的团队能通过电梯测试吗
高效能程序员的修炼
软件开发者们是真心喜爱编写代码的。但根据我的经验，他们当中很少有人可以解释清楚他们为什么在编写代码。如果你不信，你可以从你的团队里找个人来测试一下：问他在做什么；接着问他为什么要做那个；继续问下去，直到你得到一个可以让你的客户理解的原因。
你在做什么？
我在修复这个数据网格的排序问题。
你为什么要解决这个问题？
因为它在bug清单上。
它为什么在bug清单上？
因为有个测试人员把它作为一个bug报出来了。
为什么它被作为一个bug报出来了？
测试人员认为这个字段应该按照数字顺序而不是字母顺序来排序。
为什么测试人员这么认为？
很显然，如果把“条目2”排在“条目19”的后面，用户在查找的时候就会有麻烦。
如果这段对话在你看来很奇怪，或许你还没有跟足够多的软件开发者一起工作过。你知道你到底要问多少次“为什么”才会得到你的客户真正在意的答案吗——哪怕只挨上一点边？正如“你要舔多少次才能吃完一根tootsie pop棒棒糖”这个问题，答案一定会让你很吃惊！
这是一个巨大的鸿沟！
软件开发者认为他们的工作就是编写代码。其实不然。（这句话是我从Billy Hollis那里“偷”来的。他曾以软件痴迷者为主题做过15分钟的精彩演讲。）他们的工作应该是解决客户的问题。当然，我们偏爱通过软件来解决问题，那的确包含了编写代码。但是，我们要有全局的观点：在交付完整的解决方案的过程中，编写代码只是其中一环。它自身并不是目的。
作为软件开发者，我们花了那么多时间沉浸在没完没了的、支离破碎的细节中，以至于我们太容易掉入为了编码而编码的陷阱中。如果没有明确的焦点或者某种让我们团结在一起的东西，我们就会只见代码这棵树木而不见整个森林。由此可见，拥有一个清晰的项目远景声明（Vision Statement）是极其重要的，每个人都可以把它当做这个项目的试金石。如果你把远景声明搞清楚了，你团队里的每个人都应该能通过由陌生人主持的“电梯测试”——在60秒之内，清晰地解释他们在做什么，以及为什么人们会在意他们正在做的事情。
如果你的团队不能用一种合理的方式向一个外行解释他们的工作，不管你有没有意识到，你都已经处在麻烦之中了。所幸的是，你有个好伙伴——Jim Highsmith可以帮助你。他推荐了一个可以构建项目远景模型的速效公式：
一个项目远景模型可以帮助团队成员通过“电梯测试”——它能赋予团队成员在2分钟之内向别人解释清楚项目的能力。这个模型出自Geoffrey Moore1的一本书：《跨越鸿沟》（《Crossing the Chasm》）。它遵循如下的形式：
为了（目标客户）
他们（关于需求或者机会的说明）
这个（产品名称）是（产品类别）
它的（关键优势、吸引人的购买理由）
不像（主要竞争对手的替代产品）
我们的产品（主要的差异化的特性说明）
创建一个项目远景声明可以帮助团队持续专注于产品的关键方面，哪怕细节一直在快速变化也不怕；否则，团队很容易就会被短期（2～4周）开发迭代中的问题缠住，从而失去对整个项目远景的控制。
我对这个速效公式并不感冒，因为它太过死板。但它是一个不错的开始。玩玩“Mad Libs”2吧，看你能想到些什么——绝对不能没有远景声明，但也不要一个毫无感觉、用杂乱无章的拼盘伪装成的远景声明。然而，我认为Jim关于开发远景声明的第二个建议更能给我们带来希望。
我认为，即使在一个提供信息技术服务的组织里，每个项目都应该被当作是一个创造“产品”的过程。无论这个项目的目标是提升内部的会计系统，还是建立一个全新的电子商务网站，面向产品的思维方式必能带来丰厚的回报。
我发现有一种做法在让整个团队思考产品远景方面很有效果，那就是“设计产品包装盒”。这个练习可以在项目启动阶段很好地激发大家的思维和讨论。整个团队假设产品最终会被装在一个可拆封的盒子里，而他们的任务就是设计这个包装盒的正面和背面。这包括给产品起个名字、一幅图片、正面列出3～4个关键点来“叫卖”这个产品、背面的详细特性说明以及运行要求。
实践证明，想出15～20个产品特性是容易的。难就难在，要选出其中3～4个能促使人们购买这个产品的特性。这个过程中还经常会发生关于“谁是真正的客户”的激烈争论。
“设计产品包装盒”是构建远景声明的一种极好的方法。它基于一个具体的、真实世界里的概念，因此大多数人都可以轻松地开动他们的脑筋。忘掉那些空中馅饼式的远景追求吧，让我们务实一点：我们（假想）的产品包装盒看起来会是什么样的呢？
我们都是消费者。我们对产品包装盒的设计目标都很清楚。如果不拿产品包装盒跟极端的“电梯推介3”相提并论，那它也应该：
- 用最简单可行的方法来解释我们的产品是什么；
- 把潜在客户愿意购买这个产品的原因解释得一清二楚；
- 与货架上所有其他的产品包装盒相比具有独一无二的辨识度。
这里有个例子，让我们来看看命运多舛的Microsoft Bob4的包装盒。你该如何解释为什么客户应该购买Microsoft Bob？甚至你该如何说明这个见鬼的Microsoft Bob到底是个什么东西？
看看那些现有的、你觉得引人注目的产品包装盒是有指导意义的。当然，看看那些你觉得不好的包装盒也可以引以为戒。我们很清楚我们的产品包装盒不应该是什么样子。
从项目开始的第一天就确立一个坚定的远景声明吧！如果你还没有，那就从Jim众多美妙的建议里随便挑选一个，然后照着去做，立即构建出一个远景声明。在缺乏清晰的远景声明时，无法通过“电梯测试”的团队数目将是令人震惊的——他们不能解释他们正在做什么，或者为什么他们的工作是有意义的。不要犯那样的错误。构建一个了不起的远景声明，让你的队友们可以使他们的工作与这个远景相关联。确保你的团队可以通过“电梯测试”。
作者在Twitter上发的一条短讯：
- “当一个编码瘾君子需要修好一样东西的时候，他只会多写上几行代码。” *