Question

可见，在既不存在所谓 事实 （因而也难有可信的主观判断），又没有所谓 战略 时，我们是可以藉由 前瞻方向 来形成架构意图的。而另一方面，我们也可以尝试 回溯问题 。

Soul 曾经是我邻座的同事。某天一早，他敲响了我的工位的隔板，问道：Hi，Aiming，你有没有一个苹果？显然我不会一大早地备好了苹果来等着他的发问。因而我只是诚实地回答道：没有啊。然后机械地开始一天的工作：打开电脑、泡茶、拿出文件夹，以及把椅子调到合适的角度……

等等，我们在谈什么 10 ？其实，仅仅在几十秒之后，我便醒悟了——Soul 的“一个苹果”不过是一个需求。我有或没有一个苹果，或者能否帮他找到一个苹果，或者他找到一个苹果之后是否太酸太甜等等细节，都只是由这个需求开始的求解（又或者面对这个需求时，就如同我当时的茫然无解）。一刹那之间，我便绕过了这一需求的纷繁枝节，再次回问他道：你是不是饿了啊？

这个场景之所以让我如此印象深刻，是因为在前半段中我经历的是典型的“程序过程式”的思维活动，如同图 9 所展示的。

图 9　“程序过程式”的思维活动

我们的软件开发活动向来是从对需求的分析开始的，经过设计、开发等过程，最后交付和维护。这一过程是如此的自然，因而我们将它从历史的开发活动中“识别”出来之后，立即被看成是软件工程作为一个成熟概念的标志 11 。然而在上述场景的后半段，我并没有立即陷入对“（能或不能，以及具体如何）满足需求”的挣扎之中，我从 Soul 的需求中回溯到整个系统所面临的问题：“要一个苹果”是因为饥饿吗？ 12

如果真实的问题是“在这个早晨，Soul 饿了”，那么饼干、馒头甚至一杯早茶都可以解决他的问题。为什么一定要去满足“一个苹果”的需求呢？可见，我在这后半段中所经历的，其实是图 10 所示的另外一种思维模式。亦即是说：我们可以暂时将“满足系统需求的急迫性”放在一旁，而去寻求“究竟是什么问题导致了这些需求”。当我们看到了问题，也就同时看到了那个解的抽象。

图 10　面向问题的思维活动

煮一枚鸡蛋 13 真的是一个需求吗？当我们把煮鸡蛋视为一个系统的时候，一切前设都既成定局：我们只关注于一枚鸡蛋的生熟与安全，而并不关注“究竟是什么”导致了我们要去煮一枚鸡蛋。同样的问题被放大无数倍之后，我们也只是关心一锅鸡蛋与一枚鸡蛋的煮法的异同。我们往往在做一些具体行为的时候，忘掉了它的源起，这便如同《大道至简》中谈到的愚公一家，数百年的移山工程结束之后却不得不去筑关自守。

需求不是问题，但需求是问题的表现。例如，Soul 的问题是饥饿，而表现却是需要一个苹果。我们所关注的系统大致也是如此，它可能表现为一系列直接的需求，因此我们可以从需求中找到事实或直接获得战略设定；它也可能表现为一些看似无关的间接需求或间接问题，在这些表面现象的背后，总会有一些核心的问题是它们的真实动因。

“真实动因”是一个关于“找到问题”的极佳设问。通常，我们对需求的描述都是“谁，做什么”，接下来是一些限制条件，例如“在哪里做，如何做” 14 ——这是我们一般性的需求分析方法。而在这些行为中，提出“原因”这个疑问，就是为这一需求找到它的动因。当我们的多个需求都指向相同的、相类似的动因时，我们就已逼近核心问题——我们最终缺乏的，仅仅是将这些动因归纳成问题而已。

什么是问题？问题有两个形态：其一，若系统存在某种“一般过程”，则阻碍这个一般过程的，必然是核心问题；其二 15 ，若系统存在一个确定的观察者，则所谓问题，就是这个观察者的期望与现实之间的差异。换作精炼一点的描述：

所谓问题，要么是系统与其要素之间的矛盾，要么是观察与其预期之间的矛盾。

我们在系统中引入了一般过程与观察者，前者是“导致问题”的内因，后者则是其外因。系统的不变性，一般来说是由前者决定的，所谓平衡，即是在这个一般过程的要素之间的、时间与空间上的权衡；系统的变化往往是后者导致的，亦即观察者——例如经营角色或主管——对于系统的期望缺乏一贯性。