请多讨论问题,而不是解决方案 - frankel

22-10-24 banq

作为一个技术人员,我喜欢讨论技术。作为讨论,一般都是比较的那种:JVM vs. Net,Java vs. Kotlin,Go vs. Rust,Maven vs. XXX,等等。然而,我们很容易陷入我们心爱的玩具的优点和缺点的泥潭,谈论了几个小时,也没有达成一个令人满意的协议。

几年前,我曾担任 "解决方案架构师"。这项工作有不同的头衔,例如,解决方案设计师,解决方案工程师,但目标总是相同的:为一个问题找到 "最佳 "的解决方案,大多数时候是一个商业问题。

这项工作经历了以下几个步骤。
  • 讨论问题
  • 评估备选解决方案
  • 选择最合适的一个。有时,这个步骤是利益相关者的责任。

我不记得我有多少次看到人们略过1号步骤或完全跳过它。这里有几个轶事来强调我的观点。

"我想要一个Drupal"
当时,我正在为一个公共管理部门工作。请允许我不透露具体是哪一家。他们的流程规定,每个项目都应该有一个解决方案的架构师来实施上述工作流程。

有一天,一位项目经理要求与我会面,讨论一个新项目。他对要解决的业务问题描述如下。"X部门的IT主管想要一个Drupal。他有很多权力,所以让我们开始行动吧"。

不用说,我对他的做法多多少少有些惊讶。我试图讨论潜在的问题,但没有任何结果。他并不想解决根本问题:他只想顺从主任的心血来潮。

由于官僚主义的性质,他遵循的程序是需要解决方案的架构师来验证任何解决方案。他只需要我批准主任想要的解决方案。我离开了房间;我不记得到底是怎么结束的,但我没有批准任何东西。

顺便提一下,那些只是充当他人代理的人在组织中的投资回报率非常低,是零负值。有些组织往往比其他组织更能吸引他们。例如,没有竞争的组织不会遭受任何低投资回报率的后果,往往会吸引他们很多,例如,公共管理部门。

.env文件或不
我最近偶然发现了另一个例子。一位谷歌工程师写了一篇文章,名字很有挑衅性:"立即停止使用.env文件!"。在这篇文章中,他解释了.env文件的问题以及如何使用配置服务器来解决这些问题。

作为回应,另一位作者创建了另一篇文章,名为 "继续像往常一样使用.env文件"。正如你所想象的,作者重点解释了.env文件是可以接受的,并描述了使用配置服务器的问题。

最初的帖子几乎没有描述这个问题,在一个简短的章节中加速了这个问题。而在其中,作者写道。

>我甚至不需要解释为什么这很糟糕

对不起,但不遗憾:的确,你要解释

说实话,驳斥的帖子并没有做得更好。两人都专注于他们最喜爱的解决方案,但都没有出色地解释他们的问题,在他们的背景下。

PS:根本问题是.env文件管理并不能扩展,这对于像谷歌这样规模的组织来说,这是一个大问题;对于一个小组织来说,他们是没有问题的。

微服务是解决不多问题的办法
我们很难忽视微服务的热潮。很多人评论微服务的优点和缺点;很少有人写他们为什么实施微服务。

在以前的文章中,我总是小心翼翼地解释为什么微服务在大多数组织中是一个糟糕的想法。也许我没有讨论微服务所解决的问题,所以就在这里。

成功的组织确实在成长。大多数时候,为了支持业务增长,开发人员的团队也会随之增长。在某一时刻,团队必须分成几个子团队来处理增长问题。对,这就是问题所在。

现在,很多开发人员必须在同一个代码库上工作。历史上,我们通过以下方式处理这种复杂性。

不同的开发流程,例如,Git流程、GitHub流程、GitLab流程
由专人负责管理复杂的发布管理
我的经验告诉我,这种方法可以扩展......到一定程度。当开发人员的数量达到~70人时,我目睹了经验丰富的开发人员团队的同步问题。也许其他人有不同的经验。

在任何情况下,这是我们需要讨论的核心问题。只有这样,我们才能决定哪些替代方案可以解决开发团队的增长问题。

在技术支持中质疑问题
即使在技术支持中,也应该首先讨论问题。支持确实经常直截了当地回答所问的问题。我认为这是最糟糕的事情:它可能会完全跳过根本问题,提供一个不合格的解决方案。

这里有一个例子,取自StackOverflow:

我想添加一个从git拉来的项目,然后用Maven构建,问题是他们的pom.xml同时使用了私有和公共repo,他们告诉我删除私有repo来构建,这样就可以了,但我想用Jenkins自动构建过程。 — How to remove repo from pom.xml before building

答案集中在如何从pom.xml中删除东西上,因为这就是那个人问的。但问题是不同的:它是如何构建一个引用了自己没有访问权限的仓库的项目。删除XML行是众多解决方案中的一个,但我认为这不是最优雅的一个。

我可能会提议在Maven的设置中配置一个镜像。

Five whys
要想把重点放在解决方案而不是问题上,我认为应该采用五个为什么的方法。

五个为什么Five whys是一种反复询问的技术,用于探索某一特定问题背后的因果关系。该技术的主要目标是通过重复五次 "为什么?"的问题来确定缺陷或问题的根本原因。对第五个 "为什么 "的回答应该揭示出问题的根本原因。
- https://en.wikipedia.org/wiki/Five_whys


IMHO,一个人不需要五个为什么来谈论问题而不是解决方案。有几个就够了。通过走访问题的解决方案,你会发现很多背景,并可能改变一个思想开放的利益相关者的推理。

此外,你可能会注意到,在某些情况下,一个非IT的解决方案将是最合适的。记住,最好的代码就是没有代码。

总结
工程师们喜欢谈论他们喜欢的解决方案。然而,在没有背景的情况下对解决方案提出异议是没有用的。在不讨论问题的情况下同意一个解决方案甚至更糟。

讨论问题为了解问题的本质提供了宝贵的洞察力。如果你想带来更多的价值,你应该花更多的时间质疑问题是什么。