Question

对于一个小型的组织，或一个较短期的目标/方向来说，若要求“经营者”来保证两个投影的原始目标同一，并在实施过程中持续稳定，是有可能做到的。这也是一些小公司或小型团队能有良好的组织与合作的根本原因：经营者直接参与规模与细节的平衡。但是，在以下时候：

• 规模持续扩大、技术渐趋复杂，
• 经营者的方向与阶段目标间的距离越来越远，
• 方向由多个方向簇构成，

经营者便将难以通过亲历亲为的形式来实现上述的平衡。这些情况下，经营者通常需要通过组织调整来保证其战略推进的有效性。

“组织”既是一种经营工具，也是一种管理工具。所以无论经营者还是管理者，都有可能使用这一工具带来系统整体或局部的变化。换一个角度，管理者其实也可能参与或直接行使经营职责。因此《大道至简》中所述的：

你可以更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”，董事会通常是解决经营问题的地方；而总经理、执行经理及各个部门经理则是各级的“组织者”，经理办公会则是解决组织问题的地方。

这样来将“组织者”作为角色讨论是并不适当的——“组织”，是管理职能的一种工具而非其全部。所以《大道至简》其实是用一种极端情况来区分出了“经营角色”，使我们在 EHM 中的模型可以被讨论而已。

经营者选择组织工具而非其他，是有一定合理性的。首先，模型４在“方向”轴上的缺失是局部问题而非全局问题，因此通过组织工具来调适不会带来全局性的风险。其次，经营者可能并不期望颠覆正在进行中的阶段性目标，因此选择组织工具而非战术手段（例如裁撤项目）相对会更为温和。

经营者需要在模型４中解决的问题是规模与细节的平衡，以使得工程角色的实施与目标、方向的设定一致。正是这一需求导致架构角色的引入，因为“架构”角色本质责任与这一需求不谋而合。

所谓架构，包含了“范围”与“联接件”两个方面。“架构”一词源于建筑学，中文所说的架构，意指“间架结构”。其中的间、架，在建筑中是对房屋规模的度量用词；结、构则是指建筑的关键位置上的技术构件。

但是，如果我们将架构角色锁定在“某种描述 范围与联接件 的文书”这样的产出上，无异于将架构角色当成技术工人：使用某些工具，生产某种产品。我在这里讨论 “架构”一词的本义，是强调应从本质特性上来看清架构角色所关注的方面。而这些方面，又与在现今软件工程中经营角色对软件系统的关注，例如问题的识别与控制等等存在一致性。正是因为这种一致性，由架构角色来介入模型４中的“方向”这个轴线所指代的领域，才会成为一种组织选择的必然，如图附 3-8 所示。

图附 3-8　模型 5：组织视角下的工程视图

在从 EHM 模型推进到图附 3-8 所示模型的过程中，我们让经营角色介入进来，又渐渐地将这个角色分离出去，代之以“系统架构”这样的领域与角色。以下我们把工程视图模型简称为 VEO 模型（View of Engineering Organization）。在开始后续的讨论之前，我们需要再次强调引入架构角色的本意与背景：

1. 目标 。架构角色围绕一个阶段目标，以及该目标在规模与细节上的投影工作。这是能将架构角色与其他两个角色纳入同一个系统（具体的工程实施）来讨论的前提。
2. 方向 。架构角色在方向领域上与经营者（或更宽泛地称为架构需求的提出者）保持一致，了解阶段目标与方向之间的关系，并通过架构产出、指导、推进和实施等一系列工作来把握这种关系。
3. 范围与联接件 。架构的主要产出是对范围进行的约束，对目标的关键构件之间的联接件的设定。并且还需要在实施过程中调适架构最初的约束与设定，平衡由时间、信息等因素带来的目标与方向之间的衍变。

1. 思维方式 并不是 思维对象 ，前者是基于后者而渐渐形成的思想方法； 思维对象 也并不是 关注对象 ，（在同一个领域下）前者是后者所带来的、在意识中的映像或抽象。 ↩
2. 里程碑（Milestone）是“靠改进特性（Feature）与固定资源（Resource）来激发创造力”这一微软的软件工程观念中的基本概念。 ↩
3. 这并不是说项目经理要“管辖或替代”产品经理的职责，而是说在“范围”这个领域中事实上（在现实中）是并存着这些角色的。“项目管理”作为一个现实职务时，它管理的具体内容是与组织的授权有关的，这在后面的内容中将会讨论到（例如，“【附三】2.5 调适：变化中的 VEO 模型”）。 ↩
4. 对于“方向”这个轴线上的“目标”来说，项目所管理与实现的，是阶段目标下的“阶段性产品”。同样，以纯粹的“产品视角”来说，“方向”轴线上的目标/产品系列，即是“产品线”。更进一步，经营角色同时关注的是多个产品线上的方向问题，于是一系列产品线所构成的某一个方向上的“方向簇”，通常可以作为一个“战略”的战术实施。在本书中，并不对模型４中所隐含的“产品视角”作深入讨论。 ↩