[分享] 问题背后的问题

我的一位导师 Steven Caus 总是教我“问题背后的问题”的概念：我们收到的问题并不总是我们需要解决的问题。

这个概念很简单。当有人向你提出问题时，与其盲目地执行请求，不如退一步思考，试着理解他们真正想要实现的目标。很多时候，这项任务可能并非实现他们既定目标的最佳方式。

真正的要求是什么？

那么让我们从一个例子故事开始。

一个项目团队来找你，想要一款新的项目管理工具。他们已经把范围缩小到三个不错的选择，每个都有精美的演示和长长的功能列表。他们想知道的只是你的意见：哪一个最适合我们的架构和战略？

在深入选择过程之前，你会问：“你现在拥有的有什么问题？”

他们很快就给出了答案：“它老旧、速度慢，而且一切都需要手动操作。我们已经快要被淹没了，这个工具只会让我们更加难以承受。”

在这种情况下，工具本身并不是真正的问题。真正的问题是团队工作过度或人手不足，无法满足当前的工作量。当然，工具可能老旧缓慢，但真正的痛点并不会因为一个新工具的出现而消失。事实上，新工具会带来迁移、设置、培训等工作。而当你已经快要喘不过气来的时候，这些都无济于事。

相反，我们可以从上游着眼：我们能否减轻他们管道的压力？能否将最糟糕的手动步骤自动化？能否给他们喘息的空间，而无需引入六个月的部署周期？

他们一开始不会兴奋。没有闪亮的新玩具。但我们省了不少钱，避开了一个风险项目，而且确实帮助解决了真正的问题。

这一切都是因为我们停下来思考问题背后的问题。

为什么会发生这种情况？

作为架构师，我们拥有俯瞰整个组织的便利。这种优势并非很多团队都能拥有。我们可以追踪各个系统之间的联系，并发现其他人可能忽略的模式。

但我们故事中的项目团队呢？他们深陷困境，工作过度，时间紧迫，还要忙于各种耗费精力的手动任务。从他们的角度来看，工具就像敌人一样。谁又能责怪他们呢？当你沉在水下时，有时你会幻想更好的潜水装备，而不是先想着怎么上岸。

这些对话并非为了证明某人错了，而是为了合作 。你并非试图成为房间里最聪明的人，而是试图提供帮助。他们了解具体工作的艰辛、细节和日常。你则能提供全局背景和不同的视角。

他们可能不知道其他可能性或其他团队的做法，而你也未必清楚他们实际的工作流程。

问题背后的问题并非挑战，而是一种理智的检验，一种将意图与行动相结合的方法。

为什么架构师总会掉进这个陷阱？

我们都想帮忙，尤其对看起来在挣扎的团队。如果他们带着一个看似“万能解药”的方案来找你，很难拒绝。

告诉他们不能有新工具，或者他们的方案可能解决不了真正的问题，感觉就像让他们失望了。

然而，这正是你的职责所在。

我们的角色不是对请求“盖章批准”，而是守护组织的长期健康。这意味着要能识别出那些所谓的“解决方案”，是否会给本已紧绷的系统增加更多负担。

一个治标不治本的权宜之计，最终会成为长期的包袱。而这个包袱可能会跟随我们好几年。

现在做困难的事，是为了以后不用费力收拾残局。

问题背后的问题如何浮现出来。

要得到真正的答案需要技巧。

如果你直接问 “你到底想达到什么目的？” ，人们就会变得防御起来。这听起来像是在挑衅，就像你在戳他们思维的漏洞。

同样，如果你说 “听起来你真正想要的是……”， 即使你是好意，这听起来也像是自鸣得意。

所以，换个角度。问问他们的痛点。什么地方令人沮丧？什么地方耗时？什么地方感觉应该更容易些？

寻找规律、异常之处以及不一致之处。将他们的设置与其他团队的工作方式进行比较。观察组织的其他部分。

当你收集到足够多的线索时，就退一步，把它们搁置起来。“这么说来，这个工具运行缓慢，工作繁琐，而你已经捉襟见肘了。换个工具真的能解决这个问题吗，还是只会增加新的负担？”

这有点像侦探故事。你来这里不是为了审问，而是为了调查。去问那些能带来真正答案的平静问题。

而且你们不是一个人在战斗。你们都坐在桌子的同一边，共同解决同一个谜团。

表面之下

人们并不总是要求他们真正需要的东西。他们只会要求他们认为能尽快止血的东西。这是人之常情。

你的工作就是倾听，轻轻地探索边缘，找到背后的故事……这就是架构师和一个普通管理员的区别。

有时这意味着你会在短期内让他们失望。但如果你做得对，你就能解决真正的问题，而不是引入未来的问题。因为在架构领域，那些看似容易的答案，往往经不起时间的考验。

原文:The Real Ask

本作品采用《CC 协议》，转载必须注明作者和本文链接