如何成为解决难题的高手-技术圈

我们在工作中总会遇到各种各样的情况，比如

经常不开心；
工作了两三年，收入一直没怎么提升，被同学、同事远远甩开；
晋升成为主管，却无法顺利的把工作任务安排下去，导致自己手里堆积一大堆事情，总也忙不完；
刚做完的软件项目，总是出现各种Bug，每天忙于修修补补，没有时间做新项目；
……

这些问题当中的任何一个，持续发展下去，都会让我们深陷泥沼，无法自拔。那到底怎么找到应对这些难题的解决方案呢？

《拆解一切问题》这本书给我们带来了靠谱的方法。

《拆解一切问题》的作者是横田尚哉，他是日本功能方法研究所所长，在解决问题方面很有研究，除了《拆解一切问题》，还著有《解决问题技术入门》、《解决问题技术实践》等图书。

天下大事必作于细，天下难事必作于易。《拆解一切问题》就教你把问题化难为易，拆解成具体可执行的步骤。读懂这本书后，工作中再遇到难题，就可以运用其中的流程和工具，找出相对优质的解决方案，就不用再愁眉不展了。如果能持续践行书中的“拆解思维和技术”，假以时日，还可以成为解决难题的高手。

《拆解一切问题》一书将解决问题分为五个阶段，给出了一个“ISSUE”解题法。我梳理了这套解题法的逻辑和所用到的工具，提取出2个问题、4个工具，组织成拆解问题的五个步骤，分享给大家。

第一步：借助两个魔法问题来察觉问题。
第二步：用“4M管理法”，锁定问题改善之处。
第三步：分析问题（问题树分解 + FAST图表法解析）。
第四步：用奥斯本检核表法收集灵感。
第五步：评价各解决方案，选出最优解。

接下来我详细介绍每个步骤。（注：文章内容较长，读完约需15分钟，理解方法和工具有一定挑战。）

第一步：借助两个魔法问题来察觉问题

很多时候，我们会对一些现象习以为常，不觉得它们是一个“问题”，不会产生解决它们的意愿。比如“总是忙于已交付软件项目的Bug，没时间做其他事情”这种现象，很多程序员就觉得其实也没什么，大家都这样。但实际上，这类现象，恰恰是个难题，解决掉之后，收益巨大。

要解决问题，就要先意识到出现了问题。

《拆解一切问题》第19页，给出了一种察觉问题的方法。

以下两个问题的提出，对于我们认识问题的本质是大有裨益的。

• 为了谁？
• 为了什么事情？

请大家经常思考这两个问题，这样做有助于发现出现问题的征兆和解决问题的线索。

这个片段介绍的方法是——“通过提问的方式察觉问题”，它给出了两个看起来很简单的问题：“为了谁”和“为了什么事情”。

有的小伙伴看到这里可能马上会产生怀疑，“就这？还用问？我们工作难道不是为了老板？不是为了公司的事情？”

是，乍一看，这两个问题的直接答案差不多就是这样的。但如果你真的这么用这两个问题，基本上你在所有的事情上得到的答案都一样，对发现问题和解决问题没有任何实质性帮助。

还有的小伙伴会说，其实不用问那么多，事情来了就干，干就完了。

的确，工作多年后，我们经验越来越丰富，积累的办法越来越多，能够越来越高效快速的处理流转到我们手上的各种事务。但“高效快速”的另一面是，我们遇到事情不会再问这个问那个，不会再探究做这些事情的目的。这样一来，我们就忽略了可能存在的问题和改变的契机，导致长时间在一个状态中重复，工作成效和个人成长都得不到应有的提升。

所以我们在遇到令人不适的现象或问题时，要停下来，先看看是不是发生了问题，找到真正的问题，后续的故事走向就可能截然不同。

那到底怎么做呢？

还是用两个魔法提问——“为了谁？为了什么事情？”

不过我们不能大而化之的把答案归结到老板和公司身上，而是要这么问：

这个问题（事情 / 局面 / 状况）会直接影响到谁？解决后对他有什么好处？

回到我刚开始说的例子，“忙于修复Bug，无暇做其他事情”，那深陷其中的程序员可以问的问题就是：忙于修复Bug会直接影响到谁？解决后对他有什么好处？

得到的答案是：直接影响到的人是自己，好处是自己能有机会做更多更重要的事情，能得到更多成长，获得更多回报。

有了这个答案，这位程序员可能就会觉得，哇，总是忙于修复Bug真是个问题，很有必要解决掉。

两个魔法问题的实质，是帮助我们创造一个暂停时刻，让我们重新审视自己所处的状况、面临的局面、手上的事务，发现其中潜在的问题，以便在事情变得不可收拾之前，有足够的时间来思考精准的对策，控制事态的发展。

现在，请你回想一下，工作中有哪些事情（局面 / 状况等）让你有违和感，用两个魔法问题自问自答，看看它们是否是需要解决的问题。

第二步：用4M管理法，锁定问题改善之处

当我们意识到当前的状况是一个需要解决的难题时，接下来要做的事情，就是将问题特定化，寻找要改善的要点，避免扩大化，失去控制。

《拆解一切问题》中给出了一个“4M管理法”，能帮助我们从四个方面来寻找改善点。

这时，我们可以尝试着用“4M管理法”拆解问题。简言之，4M是指人力（Manpower）、机器（Machine）、材料（Material）、方法（Method），具体如下所述：

• 人力：在现场直接从事工作的人；
• 机器：检测工具、模具等；
• 材料：原材料、半成品、零部件等；
• 方法：工艺流程和操作规范。

4M是生产过程中的基本要素，在生产中，这四项要素如果出现异常就会对产品的品质造成一定影响，所以我们需要对这四项要素进行重点监控。

这个片段中的“4M管理法”源于制造业，它对机器、材料、方法这三个方面的描述，都是特定于生产场景的。我们很多人的工作，与生产环境比较远，要运用“4M管理法”，就要搞明白，在自己的环境中，机器、材料和方法是什么含义。

来看一个例子，如果我们在办公室需要打印资料。请思考一下，完成这件事情的过程中，4M都是什么呢？

我的答案是这样的：

• 人力：我们自己。
• 机器：电脑，打印机。
• 材料：文件，纸，墨盒。
• 方法：将文件从电脑传输到打印机的方法；打印机打印文件的方法。

再看个例子，和申请加薪这件事上，4M是什么呢？

• 人力：我们自己，领导。
• 机器：电脑（需要用它搜集、整理信息）。
• 材料：报告；支持加薪的事实、数据、信息等。
• 方法：报告的写作方法；沟通的方法。

通过这两个例子可以看出来，机器可以对应到我们做事情时用到的设备或者产品上，这些东西往往有“加工”或“处理”的功能；材料，可以对应到做事情时所需要的有“输入”性质的资源上，它们会在人力、机器和方法的综合作用下，转化为“输出”；方法，指人与人互动、人使用机器、人加工材料、机器加工材料时所用到的流程、规范、策略等。

理解了“4M”的含义，我们一起来看看怎么用“4M管理法”确定问题的改善点。

简单讲，就是每个方面都问一下，有没有改善之处。具体操作如下：

人力：有没有关于人和组织的改善之处？
机器：有没有关于做工具和装置的改善之处？
材料：与没有关于材料和数据的改善之处？
方法：有没有关于方法和流程的改善之处？

按照上述操作，找出每个方面的改善之处，它们就可能是解决问题的起点。

比如前面提到的申请加薪问题，操作之后的一种可能结果如下：

人力：自己从被动工作变为主动工作。
机器：暂无改善点。
材料：积累工作成果。
方法：改变沟通方法，更好的展示工作成果。

综合来看，材料方面的问题和方法方面的问题，更为突出，改善后对加薪这件事帮助更大。

为了方便你用“4M管理法”锁定问题改善之处，分享一个4M工具，如下图所示。

工具的用法是这样的：将问题填写在中间，然后从4M的角度进行排查，逐一思考改善之处，将它们填入对应的格子内。

第三步：分析问题（问题树分解 + FAST图表法解析）

用“4M管理法”锁定问题改善之处后，接下来就要对改善点进行分析，寻找解决问题的办法。

“分析”看起来是一个词，实际上是两个动作，即“分解”和“解析”。

“分解”就是“拆散”，把一个问题先拆散。

“解析”就是把拆散的问题按照特定的新目的或标准重新排列的行为过程，相当于是一种新的“组合”。

用图表示，就是这样：

分解问题的方法有很多，比如WBS（工作分解结构）、PBS（项目分解结构）、OBS（组织分解结构），每一种方法，都可以将问题分解成一棵问题树（又称逻辑树、分解树等）。

你可以任意选择自己喜欢的方法，只要遵循下列三个原则：

MECE原则（不重叠、不遗漏）。
从抽象到具体，层级越深就越细化，执行落地可行性就越强。
从左到右。

在绘制问题树时，方向可以由上到下，也可以由左到右，我们选择由左到右这种风格。

下图是一棵关于“业务部门培训计划”的问题树，来自一家公司的培训部。

在分解问题的时候，我们脑子里一直盘旋着一个问题“怎么做”，所以每往下分解一层，得到的都是比上一层更具体的“问题”、“任务”或“行动”。（做过软件开发的伙伴对此应该非常熟悉，这个过程就是结构化程序设计方法中的“自顶向下、逐步求精”。）

类似这样的分解动作，你能得到什么样的问题树，与个人的经验和知识储备有非常大的关系，尤其是当我们在某一个领域特别熟悉，形成了“自动驾驶”的做事状态时，极其容易不假思索，把“习以为常”的方法列出来后就顺流而下继续分解。

这样做，很可能会遗漏一些方法（策略），还很可能列出一些惯用却可能效果不好的方法（比如上图中的问卷法）。

《拆解一切问题》中，提供了一个能够回避这种问题的解析方法——FAST图解法。我们来看一下原文。

整理技术的FAST图解法

FAST是功能分析系统技术（Function Analysis System Technique）的简称。为了有效地实现整理的功能，查尔斯开发了FAST图解法。

FAST图解法是功能的系统化解析，用以解析复杂的程序或组合；以逐层分析的方法决定计划所需要的功能。其具体步骤是：先进行功能分析，了解研究范围内的主要功能和次要功能；接着将该功能加以整理，了解其系统内部的关系。

请大家看本节结尾处的“商品陈列的FAST图表”，越往左侧，所要达成的目的层次就越高。最后，目的被统合起来，形成一个统一的核心目的。

其中，尤为重要的功能是关键性功能，它所表示的是问题的本质。也就是说，我们不能从各个行为的表面考虑如何解决问题，而应该从关键性功能的层面进行把握。

在前文的案例中，我们真正想要达成的目标并不是“提高店内的照明度”，而是“增加品牌与顾客的接触点”。可见，我们必须从关键性功能着手进行分析。因为只有按照这种思路分析问题，才能从固有观念、思维定式中摆脱，从而使思考和解决问题的活动变得更加富有创造性。

什么是关键性功能

对象的存在意义以及选择它的理由等级别的功能。在存在多个功能的情况下，必须保证各个功能是相对独立的。如果各个功能有不同侧重点（如目的、手段），那么更接近目的的功能便是关键性功能。

这几段原文中，有一个出现频率很高的词——“功能“。

那什么是功能呢？

功能指事物的功用，就是我们通常说的，这个事物是用来干什么的，有什么作用。详细点说，功能的具体内容包括意思、意图、目标、效果、目的、理由、性能、使命、作用等。

与功能对应的一个概念，是“形式”。形式是指事物的形状、结构、外观等。

比如眼镜，半框、无框、金属镜架、塑胶镜架、钛合金镜架，这些都是它的形式，而非功能，它的功能是“矫正视力”。

比如冰箱，单开门、双开门、十字对开门，这些都是它的形式，而非功能，它的功能是“冷藏食品，保质保鲜”。

比如轿车，红色、白色、燃油车、电动车、油电混合、SUV、超跑，这些都是形式，而非功能，轿车的功能是“代步、载人”。

逻辑上讲，我们买一个物品，一般都是为了它的功能。做一件事情，也是一样，为了功能。但现实中，很多事物会以某种形式为主要特点存在于我们身边，我们往往会“习以为常”的关注其形式，忽略其功能。比如我们会关注到窨井盖是“圆”的（形式），但很少去想它为什么是圆的，想要实现什么功能；又比如我们会关注到电灯泡是鸭梨状的，但很少去想做成鸭梨状是为了什么，想要实现什么功能。

FAST图解法关注“事物的功能”，从功能出发来解析问题，可以帮助我们跳出形式的陷阱，去思考形式背后的意义和本质，找到关键性功能，把握问题的本质，找到更好的解决方案。

那怎么用 FAST图解法来解析问题呢？具体分为三个步骤：

以前面的问题树为基础，从右往左追问“为什么做这件事”或“做这件事的目的是什么”，寻找“形式”背后的“功能”
以找到的功能为基础，思考“还有哪些做法可以实现这个功能”，补充进分解结构
持续往右推进，直到找到一个统一的核心目的

让我们基于前面给出来的业务部门培训计划来演示下FAST图解法怎么用。

先看问题树最右侧的事情——问卷调研，追问“为什么做问卷调研”。想想看，是为了“收集培训诉求”吗？初看是的，但你细想一下或者回顾一下以往问卷调研的结果，就会发现，业务部门通过问卷给出的诉求，五花八门，比如增强团队认同感和向心力，比如降低离职率，比如提升工作表现差的员工的工作效果等等，大部分都没办法通过培训来解决，这就导致问卷调研不解决问题，流于形式。进一步推敲，就会想到，问卷调研的真正目的是明确工作中通过培训能够解决的真实问题。

明确了问卷调研的功能是“明确培训能解决的真问题”，接下来就要思考“还有哪些做法可以实现这个功能”，那你可能就会想到“关键行为分析”、“一对一访谈”等新的方法。

补充完针对“明确培训能解决的真问题”的做法后，接着往右推进，追问“明确培训能解决的真问题的目的是什么”。仅仅是为了做一份普普通通的“业务部门培训计划”吗？不是的，是为了产出一份能落地的“业务部门培训计划”，即“业务部门培训落地计划”。从这个功能出发再思考，就会发现，要想培训计划能落地，必须得有业务部门支持，那在“计划创建”这部分，就要“明确各部门分工”。

经过这样的FAST分析，关于业务部门培训的问题树就变成了下面这个样子。

相信经过上面的演示，你能更好的理解FAST图解法了。《拆解一切问题》中，有一个更完整的示例，可以帮助你进一步理解FAST图解法。

从这个图例中也可以看出，分析问题的典型过程：选择一种分解结构，从左到右，不断追问“如何做”，将问题分解成一棵问题树；然后运用FAST图解法，从右往左，不断追问“为何做”，找到“功能”，根据“功能”，向问题树上补充或调整更落地的做法。

第四步：用奥斯本检核表法收集灵感

经过第三步，用问题树和FAST图解法对问题做了正推和反推后，我们往往对问题本质有了更深入的理解，也找到了不少“行动”、“任务”或“做法”，看起来可以整理出解决方案了。但实际情况是，我们往往会发现某种做法不在我们的掌控范围内，行不通。

一位辗转在各个小微公司做开发的程序员 C，三十多岁时，想要到大平台谋求稳定，数百份简历投出去如同石沉大海。经过分析后，C 找到一个做法——“优化简历突出优势”。这种做法对在某个技术栈上有深厚积累、在同技术人群中具备竞争优势的程序员来讲，是可行的，但对 C 来讲却是不可行的，因为他经历的项目小而不难，用到的技术杂而不精，既无业务积累，又无技术优势。

这个时候，如果 C 没有找到别的做法，就会卡在那里。

为了避免这种情况，我们就需要在第三步的基础上，想办法激发灵感，收集更多方案。

《拆解一切问题》中提供了很多方法，其中简便易行的方法是“奥斯本检核表法”。如下图所示。