如何快速理解复杂业务,系统思考问题?

简介: 对于复杂问题的思考其实是有层次的,从最表面的事件,到事件背后的规律,再到这个问题的结构模式,再到价值观,层层递进。在画完自己的业务系统因果回路图之后,再结合这个心智模型,思考自己的思考在哪个层次,是否可以有机会再下钻到更深的层次。

正视复杂性

我们必须承认这个世界原本就非常复杂,就像以我们现在的科技仍然不能攻克新冠病毒、不能精确预测天气、不能有效控制经济形势异常波动一样,任何试图浮于表面、疏于投入就想了解并解决一个复杂问题的傲慢做法,最终都只能接受无情的打脸。
回到我们阿里当前的业务,随着市场规模的扩大、用户群体的多样性、公司组织的持续膨胀和细分、产品历史包袱的累积,我们的业务不可避免的越来越复杂和难以理解。就像著名的热力学第二定律(熵增定律)所解释的那样,只要没有外界系统的做功(我理解是一个颠覆性的业务模式),我们当前的系统就无可避免的持续熵增
但作为在业务线工作的一员,更加全面的理解我们手上的业务逻辑是我们能做好工作的基本条件,我们肯定不能满足仅仅是点状理解的一些信息,也不能接受理解一个业务只能依赖长时间的工作经验,所以这里给大家介绍一个帮助自己全面理解一个复杂系统的工具:“系统思考”。之前我会尝试用它来帮助自己梳理手上的业务逻辑,感觉有一定的作用,做了这个入门总结,希望对大家有帮助。
什么是系统思考

 我们的思考误区

image.png

先回忆一下,从很小的时候起,我们接受的教育是让我们怎么解决复杂问题的?
是的,就是通过拆解,把一个复杂为题拆解成多个不那么复杂的问题,再把不怎么复杂的问题继续拆解成简单的问题,最后通过解决一件一件的简单问题进而来解决原本的那个复杂问题。
这个方法是非常了不起的,也成就人类的伟大,我们把世界分割成一个一个的片断加以分析后再合并、还原,其思维方法遵循如是简单的法则:“部分之和等于整体”。这种拆分的思考方法在大部分情况下都比较有效,它让人产生了幻觉,误以为这世界是由一个个的各别事件堆积而成,看不见普遍存在的、整体复杂的关联、互动作用,从而导致人类行为的短期性、盲目性和灾难性。就像“盲人摸象”、“快思考”等都指出这种思考方式的局限性,所以在我们的工作中,如果仅仅秉承着“拆分”的方法,是不能解决真正复杂的问题的。

image.png

所以我们这里介绍一个从整体系统的角度思考复杂问题的方法:“系统思考”,本文的核心思想主要来自两本书:《第五项修炼》、《系统思考》,大家如果看完本文,觉得还有点意思,可以考虑找来这两本书深入了解一下。


 什么是系统


在介绍“系统思考”之前,我们先确认下什么是“系统”。


“系统”都是复杂的,但并不是任何看上去“复杂”的东西都是系统,在我们讨论的范围里,一个规模庞大的衣柜、一发炮弹、一大束鲜花都算不上是一个“系统”。

系统是指一组 相互作用、相互关联、或相互依赖的部分组成的复杂而又统一、具有特殊目的的整体, 系统会拥有其单独部分不具备的特征


我们说的“系统”都是动态的,比如下面的足球队、龙卷风、蜂群都能称之为一个“系统”。

image.png

系统一般有三个核心特点,多个部分、相互依赖、特有目的:

  1. 系统一定是由多个部分组成的,如果只有一个部分,一定不能称之为系统;
  2. 各个部分之前必须相互有依赖关系,单独的部分不能独立发挥它的价值;
  3. 所有部分整合在一起有它的目的,虽然有的时候自然和社会系统往往难以确知它的目的。

image.png

 什么是系统思考


对什么是“系统”达成一致后,我们来看一下什么是“系统思考”。为了好理解,我们把系统思考扩展成三个不同的思考概念,可以理解为“系统思考”是同时具备这三种思考模式的一种方法:

  1. 【深度思考】不能停留在现象的表面思考,要能从现象深入到问题的背后,找到问题的本质;
  2. 【全局思考】不能单点、局部的看待问题,要能站远一点,看到问题的全局;
  3. 【动态思考】不能停留在某个时刻看问题,要理解每个人、每个业务之间都是动态变化的;

image.png系统思考不仅仅是一个概念,更是一套思考问题的方法论,下面重点介绍这套方法论是怎么操作的。
系统思考的工具和方法

首现我们举个列子,下图左边这个人接水的场景就是一个典型的系统,那我们可以怎么描述这个系统呢?


image.png

  1. “一个人正在接水”?太简单,没有描述清楚这是一个什么样的系统;
  2. “一个人左手控制水龙头,右手拿杯子在接水,眼睛在观察水位情况”?还是觉得缺少结构化,没有能清晰得描述出这个系统中各个部分之间的、动态的、依赖的关系。


我们再看右边这个被抽象的结构图,每个节点都是系统中的一个变量,不同变量之间形成了关系,通过这个图,我们能理解在系统中不同部分之间是怎么相互依赖和影响了,我们可以预料系统可能的走势,也可以进一步思考怎么在这个系统中施加作用而影响系统的走势。
基于上面这个描述系统里各个部分相互作用的因果逻辑图,我们引入“系统思考”里的一个最重要的工具:因果回路图,下面我们就来讲一讲这个因果回路图的画法。

 因果回路图

image.png

一个用来描述“系统思考”的因果回路图一般由三个部分组成,分别是:

  1. 【变量】,变量是我们建模的系统结构里的因素,它的值是随时间而变化的,一般是个名词;
  2. 【链路】,变量之间可以形成链路,这个链路是形成因果逻辑的链路(一个变量的变化影响另一个变量);
  3. 【回路】,几条链路可能形成回路。如果从变量A到变量B有一条链路,当从变量B到变量A,之间可能通过一系列其它的变量,也有一条链路时,就形成了回路。


 两种回路模型


找到系统中的回路是“系统思考”的重要抓手之一,所以我们会重点讲讲回路。我们有两种最典型的回路,一个叫“增强回路”,一个是“平衡回路”:


  1. 【增强回路】Reinforcing loop,一个回路中的变量增加或减少,会影响这个回路中的所有链路持续增加或减少,发展的趋势不受控制,我们常见的类比说法比如“恶性循环”、“强者恒强”等等就是增强回路导致的;
  2. 【平衡回路】Balance loop,一个回路中的变量增加或减少受到系统中其他变量的反向影响,使得这个系统中的变量在长期的维度会表现出一种保持平衡的状态,比如最常见的例子是,猪肉如果大幅度涨价,就会有更多的人加入到养猪的行业,第二年的猪肉就会应为供应充足而降价,最终长期看价格会维持在一个平衡的状态。

image.png

后面的回路里,我们会用“R”表示增强回路,用“B”表示平衡回路,在链路中,会用“+”表示变量之间的正向的影响,用“-”表示变量之间的负向影响。


 回路上的时延


在因果回路图中还有一个非常重要的概念就是“时延”。
一个变量的变化影响另一个变量并不一定是马上生效的,他们之间的关系有可能存在时延。一个大家在日常生活中很容易遇到的例子就是调节洗澡水的温度问题(特别是来到一个不熟悉的环境里,如宾馆),怎么调到一个适合自己的水温并不容易,要不就是水温过高,要不就是过低,这背后就是水温调节器和实际水温变化中间存在“时延”导致的。

image.png

在因果回路图引入时间概念之后,我们在链路之间增加一个“||”的符号代表这两个变量之间的因果关系存在时延。

image.png

时延在工作中最典型的例子比如:招聘对项目人力缺口的影响、代码单元测试度产品质量的影响、学习对于工作能力的影响等等。对时延的感知也是帮助你理解系统复杂性的重点之一。
系统思考的5个基础模型


如果现在大家对系统思考最基本的工具“因果回路图”有了理解之后,我们就可以参考软件开发领域里的“设计模式”(Design Pattern)思考一下,系统思考是不是也有一些常见的模型。


是的,因果回路是有一些常用、特定的“套路”,这些套路就是我们常说的“模式”,这里我们介绍4中最有代表性的基础模型。


 饮鸩止渴

image.png

“饮鸩止渴”描述了我们是怎么在进度的压力下一次又一次的放弃了自己的坚持,因为链路上的延迟,让我们心存侥幸,最后使得我们的系统背负了沉重的技术债的。


 舍本逐末

image.png

“舍本逐末”描述了短期表面方案和长期根本方案之间的冲突,因为增强回路的存在,使得我们不能对“效能优化”这个根本的方案提高优先级,最终上瘾于短期表面方案。


 目标侵蚀

image.png

“目标侵蚀”描述了我们怎么在目标完成的压力下,放弃了做争取的事,而是通过直接降低目标来达成目标的。真实的“加速”措施通常需要更长的时间才能见效。正是这个延迟,使得我们逐步转向上面的平衡回路,需求延期和下调目标成为一种习惯。

image.png

“成长上限”描述了一个增强回路不可能独自持续下去,在一个更大的维度,一定会有另一个因素(或平衡回路)对它进行限制,这个就是成长上限。


 公共悲剧

image.png

“公共悲剧”描述了对于大家共享的有限资源(APP首页弹窗),每个个体(业务单元)都想自己利益最大化。使用者越多,越消耗用户对平台体验的信任。随着弹窗总量迅速增加,遭遇用户容忍瓶颈时,消费者会感到不可容忍,用脚投票。


理解业务逻辑的例子

对于我自己过去接触的一些复杂业务,我会尝试使用“系统思考”作为工具去帮助自己加强对业务的理解,我经常在画对应业务的因果回路图的时候会发现一些新的观点,产生一些新的疑问,这个过程对我的帮助良多。
这里还是要强调一下,“系统思考”只是一个工具,不同的人,面对同样一个系统,因为了解的信息多少不同,关注的问题角度不同,对系统发展方向的期待不同,都会导致画出来的因果回路图有所不同
所以,“系统思考”就是一个帮助你不断的通过zoom out、zoom in 来完整的、体系的看待复杂问题的工具,通过使用这个工具的过程,帮你更好的思考和理解你面对的复杂问题。


image.png

image.png

image.png


最后,再补充说明一下,对于复杂问题的思考其实是有层次的,从最表面的事件(正在发生什么),到事件背后的规律(发展趋势是什么),再到这个问题的结构模式(解释趋势背后的原因),再到价值观(驱动这个模式的理念),层层递进。在画完自己的业务系统因果回路图之后,再结合这个心智模型,思考自己的思考在哪个层次,是否可以有机会再下钻到更深的层次。

相关文章
|
7月前
|
存储 运维 架构师
经验教训:微服务设计时的五条宝贵经验
在著名软件著作《人月神话》中提到,软件世界没有“银弹”,这句话当然适用于架构领域,随着从单体架构过渡到微服务架构,因为将原有系统打散,给系统增加了许多不稳定因素。
58 0
|
6月前
|
移动开发 数据挖掘 C++
数据驱动业务,就得这么干!
数据驱动业务,就得这么干!
|
11月前
|
设计模式 小程序 测试技术
面对复杂问题时,系统思考助你理解问题本质
面对复杂问题时,系统思考助你理解问题本质
170 0
|
11月前
|
测试技术
「业务架构」需求工程——需求验证(第4部分)
「业务架构」需求工程——需求验证(第4部分)
|
11月前
|
安全 程序员 UED
程序员在软件开发中,业务开发和非业务开发到底哪个工作量更大?
随着互联网的普及和信息化时代的到来,软件开发已经成为了一个非常重要的行业。而在软件开发的过程中,业务开发和非业务开发都是非常重要的环节。那么,在这两个环节中,哪一个工作量更大呢?本文将就此问题简单探讨一下。
129 1
程序员在软件开发中,业务开发和非业务开发到底哪个工作量更大?
|
11月前
|
人工智能 数据可视化 前端开发
技术人如何做好业务?
技术人如何做好业务?
251 0
|
敏捷开发 架构师 项目管理
架构师才能看懂的大型网站架构面临的挑战:业务架构的基本思路
业务架构的基本思路 大型网站系统有很多功能,一次性明确所有的功能需求并设计出一个庞大的业务架构是一件费力不讨好的事情。因为在项目前期,难免会忽视一些琐碎功能,而随着开发的进行,也会有很多新的想法产生,基本上不会存在完全按照最初的业务架构设计完成的软件产品。因此,业务架构不仅要做到“规整功能模块,厘清产品业务逻辑”,更重要的是如何做到“有规划性地应对项目过程中的需求变更”。
|
Unix Java Linux
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1089 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
|
Unix Java Linux
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48592 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
|
数据可视化 架构师 领域建模
如果你连业务领域建模都不会,那还怎么做架构师呢?
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。概念比较深奥,其实说白了就是我们把基于对业务的理解画成一个类图,并画出这些类之间的关系(面向对象)。
287 0
如果你连业务领域建模都不会,那还怎么做架构师呢?