Question

有三种组织模型能够描述“有着某种领导风格”的组织，分别是 Owner、Center 与 Core。在这三种模型中，领导者将自己作为一个点，代表、凝聚了这个组织，或作为组织的一个缩影。但这样的组织模型只表明“领导力”的一个结果，即“如果某些角色是有领导力的”，则他们的推进结果可能使组织演变为这样的一种形态。我们不能反过来说，一个结果（如形态）就是领导力本身。

VEO 模型在角色职能出现了架构、管理与技术三个方向，从团队/项目组织职能上来说，这三个方向也就存在三个（可能的）领导角色，即架构师、项目经理、技术经理。如 VEO 模型所阐明的事实一样，图附 3-19 表明这三类领导角色在组织上是趋于衡态的 6 （领导力下的衡态，以下简称 LoE，即 Leadership of Equilibrium）。

图附 3-19　（与领域相关的）领导力下的衡态

如何让 LoE 模型趋向于一个“有领导力”的组织模型，是这一系统中的各角色间存在冲突的主要原因——换个简单的说法，就是大家都想当领导。在另一方面，这些角色将受到更外层的角色的影响，外层角色级别可能更高，或更为具体（如开发团队、产品）或宏观（如更高级别架构决策者、产品线），如图附 3-20 所示。

图附 3-20　外层角色的影响

许多情况下，这些外部力量左右或影响了具体角色的实施（并不一定是决策）。这个问题随着领导责权属性的不断增加，例如可能出现的跨角色授权或领导小团体的形成，将不断扩大到整个的、全局的系统，如图附 3-21 所示。

图附 3-21　更多的组织角色构成的阶层

为了解决这一问题——或为了利用这一形势带来的利益，我们通常在某一方面或某一方向上合并角色，如图附 3-22 所示。

图附 3-22　通过合并来打破阶层（示例 1）：决策者的思想

这样的组织形态一方面可能因为在相应方向上的领导缺位导致，另一方面，也是因为组织中既已形成阶层结构——并由此带来权责分配，因此“自然地转变为（而未必适宜）”由这些角色通过他们的领导力来影响项目。甚至有些时候，你看到 CEO 都被合并到这个角色中来。由于这种合并，项目常常变得非常难于控制，因为角色对项目的影响会因为“管理层次”，而非“项目自身需求”而变化。

然而这一趋势可能会进一步激化。因为，在各个方向的合并在一定程度上是有益处的：首先，它满足了某些组织角色的权力诉求；其次，它确实在很大程度上减少了沟通成本；其三，它更利于构建“那些还不存在的”团队或组织结点；其四，它的失误成本更小，例如对于该组织来说，失败时责任划分更简单，且可以更快捷地改变；最后，它事实上也提供了领导角色短期实践的空间。然而更大范围的合并，通常责权更为集中，而角色与其职能也就更难区别，而且一些时候也不可避免地出现“为了形成对立”而结成的联盟。

图附 3-23 所示的模型事实上形成了技术与产品（包括其他一些非技术角色）的对立，在这样的模型下，技术是否“生产”符合需求的产品，是否在做符合公司利益的事等，这些问题都是由被合并后团队的决策者（或事实领导者）来判断的——但这是否可行，是组织权力上的具体考量。图附 3-24 所示的模型貌似风险更大，例如它看起来在做“CEO、CTO 与产品线都不知道的某种东西”，但事实上它更经常地出现在创新团队中。

图附 3-23　通过合并来打破阶层（示例 2）：实现者的思想

图附 3-24　通过合并来打破阶层（示例 3）：尝试者的思想

这也意味着如果“组织形态的合并”在规模与责权上是可控的，那么它既可能产生新的产品/项目，也可能产生新的组织结点。但如果反之，在这两方面失控——例如在不正确的角色上做出了不正确的决定，那么它的影响面也就更大。然而事实上，我们在项目中的思考常常并不那么清醒。例如，会出现某种空中楼阁式的、忽略了开发技术实施可能达到的能力的合并，如图附 3-25 所示。

图附 3-25　通过合并来打破阶层（示例 4）：规划者的思想

基于 LoE 模型，事实上我们是在讨论“组织的形态”对于 VEO 模型可能发生的影响。这些影响既有正面的，例如权力的扩大、沟通的简化，以及领导力的形成等，也可能有负面的，例如联盟与对立的形成 7 。回到最根本的问题点上来说，真正形成对立的，是领导力与组织力在 VEO 中的价值。从这个根本出发点来看，我们会意识到：组织力与领导力在本质上是存在一种“堵与疏”的关系 8 ，如图附 3-26 所示。其中：

1. 组织的基本形态是各行其事，因而组织力的根本在于构成确定组织结点的权责，并进而明确系统规模与代价；
2. 领导角色的基本职能定位在于形成系统的合力，因而领导力的根本在于消除内耗。

图附 3-26　组织力与领导力对组织形态的不同影响

对于 VEO 模型来说，驱动其变化并趋向良性的是领导力，而其依赖的事实基础却是受组织力影响的 LoE。这是两个矛盾又统一的结构，也是大多数结构的内在形式。对这样的结构加以调适，其关键在于使用者的思想、方法与眼光。

1. 在这里以及后文的讨论中，我是特指 Windows 中的 notepad.exe 这个记事本工具软件。 ↩
2. 我并不清楚在 Windows 开发团队中，记事本软件是不是由“一个人”来开发的。但大多数人认为类似这样规模的产品，是可以由一个人完成的。 ↩
3. 不过对于一个时间跨度很大，或者会持续多个阶段的项目来说，这些问题可能就落到了项目经理的头上，因为他也担负着团队建设的责任。 ↩
4. 在这里以及后文的讨论中，我是特指 Windows 中的 write.exe 这个写字板工具软件。 ↩
5. 传统软件工程模型其实就是一个软件开发方法论在过程与工具上的投影。 ↩
6. VEO 与 LoE 描述的是相同模型的两个方面。二者的区别在于，前者面向领域间的差异，后者体现项目/系统整体下的角色冲突。基于系统整体观察时，若从组织形态上来说，应强调 LoE 中的冲突，因为这是组织外在的、形的东西；又若从组织结构上来说，则应强调 VEO 模型反映的领域与角色，因为这是它内在的、质的东西。 ↩
7. 一定程度上，可以参考奥尔森有关利益与利益联盟的形成的理论。 ↩
8. 这种关系不是衡定的而是变化的。例如组织力通常扮演堵的角色，但当系统趋向呆板、滞化时，又通常是用组织力来实现疏的效果。 ↩