Question

我们回到问题本身：决策域和产品域为什么需要（它们特有的）模型？

决策者 需要的是业务模型。所谓“业务”，其核心包括它的产品构成与收益形式。作为面向商业运作的决策者来说，成本的开销与控制方式以及收益的获得与分配方式是整个业务的关键。 工程管理者 关注的则是一个产品或一系列产品的生存周期。这表现为项目过程，以及与项目过程对应的产品模型。业务建模与产品建模的区别在于：前者并不描述产品的当前特性以及延展特性，而后者正好关注这些内容。

需要特别提及的是，工程管理者通常关注一个产品/项目过程的实施进展、阶段规划、品质保障、成本控制等内容，而对产品之于产品线的中长期特性关注得很少。但事实上工程管理者需要产品模型的真正原因是，他需要一个蓝图，以及这个蓝图在长期演化上“可能性”。对于一个具体的工程管理者（例如某个项目经理）来说，产品的下一个版本或下一个系列可能根本与他无关。不过即使在这种情况下，他也需要在某些决策中用到上述的“可能性”，将其作为趋势判断的依据。

这些问题与城市建筑是类似的。业务模型相当于城市规划：东边要建行政区，西边建成科技园区，市中心以旅游和购物中心为主，而南边则进一步做旧城改造规划等 8 。产品模型，则相当于某些在建住宅小区的“XX 工程几期规划图”。这个图用在工程现场，每个施工者就知道他们在建造一个什么样的东西；用在售楼广告中，购买者就知道他们交钱买单的楼盘特点；用在小区周边规划中，大家就知道哪个地方该开个超市或为小区幼儿园留一个绿色通道；如此等等。

但是我们会发现——事实上我们做如上讨论与比拟的关键价值也在于此——尽管决策域与产品域确实需要基于模型来开展工作，但对于工程现场的施工者来说，这两类模型的意义并不大。例如你不能指望施工者因为楼房有商用与住宅之别就感到开心或沮丧，也不会因为大楼模型做得比别的工程现场精美，就能让施工进程更快更好 9 。

因此，在大多数时候，业务模型与产品模型事实上是无助于实施与评估实施的细节的。这也意味着，在软件开发/工程中，这些模型所采用的语言（文字、图、幻灯片或实物样品）只需要与它们主要的沟通环境相匹配即可，不必非要得到用户、工程师或者某个具体团队的认可 10 。

1. 正因为如此，在“第 12 章 应用开发技术”一开始就讲到：它适于解决时间因素所致的复杂性。 ↩
2. 引自“MSF Process Model v. 3.1”, Microsoft Solutions Framework White Paper。 ↩
3. 这种对应关系并非是边界分明的，事实上 IDE 中的同一个功能可能应对的是不同模型中的问题或问题集。 ↩
4. 导致这一局面的部分的、且并非关键的原因在于：一方面，开发工具中使用 Project、ProjectGroup 等关键字来应对项目规模的扩大，而这一问题延伸到工程模型后所得到的抽象概念却是 Product、Version 以及 ProductLine 等；另一方面，工程工具与开发工具的提供商试图将这些合而为一，但形式上的统一未能弥补概念与领域上差异。 ↩
5. 这进一步导致了团队无法摆脱既有的公司组织与管理结构，于是实施敏捷变得在组织层面上既说不通也行不通。 ↩
6. 例如，正如此前所讨论的，敏捷中的原型事实上也是敏捷工程师与用户之间沟通的模型。 ↩
7. 你可以想象成开发过程中的“定义数据结构和写函数声明”，以及形式化的流程图与部分逻辑代码。 ↩
8. 在地图上描绘类似这样的一个规划布局，然后试着将一个人工作生活的行经路线画出来，标上每天、每周、每月重复路线的次数作为权值，于是你就可以论证“为什么我们所在城市的交通这样拥堵”了。 ↩
9. 这里特别地忽略了一些细节，例如某种类型的楼（或软件开发产品）更难建造，或某个地区的楼（或业务方向）更受领导重视等。这些的确影响到具体团队、人员的选择，但它们并非这里讨论的“模型作为沟通工具的价值”。 ↩
10. 一个设计或架构模型“要让所有人都理解”是相当荒谬的，而统一建模语言——请注意，我这里并不是指字面上的 UML，而是指“统一（某些东西）”这种思想——便是这类荒谬想法的具体实践。 ↩