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