软件方法－－愿景

愿景

谁挽起弓箭，射天空的火舌；谁偷仙丹飞天，月宫安守青天

《天问》；词：潘伟源，曲：达明一派，唱：达明一派；1990

图2-1 系统映射到老大的大脑里是个什么东西/p>

上面愿景的定义中有三个关键词：老大、系统、目的。

老大

老大也就是平时我们所说的“客户”，是最有“地位”的涉众，权衡系统的各种需求时，他的意见是最重要的。

为什么要说“老大”，不直接说“客户”呢为“客户”指的是一个组织或人群，不是具体的某个人。例如，客户“NB市国土资源局”不是一个人，里面有局长/副局长、办公室主任/副主任、地籍管理处处长/副处长、监察支队长/副支队长……许许多多岗位，“这条需求哪里来的“客户那里来的”，没准是从客户的门房老大爷那里来的呢，能放在重要的位置来考虑吗以，我们需要具体到老大――客户中针对此系统最有发言权的人，例如：NB市国土资源局局长。

现在的许多系统，特别是互联 站，面对的客户组织是一个人群。例如一个汽车 站，面对的客户是“车友”，“车友”是一个人群，不是一个具体的人。车友中有SH市的韩少，有NB市国土资源局办公室主任，也有XA音乐学院的学生；同理，NB市国土资源局的人员里中有车友，也有驴友、玉米…。这时，也要学会寻找车友中的“老大”――最像“车友”的车友。

学会从老大（客户）的角度看问题，对开发人员来说也不简单。开发人员很多时候习惯于从自己的视角看问题，而不是老大的视角。

有时我问开发人员：你最近做什么项目的开发人员回答：我在做一个Java项目。对吗的！这个项目对于这位开发人员来说确实就是一个“Java项目”，因为他不关心项目的核心领域是医院、物流、保险还是地理，他只关心这个项目能不能提升他的Java技能，对以后升职加薪有帮助，所以他把这个项目叫做“Java项目”十分正确。并不只是刚入职的开发人员会这样回答，有一次，我问一位有将近十年开发工作经验的架构师最近做什么项目，架构师回答：在做一个数据仓库项目。继续聊下去，我才知道其实他做的是某通信公司的客户关系管理系统，里面用到了数据仓库，而数据仓库的知识恰好是他比较缺乏而且感兴趣学习的，所以他干脆把这个项目称为“数据仓库项目”了！

如果我们的系统是一个有特定甲方的项目，老大是比较好找的，就是甲方的某一个人，例如NB市国土资源局局长。如果是一个产品，老大就相对难找一点，因为产品不是针对某个特定组织开发的。这个时候，也要学会具体化，把产品当成项目来做，先定位到具体的组织（人群），再从组织中找到老大。

寻找项目的老大：要点和典型错误

要点：老大是买方。

典型错误：老大就是我们开发公司老总（或者研发总监、产品经理…）。

说得倒是没错，因为老总让干啥我们就干啥，甚至老总要是不乐意接这个项目，就不用干了。特别是做产品的公司，开发人员会觉得没有具体的客户，或者全世界都是客户，公司走什么方向，做什么产品都是老总决定的，所以老总就是老大。可惜的是，这个答案来得太容易了，不需要思考，而且放之四海皆准。这样的答案有价值吗/p>

针对什么样的“系统”，开发公司老总才是老大呢是他成为买方的时候。例如，购买一款开发工具，招聘一名开发人员，选择一次开发技术培训服务……。

要点：系统改善哪个组织的流程大指的是那个组织的老大。

典型错误：老大是××局信息中心主任李××。

很多时候，开发团队并不能常见到真正的老大，常见到的最高干部可能是对方派来的一个IT方面的主管（头衔可能是信息中心主任之类）。没准这个主管上大学时也是学计算机的，大家一见面，大谈特谈“架构、SOA、云计算…”，业务方面却难得深入讨论。

这个IT主管不是老大，因为系统要改进的不是客户IT部的流程，而是客户业务部门的流程。所以，老大应该是客户业务部门主管或客户公司老总，视系统改进波及的范围而定。当然，如果改造的就是客户IT部的流程，那就另当别论了。

研发部要招一名C#程序员（也就是租用一个人肉编程系统），人力资源部负责出面招人，但人力资源部主管不是老大，因为招到的C#程序员改进的不是人力资源部的流程，而是研发部的流程，所以老大是研发部主管。

要点：系统好坏的度量指标藏在他的大脑里吗/strong>

典型错误：老大是某位大领导（可能是集团董事长，也可能是省长，甚至是总理）。

大领导是大，问题是大领导脑子里关心的是一个省、一个国家的改进指标，不关心具体某个系统的改进指标。大领导的某些期望，可能适用于成千上万个系统。这个错误和“老大是开发公司老总”类似，都是放之四海皆准，没有体现出系统的味道。

“味道”这个词后面的章节中还会不断提到。每一个系统之所以能卖，是因为它有自己存在的独特价值，独特“味道”，建模就是要把这个味道剖析出来――恰如其分的抽象。

搞错老大怎么办关系的，把老二老三当老大，总比没想过这个问题要好得多，也许我们的竞争对手根本没想过这个问题，或者把老八当成了老大。

定位具体的组织（人群）

一个老头找到PS可乐公司，告诉他们的主管说，“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州。现在我老了，我对你们的可乐下一个版本提出如下需求：第一，我有胃病，下一个版本不要有这么多气；第二，我有糖尿病，下一个版本里面不要有糖。PS可乐公司的主管很感动，哇，这么棒的顾客，把需求提得那么具体，省去我们调研需求的好多时间，好，下个版本就这么办！

会有这样的场景吗会的。老头老太太可以买可乐喝，甚至可以买给自己的狗喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者他们的狗提的要求，PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标客户群是年轻人。可惜，很多时候我问开发人员，“可乐卖给谁得到的回答大多是“卖给消费者”，“卖给想喝可乐的人”――对做出好卖的可乐没有帮助的、正确而无用的废话。

开发人员有时会觉得全世界人民都可以用我的产品，巴不得从每个组织、每个人、每只猫、每条狗、每块石头，每颗植物，每个僵尸都榨出金币来。然而事实是：竞争使得产品分类越来越细，不再有针对所有人的产品了。

在原始人眼里，喝水是很简单的事情，也没多少选择，靠着河就喝河水，靠着泉就喝泉水。随着 会的发展，喝水变得越来越复杂，水的种类不断分化，“水”的含义也在变化。“我进超市去买几瓶水带在路上喝”，你猜会买什么/p>

图2-3 不断分化的人

软件的分化也是如此，看起来功能类似的不同软件产品，面对的目标客户群是不一样的。请大家尝试做下面的题目：

  阅读到此处请完成测试题：http://www.umlchina.com/book/softmethflash/Chap2_2.swf

并不是说高中生不能用旺旺，没人拦着他，问题是高中生这个人群的意见对旺旺的需求影响力有多大呢/p>

要做一个电子病历系统卖给医院，说“客户是医院”还不够，医院也一样越来越细分，有大型三甲医院，也有二级医院、中心卫生院甚至 区卫生服务中心…，还有根据性别细分的男子医院、女子医院，根据人体器官细分的口腔医院、肝病医院、肛肠医院…，还不要忘了国外的医院，美国的JHH、Mayo、乌干达的@％&，孟加拉的&￥#……。系统真的能卖给所有的这些医院吗通过比较慢慢缩小范围，逼近具体的“客户”――“协和医院”还是“大兴中医院”更像你的系统所服务的医院什么/p>

可度量的目标

有了老大，接下来要写出老大希望这个系统给组织带来改进的目标，而且是可以度量的目标，象下面这样：

图2-4 愿景是改善组织的指标，不是做某事

图2-6 错把系统功能当作愿景

图2-6描述的都是“做什么”，已经是系统的功能需求。愿景不是问系统有什么功能，而是回答买了这个系统，对组织有什么好处。如果回答不了这个问题，谁能相信开发人员拍脑袋得出的“本系统有××几大功能”有多少价值呢恰当的愿景描述如下图：

图2-8 太大的愿景

图2-8的目标不能说不对，但是太大了，放之四海皆准，适用于医院采购的各种系统，失去了“移动病区护士系统”的味道。更贴切的愿景描述如下：

图2-9 一个系统，多种涉众的利益

戏如何演，不是由演员（Actor）决定的，而是由台下各种观众的口味角逐而定。观众按照重要性排排坐，先要照顾第一排观众的口味，然后再照顾第二排观众的口味….. 同理，涉众利益之间的冲突和平衡，决定了系统的需求。演员下台以后可以当观众，甚至有的演员还坐前排（象范冰冰），不过大多数演员（死跑龙套的）是坐后排的。

图2-11用户＝懒惰＝无脑

可以积累的财富

需求是不断变化的，新系统肯定在功能或性能上和旧系统有所不同，否则还做什么新系统是，背后的涉众利益要稳定得多。我们来看银行领域中的涉众利益：

储户――希望方便；担心权益受损

银行――希望安全；希望节约运营成本

这些涉众利益，适用于清朝的钱庄柜台，适用于取款机，也适用于 上银行。现在手机银行又开始热门，背后的涉众利益变了吗/p>

图2-13 请思考图中的涉众利益

 阅读到此处请完成测试题：http://www.umlchina.com/book/softmethflash/Chap2_3.swf

工具操作

工具操作请看以下视频：

 http://www.umlchina.com/book/softmethflash/Demo2_1.swf

【1】http://money.cnn.com/magazines/fortune/fortune_archive/1999/11/22/269067/index.htm

【2】Managing software requirements: a unified approach , Dean Leffingwell, Don Widrig