规则引擎并不灵:康威定律不适用于刚性设计 - verraes

22-05-24 banq

软件设计与康威定理是两种不同的东西,软件设计是针对软件的,康威定律认为团队组织管理方式决定了软件的设计,因为这两者本身就属于一个大系统。
但是虽然你的团队划分按照康威定律,最终软件设计还是不行,原因是康威定律并不适用于刚性的硬设计,Mathias Verraes这篇新文章认为:
人事方面的人员重组可能会帮助你获得你想要的系统设计,但是前提是这个系统必须是全新的重新开始的新系统,或者这个系统至少在适应组织方面非常灵活。如果是设计已经僵化了的旧系统,重构没有用,换人的人事重组也不会。
文章还批评了规则引擎本身的局限,它还是一种分割思维的体现,没有从整个系统高度去设计,这篇文章也强调了复杂性系统的思维和通常科学分析思维的区别。以下文章摘要,详细点击标题:

康威定律 是一种组织工程方式:它告诉我们需要改变团队和组织结构才能实现我们想要的系统设计。越来越多的组织根据这个想法进行重组,但他们最终却没有得到他们想要的系统。

我们什么地方弄错了?
例如,GitHub是一家分布式公司,利用GitHub建立了一个分布式协作的工具。虽然系统确实模仿了他们的组织结构,但改变组织似乎并没有产生同样的效果。
这是因为我们没有考虑到设计中的系统本身的属性。

理论本身就是系统
康威Conway博士描述了一种 "系统的线性图与设计组织的线性图之间的结构保持关系 "。他对 "系统 "的定义比 "软件系统 "要宽泛得多。因此他的康威定理定义更符合系统理论,即(松散的定义)所有的东西都是一个系统,所有的东西都是一个系统的一部分。

例如,康威写道:"在同样的意义上,一个理论是一个系统,这可能不那么明显"。他的例子涉及调查员形成了一个关于飞机如何坠毁的理论:调查员们根据他们的专业领域,对导致坠机的不同事件创建了子理论。该理论的结构将模仿调查员组织的通信结构。

一个软件系统并不是生活在真空中。它被嵌入到生产这个系统的组织中。它受我们关于软件的理论支配:它是如何工作的,它做什么,它为什么这样做,它是如何连接的。我们把这些理论称为 "模型 "和 "架构"。

在一些组织中,这些理论只存在于人们的头脑中。其他人则用图表和文件来表达这些。如果他们持续关注这些模型的协作和发展,那就更好了(例如,使用领域驱动设计)。但是,无论你是否有图表,每个使用或设计系统的人都有一些关于该系统的理论。如果不对这些理论进行明确的建模,我们不仅有可能得到一个糟糕的系统设计,还有可能得到关于这个系统的错误信念。

规则引擎等反面案例
十多年前,我曾为一家SaaS公司提供咨询。我发现,在CEO、销售人员、客户成功经理和培训师、客户和工程师之间,对系统如何运作的信念差异很大。如果你立即认为工程师有最好的理论:不。他们对设计(主要是由他们的前辈创造的)了解甚少,以至于他们每晚都要删除和重建客户仪表板数据库。这是他们能在结果中获得一些一致性的唯一方法。

另一个例子是Aardling的一个客户,一个在具有复杂监管要求的领域运营的B2B公司。在创建公司时,首席执行官(一个领域专家)和首席技术官同意首席技术官不参与这个领域的复杂性。相反,技术将以一种允许技术保持与该领域无关的方式来构建。为了做到这一点,工程师们建立了一个表单生成器、一个规则引擎和一个模板语言。他们聘请了(非技术性的)领域专家,并教他们如何使用这些工具来建立面向客户的功能。

快进到几年后。从系统设计到产品再到组织控制结构,关于公司应该如何运作的理论已经渗透到了所有的东西中。

但你只能用表单和规则引擎做这么多。

用这些工具可以很容易地建立起一些功能,有快速的周转时间,但其他一切都必须由工程师来完成。这需要预算和优先级,而且往往是通过捷径完成的,这反过来又使后续的修改更加困难。整个设置使其无法实现某些增长目标。这些团队没有自主权,需要大量的协调来实现任何目标?重组能解决这个问题吗?尽管系统设计模仿了公司成立初期的沟通结构,但现在的系统太僵化了,仅仅是团队的洗牌是无法影响的。

僵化的系统
逆康威定理的倡导者告诉我们,我们所要做的就是重组团队以获得更好的系统设计。但是,如果软件本身,创造它的人类(社会技术)环境,以及人们对系统的信念,都只是属于他们自己的另外一套系统,而且他们都受到组织的沟通结构的影响,那么应用这个定理就变得更加混乱。

为了有效地干预我上面的两个例子,你必须解决组织、系统以及人们对组织和系统的理论。

软件应该是柔软的,也就是说,可塑性强,容易改变。
通常情况下,它其实不是容易改变的,因为这些系统通常是深度耦合和相互连接的。

改变一个组件会产生连锁反应,不仅仅是在软件组件中,而是在整个组织和客户的生态系统中。如果我们的软件的这种僵化性是我们的主要瓶颈之一,你会认为我们会急于解决这个问题。然而,令人失望的是,很少有软件组织对其软件的深层结构改进给予足够的重视。

相反,他们转向了重组。而这是一个诱人的承诺:改变你的组织,得到你想要的系统设计。它甚至带有法律,所以它不会失败! 然而,正如一位客户的首席技术官曾经告诉我的,"我们重组了,但是系统没有收到备忘录"。(有一个挽回的因素:管理者只能间接地影响软件系统,而他们唯一的工具是会议和重组)。

(banq:从代码重构 到代码重写,再到换人:组织重组,经过这三个阶段血流成河,损失巨大,人才流失严重,最后还是失败,关键是没有人知道软件工程失败的深层逻辑与原因)

扩展康威法则以说明刚性问题
康威法则是错的吗?不,我不这么认为。当从头开始设计一个系统时,它是正确的,这正是本文所描述的。当使用一个灵活的系统设计时,它是正确的,因为它足够灵活,可以适应模仿新的团队之间交流沟通结构。
但它不能很好地转移到适用现有的具有刚性设计的系统中。

我建议这样做:
系统设计将模仿组织的沟通结构,但只是在设计的灵活性允许的范围内。

Conway博士评论说:"我认为[沟通结构和系统设计之间]的关系是一种约束,仅此而已。你可以通过扰乱一方或另一方来改变什么,取决于它们的具体特征 "。

因此,"反康威演习 "也需要被扩展。

如果系统是新的或灵活的,改变组织结构以获得你想要的系统设计;如果系统是僵化的,就先解决这个问题。

或者,更简明的说法是:

人员重组并不能解决一个破碎的设计。

当涉及到新系统的设计时,康威定律被低估了,但当涉及到现有系统的重新设计时,却被夸大了。

一个新的绿地项目有无限的灵活性。但随着设计中更多的耦合和互连,它就失去了灵活性。我们需要尽早地、持续地考虑我们的组织结构,而不是在设计僵化后才去考虑。

防止我们的系统变得僵化需要持续的关注,从成千上万的小的局部设计决定到大规模的架构。为了支持和促成决策,我们需要关于系统、领域、产品和它所服务的生态系统的良好模型或理论。

当我们发现自己面对的是一个僵硬的系统时,反康威演习只是我们可以使用的工程设备之一,而不是一个魔杖。

归根结底,好的设计是导致良好设计的系统的原因。

1
猜你喜欢