2.4 明确一个可以共享的愿景
当你让这些干系人参与时，澄清愿景显得非常必要。谢天谢地，由于你使这些干系人紧密地合作，你就不会面对一团糟。你应该在早期就以最小的代价来强调愿景。如果产品负责人和干系人们讨论一个长远目标或者软件产品的意图时，就应该会得到一个大家都认可的产品愿景。
比较完美的情况是，软件产品的名称将清楚明确地概括出产品的愿景。名字是人们第一次接触到的关于软件产品的介绍。名字将被重复使用，就会在人们脑海里形成深刻的印象。
不幸的是，事实远不是这样。名字通常由市场部或项目管理办公室提供，他们只是随意地定义，丝毫不会考虑软件产品的愿景。他们常常定义一个从管理的角度很容易识别的项目代号。
因为是从管理的角度考虑的，你很难忽略这个正式的名字。然而，没有任何事情可以阻止你取一个非正式的名字：一个关于愿景的一句话的描述。这就是我的建议。
用几个单词描述软件产品需要实现的愿景。这个简短的、一行字的概况应该给所有人提供了关于一个软件产品最终必须是什么样子的共同的理解。一个清楚的愿景为软件的整个开发生命周期提供了决策和承担责任的依据。它深刻地影响着干系人和团队对开发软件产品的贡献。因为每个成员都朝着一个方向努力，所有团队士气高涨。这是一个改善结果的稳定因素。它影响着团队将要生产什么，以及在生产过程中人们的行为方式。
马马虎虎地随意取名是造成模棱两可的结果的危险来源。同样，缺乏对整个愿景的唯一描述也会造成模糊不清的症状。不要犹豫，请将所有昵称、工作名称和项目描述整合起来。
为了创建一个明确的一行字摘要，需要遵循高斯和温伯格[1]推广的启发式命名规范。下面这个简明扼要的三步流程就是从他们的书里引用过来的：
“首先提议一个名字，接下来提供这个名字不十分恰当的三个原因，然后提议用另一个名字来解决这些问题。”
重复这三个步骤，直到找到一个有用的描述。记住并不存在一个完美的一行字描述，因此不要因为重复不休而停滞不前。
下面我们来演示一下这个过程。假设纽约大都会交通运输管理局想要为在电脑上使用自助服务的乘客通过智能卡在“自助资讯服务站”购买车票的项目定义一个愿景。最可能浮现在脑海里的描述就是“交通卡项目”。
下面是关于这个选择的三种误解：
1）这个票务软件没有指名交通管理局。
2）“项目”暗示软件的实用性随着项目的结束而结束。
3）在这个名字中没有任何关于自助资讯服务站的暗示。（将会有一个自助资讯服务站。）软件的最大收益是不再需要销售员来帮助完成交易。
当审视完这些缺点后，干系人再次提出名字选项“NYC大都会交通管理局自助票务资讯服务站”，这个名字有下面三种缺陷：
1）应该从名字中把“NYC”去掉，因为每个人都知道MTA（Metropolitan Transportation Authority）是纽约市的交通管理局。
2）这个名字没有关于车票会上传到智能卡的信息。
3）这个名字没有任何关于服务站也可以用来读取智能卡上还剩多少张车票的暗示。
通过这两轮的讨论，团队决定继续第三轮的一行字描述：“MTA自助服务智能卡资讯站。”团队本可以继续进一步执行关键的命名流程的，但他们觉得应该停下来了，因为每个人都对这个结果感觉很舒服。启发式命名的目标不仅是为了得到一个描述，也是为了保证团队中的每个人对真正的问题有更好的理解。
找出一个可以共享的愿景是一个由产品负责人引导的活动。主要形式是干系人们面对面的会议。结果是用短短的一行字概括出软件产品应该是什么和它能做什么。它是软件开发的一个坚实基础，一经产生就会在一整年里不应该有变更。很显然，这是一个需要一年一度重复的任务（或者更早期，在那些较大的、要求彻底优化产品的需求提出来时）。