《软件方法》第2章 愿景

软件方法（草稿）第2章 愿景

<<上一章 下一章>>

愿景

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

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

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

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

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

愿景的定义

愿景回答这样一个问题：

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

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

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

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

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

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

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

可度量的目标

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

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

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

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

图2-8 太大的愿景

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

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

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

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

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