我们正朝着云发展。这在我们构建软件系统时引入了新的复杂性级别。一个方面源于云中的技术和架构。微服务形成松散耦合的分布式系统。第二个方面是，我们不仅要构建和运行软件，还要优化整个过程。例如，我们希望支持不断的增量更改，以便我们能够基于简短的反馈循环改进这些系统的业务结果。

这意味着我们正深入到一个以混沌和复杂性为特征的环境中。在这里，我们重温Jamshid Gharajedaghi的陈述，并提出应用系统思维在这种情况下可能会有所帮助-无论系统思维意味着什么。

应用系统思维包括三个步骤：

步骤1：构建系统并制定您的问题。第二步：透过系统镜头看第三步：运用系统思维来设计解决方案

让我们从找到一个系统开始，并制定我们要解决的问题。

我们可以这样描述我们的系统和问题：优化一个复杂软件系统的业务价值。

这看起来很合理。软件系统应该是一个系统，优化业务价值是我们需要解决的问题。那很容易，也许有点太容易了。现在的想法是从我们的利益体系中抽象出一个事实，即这是一个体系。在这个抽象层次上，我们可以看看系统思维，它描述了一般的系统特征和复杂系统可能面临的问题。优秀足球运动员的总和不一定能组成一支好球队。系统可以显示紧急属性。想想看，一群鱼是如何成群游动的。系统可以表现出混沌行为。输入变量的微小变化会导致截然不同的结果。系统不仅需要为生产力或稳定性而管理，还需要为弹性而管理。

这些陈述对我们以后将变得重要。

处理混乱和复杂性

复杂系统中的一个问题是，分析思维不足以理解或预测其行为。这是由于上述系统特性造成的。这意味着你可能很难预测和控制你正在构建或改变的系统的行为？你需要使用迭代反馈循环。用Eric Ries的话说，这意味着应用构建-度量-学习模式和迭代。听起来很简单，但事实并非如此。

你现在有了一个反馈周期和迭代，而不是正常的分析"因果"思维。当开发一个复杂的系统时，你会有很多反馈周期。每一个单元测试、每一个性能测试、每一个演示和讲解会话、每一个您设计的UI都会产生额外的反馈。由于系统具有紧急属性，因此在系统级也会有反馈周期。测量并不总是容易的。接受反馈是一种衡量手段。但有时你需要衡量一些东西，你需要一个KPI来做到这一点。定义KPI可能很困难。如果反馈回路中有长时间的延迟，某种预见是必不可少的（多尼拉·梅多斯）。反馈回路越短越好。学习步骤仍然是你运用分析技能的地方。

构建-测量-学习模式是一个反馈循环。要实现反馈循环，您需要：

定义技术和业务指标。有关一些示例，请参见下面Netflix的混沌工程和进化架构。测量已定义的指标。

所以，现在我们首先从系统思维的角度来看待系统。然而，我们不想只看一个系统，我们想为我们的问题设计一个解决方案。系统思维从几个方面帮助我们做到这一点：

整体思维：考虑整体、部分和周围的系统。操作思维：考虑端到端的流程。设计思维：在设计解决方案时要像设计师一样思考。社会文化系统

整体思维

一个系统不仅仅是它各个部分的总和。在应用构建-度量-学习模式时，我们必须解决部件级别。例如，人工智能包含哪些方面，我们可以应用单元测试。然而，我们也必须解决系统层面的问题。

整体思维的另一部分是：没有独立的系统（多尼拉·梅多斯）。在我们的上下文中，这意味着其他系统会影响我们的利益系统。我们也得考虑一下。以下是我们系统的目的和问题的优化方面：优化业务价值。这种商业价值是在公司层面创造的。这里的反馈循环又如何呢？事实上，这可能是最重要的反馈周期。

Netflix的混沌工程是关于提高系统层面的弹性。这将整体思维应用到软件工程中。

对系统架构的需求将在非功能需求中表现出来。随着时间的推移，许多增量更改可能会危及这些体系结构需求。您可以通过定义度量来保护它们。这些量度可以在过程层面（例如，性能需求）或系统层面（例如，弹性）。

操作思维

操作思维是关于系统中的过程。在我们的上下文中，建站系统哪个比较好，即优化复杂软件系统的业务价值，大数据的趋势，用户场景表示流程。使用"所以"部分，每个用户故事都与一个有助于优化业务价值的值相关联。这里还涉及许多反馈周期。它们用于设计单个用户情景，并将其嵌入到系统的端到端流程中。

用户情景映射（USM）为您提供更全面的用户情景描述：

设计思维