我们无法有效分析问题的一个主要障碍是思维跳跃。大多数复杂问题牵扯到多个子问题,而每个子问题有有其自身的结构。思考这些问题的时候,我们很容易在不同子问题和不同层面之间跳跃。这样的跳跃将思维的展现拉得过长,难以集中突破,要提升思考的效率我们必须学会避免思维的跳跃。

人类的思维本身是跳跃的。我们的思维是大脑内的点信号在神经网络中游走的过程。这个过程本身是不断发散的。每一个新的想法甚至词语都可能出发一大堆相关的想法,以至于在思考一个问题的时候,我们常常会随机游走,等回过神来的时候才发现已经偏离到了一个陌生或者细小的领域。

但从另一个角度来看,思维跳跃有时候是寻找问题内在结构的努力。思维跳跃的程度往往跟我们队该领域的熟悉程度相关。对于完全陌生的领域,我们很难产生跳跃,因为缺少足够的知识,比如如何登上月球。对于完全熟悉的领域,我们往往可以高效的找出问题的内在结构,而沿着内在结构逐个解决即可。

最容易产生跳跃的问题往往来自于我们部分熟悉部分部分陌生的问题,而这也正是我们日常工作生活中最为常见的问题类型。因为有一定程度的熟悉,我们可以获得一系列思考的起点,但每一个子问题的深入又需要一定程度的研究。我们或许感到继续深入的困难而主动转移思路,或许因为对某个问题的兴趣而不断深入。

比如为了满足业务增长的需求,我们正在考虑将数据从一个数据库系统迁移到另一个数据库系统。我们熟悉现有的系统,对新系统则并不完全了解。我们可能会在下面的问题之间跳跃:

  • 具体应该怎么进行数据迁移?(执行问题:如何做)
  • 新的数据库适用于我们的工作场景吗?(是否合适的问题)
  • 我们的工作场景遇到的问题是什么?(知识缺乏:对现有的系统进行诊断和总结)
  • 新的数据库适用于什么工作场景?(知识缺乏:需要研究新的系统)
  • 新的数据库中的数据模型要怎么样设计?(具体执行问题)
  • 使用新的数据库给我们服务器的读写模式带来了什么变化?(是否合适的子问题)
  • 这些变化如何影响我们的应用程序接口?(是否合适的子问题)

你很容易可以看出来,上面这些问题在至少涉及三个不同的层面。为了有效的思考,我们需要抑制思维跳跃的冲动,努力专注于一个目标:定义问题,并找出解决当前问题完整而不重叠的子问题。

首先我们需要定义问题:

  • 现状

现有的数据库系统无法满足业务继续扩张的需求。一方面是因为它不支持容量的线性扩张,按照现有的业务增长速度,在X时间之后会遇到数据库容量和性能的瓶颈。另一方面是现有的数据库模型设计方式不再适合业产品的快速迭代。随着产品的演进,目前的数据库模型已经过于复杂,新人掌握当前产品以及迭代新产品的成本都越来越高。

  • 理想状况

一个可以线性扩张性能以满足业务增长的数据库系统。 简化的数据库模型设计从而降低产品迭代的成本。

  • 问题

一个可能选项是迁移到新的数据库系统,同时重新设计数据库模型。需要研究:新的数据库系统是不是适合我们的业务模式?迁移到新系统的具体方法和成本如何?

为了回答新系统是不是适合的问题我们需要回答下面的子问题:

  • 1.1 新的数据库系统能否解决性能扩张问题?
  • 1.2 新的数据库系统是否适合我们的业务模式?

对第二个问题我们又可以分为下面的子问题

  • 1.2.1 现有的业务模式对数据库有什么样的要求?
  • 1.2.2 新的数据库系统能否满足这样的要求?