软件方法－－愿景

 

 

愿景

 

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

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

 

 

 

 

最不可缺的文档

缺乏清晰、共享的愿景往往是项目失败的主要原因。

系统的愿景和“电梯演讲”很类似――如果在电梯内遇到了风险投资人，您如何用简短的几句话描述您的项目来吸引投资？

愿景的英文是Vision，原本是一个商业概念。我们的生活就是被许多伟大的愿景改变的。1999年11月的《财富》杂志题为“20世纪企业家”【1】的文章，评选出了最能代表20世纪企业家精神的企业家――Henry Ford，他的愿景是：让每个家庭都拥有一辆汽车！排名第二的是Bill Gates，他的愿景也非常相似：让每个桌面都有一台计算机！许多著名的企业都有鲜明的愿景：

 

 

 

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

 

 

 

 

对于软件系统来说，愿景也是至关重要的。Rational 统一过程（RUP）的主要负责人Philippe Kruchten曾经说过：

If, instead of a fully robust process, I were permitted to developonly one document, model, or other artifact in support of a software project, ashort, well-crafted Vision document would be my choice.【2】

如果不允许完整厚重的过程，仅允许开发一份文档、模型或其他工件来支撑软件项目，我会选择一份简短精致的愿景文档。

愿景的定义

愿景回答这样一个问题：

在老大看来，购买（开发）这个系统的目的是什么？

这么简单的问题，回答起来未必容易。开发人员介绍项目时，洋洋洒洒说一大堆系统有哪些功能，采用的技术平台、架构等等，但被问到“为什么要做这个系统”时，可能就会瞠目结舌。如果开发人员的思维停留在“可以工作的软件”而不是追求“可以卖的软件”，他甚至会纳闷为什么要写愿景这个东西！

“知道这两个（和愿景相关度最大的）功能实现难度太大做不下去，在我看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他功能可以做。”――某公司技术总监

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

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

老大

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

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

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

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

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

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

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

要点：老大是买方。

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

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

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

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

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

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

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

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

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

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

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

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

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

定位具体的组织（人群）

 

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

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

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

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

图2-2 超市里摆的各种“水”

动物的种类越来越少，人的种类越来越多，买水的“人”也在分化：

图2-3 不断分化的人

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

 

 

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

 

 

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

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

可度量的目标

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

象愿景

不象愿景

减少采集数据所花费的时间

提高制作动画的速度

缩短订单的处理周期

建立一个CRM系统

提供在线订机票功能

能够对贷款申请作风险评估

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

图2-5 愿景 vs. 功能

图2-5中，“提高防汛决策准确度”是愿景，而不是功能。系统没有提供这样一项功能，局长输入一个准确度数值，确认，防汛决策准确度刷的一下就提高了。要达到这个目标，需要各个岗位分别使用“查看云图”、“上报水库运行情况”等功能。

错例：把系统的功能当作愿景。

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

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

图2-7 更恰当的愿景描述

错例：把组织的目标当作系统的目标。

图2-8 太大的愿景

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

图2-8 更恰当的愿景描述

揣摩目标度量

老大心底里是有度量指标的，否则，系统摆在他面前的时候，他拿什么来判断系统好不好？不过，要得到度量指标不容易。

正如前文所说，老大不是开发人员经常能接触得到的。大多数时候，代表“客户”的是“甲方信息中心主任”这样的人，而实际上这个人无法代表老大，更无法代表形形色色的涉众，只能代表他自己。

即使能接触到老大，老大未必说得出来。后文在“需求启发和验证”一章中还会说到这一点――涉众会做但不会定义。就算老大说出来了，也不一定会说得很直白。其实这也正常，老大的意思那么好懂，那还有老大的样子吗？

开发人员需要通过各种手段揣摩老大心底里的度量指标，可以通过老大的讲话、报告，通过客户派来的接口人，也可以问本方老大――开发人员接触不到对方老大，我们老总接触起来总好些吧？揣摩的技能每个人都有，我们每天都在揣摩上司、同事、配偶的意思，只不过现在要把它用在软件开发上。设想一下，如果不是开发软件，而是招待老大到澳门泰国的娱乐场所玩，老大说“帮我找个漂亮的技师”，你不也得从老大的角度揣摩“漂亮”的度量指标吗？

有时开发人员说“哪有什么度量指标啊，我们做的那个系统就是个政绩工程，客户领导去××省考察回来，说××省有一套啥啥系统，我们也要有！”。其实，“政绩”二字本身就隐含着数字的概念，政绩工程也一样有度量指标。开发人员仍然需要好好去揣摩：老大关心什么样的政绩指标？

老大可能会有多个目标，而且目标之间还有可能会产生冲突。例如，一个给地产经纪计算佣金的系统，老大要求在尽可能短的时间内计算出佣金，同时计算要准确，每一步的操作过程事后可以追究。这几个目标是有冲突的，要“准确”，要“每一步可以追究”，“快”就要受到影响。这时需要对目标排序，揣摩出老大首要关心的目标――准确，即使规则不断变化，也不能出任何错误，因为计算不准确导致分配不公，会影响到经纪的工作积极性。揣摩到这一点，就会意识到结果和当初的设想大为不同――这个系统不需要精美的图形界面，甚至用脚本都可以。

有时开发人员会说，“哎呀，你说得容易，哪里有那么好揣摩的？”和前面说到的“搞错老大怎么办”一样的道理，不可能揣摩到100%，但是就算只揣摩到30%也是好的，很可能竞争对手做类似项目时根本没有揣摩或者只揣摩到10%，相比于竞争对手，我们的风险就小了很多，也就有了竞争优势。

涉众利益

愿景是老大针对系统的目标，那其他人的目标难道不重要吗？其他人的目标也要关注的，我们把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益。

涉众（Stakeholder）指受到系统影响的各种人。拿拍电影做类比，涉众就像电影观众，需求就像电影剧本。剧本只有一份，观众却是多种多样，不同观众的欣赏角度和口味不同。正如鲁迅所说：一部红楼梦，经学家看见易，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事。开发一个系统也是如此：

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

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

图2-10 演员（Actor）在台上表演Use Case，观众（涉众，Stakeholder）在台下看

用例技术使用“执行者”（Actor）和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的界限，我认为在开发中可以把“用户”废弃。

用户指可能和系统有接口的人肉系统，之所以说“可能”，是因为系统的需求没有推导出来，无法真正判断用户是哪些。例如做一个银行营业系统，认为营业员是用户，找营业员去问需求。这样先入为主的想法已经束缚住了我们的改进思维――很可能老大更希望废掉营业员这个人肉系统，毕竟计算机系统不只是简单地把纸上的东西往电脑里搬。

即使最终保留了营业员这个人肉系统作为“用户”，从“用户”身上所获得需求素材的价值也不可高估。越是用户（即亲自上阵和系统打交道的涉众），往往在涉众排行榜上排位越靠后。整天操作电脑搞得手僵脖子硬的“用户”，有几个是职位高的呢？真正位高权重的涉众，虽然偶尔也会上台表演当Actor，但更多时候是坐在台下看戏。开发人员如果过多地关注“用户”，花在重要的前排涉众身上的时间往往就不够了。

找用户问需求，就像找演员问剧本。要得到好结果，除非这个演员自编自导自演了。互联网网站的“用户”往往就是它的前排涉众，所以象“用户故事”这样的技术在开发互联网网站时还能应付。如果开发涉众较多、利益冲突微妙的系统，应该采用用例这样更严谨的技术。

没有“用户”的系统，也一样有涉众。现在，越来越多的系统“用户”不是人，或者说，和它接口的系统不是人肉系统，而是另外一个电脑系统。两个电脑系统交互的需求，难道就不用做了，或者可以随便做？非也。那只是相当于上台表演的不是人，是功夫熊猫，是变形金刚，是喜羊羊灰太狼，台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演，涉众在台下看表演”的概念，对非人系统的需求捕获很有帮助。

“用户”这个词还是懒惰的一种表现，这个功能给谁用？给用户用。这样的回答，和“东西卖给消费者”一样，是正确而无用的废话。所以在做需求时，尽量不要使用用户这个词，而是使用具体的执行者名称：储户、顾客、科长、验质员、检斤员…。当然，设计时尽可以抽象出“用户”这样的超类。

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

可以积累的财富

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

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

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

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

图2-12 系统的具体形态变了，涉众利益不变

涉众利益的介绍先说到这里，在后面的“书写用例文档”、“需求启发”等章节中，还会详细谈到涉众利益的细节问题。

很多团队是“一穷二白”的，也许他们也写有需求规格说明书，但上面说的不是需求。也许有设计文档或图形，但并不能对编码形成指导。对于从零开始的团队，第一个引进的概念是“愿景”，团队需要对“为什么要开发这个系统”达成共识。另一个需要建立的概念是“涉众”，什么人关心我在写的这些代码？这个时候即使还是没有正式的需求工程，没有改进分析设计，在开发过程中，把这两个概念记在心中，愿景和涉众的概念也能起到潜移默化的作用，我为什么要画这个图，为什么我要编写这个窗体？

以下是新浪微博的注册界面，请思考，为什么是这样的界面，其中涉及到了哪些涉众的什么利益？

图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 , DeanLeffingwell, Don Widrig