作者：人月神话，新浪博客同名
简介：长期从事IT信息化建设和管理工作，多年来对思维框架和个人管理有兴趣和研究
今天我要讲的是问题分析和解决的逻辑。前面讲思维框架的时候，我已经说过学习方法模式、问题分析与解决、事物认知都是整体思维框架的子内容。我专门写了一篇学习方法和模式的文章，今天重点讲问题分析和解决逻辑。
引言-问题的分类
人的生命本质是不断面对、分析和解决问题的过程。这个解答怎么写，高考怎么选几所学校？小到今天中午应该吃什么，出门应该穿什么衣服。
那么，我们有没有考虑过问题应该如何分类？
在研究了大量的问题或题型后，最终总结出四种呈现问题的方式。
What类：是什么？比如我应该如何看待某个事物。,How类：如何做？比如我应该如何写一篇科研论文？,Which类：如何选择？比如收到了三个Offer我应该如何选择？和Where类：哪里出问题？典型的就是出现了故障，异常偏差后究竟问题点在哪里？可以从以上四类中看出。
对于什么类是典型的事物认知类，需要的是理解事物的认知模型；How class是方法论类，侧重于根据不同的领域和目标给出可行的方法论和最佳实践；对于哪一类是我们常说的决策分析，从最简单的经验决策到结构化决策，再到高级的量化决策；对于Where类来说，简单来说就是事物运行状态的偏差或异常，需要快速找到对应的点并解决。
从普遍适用的方法论来看，问题解决就是一个问题定义，问题分析，问题解决的三大阶段过程.这对应于四种不同类型的问题。然而，我们应该注意的是，不同类型的问题在问题分析和解决方案上必然有所不同。
正是因为这个原因，我们可以看到，完整的解题逻辑必须上升到思维框架的逻辑层面。
说到解决问题，估计大部分人都会谈到麦肯锡的问题分析和解决七步法。
当我把上面的分类梳理清楚的时候，我们可以看到麦肯锡的问题解决方法是属于How类问题的解决,说的是，在咨询的时候，一个咨询公司应该如何对客户提出的一个问题形成一个完整的解决方案来支持目标和问题的解决。
今天我重点讲的是Where类，也就是我们常说的狭义问题分析与解决。即当出现异常和故障时，如何找到问题的根源并解决？
也是因为这个原因，如果只学习麦肯锡的解题方法，可能还是解决不了问题。
麦肯锡问题解决七步法
">还是先回顾下麦肯锡的问题解决七步法。
在前面谈到麦肯锡作为一家咨询公司，给出了很多协助顾问进行结构化思维，问题分析解决，解决方案写作和呈现的方法论。比如给出结构化思维和框架写作和呈现原则的《金字塔原理》一书的作者芭芭拉明托本身也是麦肯锡的咨询顾问。
了解了这点，我们才清楚麦肯锡的问题解决七步法的适用背景，即：
面对客户的一个目标或需求的时候，如何形成一个完整的解决方案去解决客户问题。
我们可以举例来说明一些常见场景。
- 如何将当前的产品交付周期从50天缩短到30天以内？
- 如何编写一个售前技术方案文档？
- 如何解决当前业务系统性能缓慢的问题？
所有的如何你都可以看到，最终形成的是一个完整的解决方案，这个完整的解决方案包括了多个解决措施，同时这些解决措施最终融合协同形成一个完整有效的解决方案。
因此在这里，我们重新构图对麦肯锡核心问题解决逻辑做一个说明：
第一阶段：问题分解和基础素材对应
在这个阶段重点就是将目标分解为子问题，然后将论据映射到对应的子问题上。
在这个过程中你已有知识库积累可能不足够，这个不要紧，那么需要你进一步学习，进一步上网搜索资料，对资料进行分析，同时将没有的素材论据全部要清理掉。
最后留下的就是能够完全支撑目标的有用论据材料。
第二阶段：粗粒度对应，进一步排序和整合
到了第二阶段做什么？简单来说就是要做抽象和归纳的事情了，即进一步对你的材料进行整合和归纳，形成大块的解决模块，然后将解决模块对应到子问题域。
在解决模块形成过程中，我们还需要对素材论据进行优先级排序，确定材料的重要性，哪些在最终呈现的时候应该放在前面，哪些应该放在后面等。
第三阶段：进一步归纳并从归纳到演绎反转
前面三个论据形成了，但是仍然比较散。
因此我们需要进一步进行归纳，将其形成一个完整的整体，不论是静态的金字塔结构，还是动态的流程结构都需要看到，你最终的解决方案中各模块必须首先是一个整体，不能散。
其次从归纳反转到延期，给出完整解决方案，然后再来进一步演绎呈现你给出的解决方案中的各个解决模块是足够的支撑各个子问题的解决的。
通过各个解决方案模块通过集成和联动最终完成大目标的解决。
整体思路有无进一步案例说明？
请参考我头条号文章《思维究竟是什么-思维的逻辑和模式匹配》，这里列举了一个制作校园信息化解决方案的完整问题分析解决思路，可以参考。
以上即是对麦肯锡问题解决七步法核心的一个说明。
再次强调下我写的关于思维，问题和事物认知的文章都是个人多年实践的经验总结，而不是说拼凑已有的理论和书籍资料。如果有用可以点赞或收藏。
下面重点还是回到我们说的Where类问题的分析解决方法说明和论述上面。
问题概述和问题定义
在《你的灯亮着吗》这本书里面对问题有个明确简单的定义，具体如下：
问题就是事物的现状和你期望的结果之间的差距。所以从这个层面来看问题的解决途径是很明朗的，一个是降低自己的期望，一个是改变事物的现状。
我们在做问题的根源分析的时候常使用鱼骨图从人，机，料，法，环五个方面进行全面的分析。在问题定义上面我们可以整合为三大主要内容，即问题的涉及的人，产生问题的环境(空间和时间)，产生问题的过程(方法，步骤，工具，操作事物)。如果这三方面都搞清楚了就有了一个明确的问题定义，有了明确的问题定义，后期就有了问题分析的切入点。我们就可以很好的回答如下问题：
- 是谁的问题?问题的涉众是谁?他对事物的期望是如何的?
- 事物的现状是如何的?具体的差距是否是清楚的?
- 导致问题产生的流程和步骤是如何的?中间使用了什么方法或工具?
- 问题发生的环境是如何的?问题产生是否跟环境有关系?
为啥我们需要把问题是什么理清楚，原因就是当真正出现问题的时候往往都是事物内部发生了变化，或者说是事物基于的外在环境出现了变化。导致了事物表现的状态出现了变化。比如我们说我们的IT应用出现了故障或问题，简单来说很简单就是部署包依托的基础设施环境出现了变化，或者就是部署包本身重新构建过而导致内部出现了变化。
那么如何完成一个问题定义？
在《提问的智慧》里面，给出了如何完整的描述一个问题。
- 自己遇到问题的过程和具体步骤
- 自己遇到问题的特定环境和场景
- 如果是异常或错误要有详细的描述信息，包括文字和图片。
- 要自己去把问题的边界条件搞清楚，方便他人帮你解决问题。
愚蠢问题
救命啊！我的膝上机不能正常显示了！
聪明问题
XFree86 4.1下鼠标光标变形(现象)，Fooware MV1005的显示芯片。 (特定环境和条件)
HP1200无法正常打印，错误提示信息是***，我的操作系统是XP+SP2，驱动是安装的打印机光盘带的标准驱动，电缆连接正常，重新启动机器也不行。
从上面可以看到任何一个完整的问题定义和描述都必须包括两个关键内容，第一个就是问题产生的周围环境和关键输入，其次就是你产生问题的详细操作步骤是如何的。
问题定义清楚，问题就解决了一半
帮助他人解决问题的时候，更多的往往是在帮助对方完成问题的完整定义。
今天，接到一个用户的电话，反馈在录入出差申请后提交的时候报错。在接到电话后我详细询问了报错的异常信息是什么? 在用户反馈异常信息后，根据已有的知识库这个很可能是浏览器版本低导致的，因此我尝试询问了下客户浏览器版本，客户反馈是IE8版本，最终我基本确认是版本过低导致。因此建议客户升级浏览器版本后问题解决。
上面也是一个典型的例子，即问题的定义完整搞清楚后，往往问题自然就解决了。所以当我们自己面对问题的时候，首先需要的不是马上求助，而是自己把问题描述和定义清楚。包括问题周围的环境，问题产生的详细操作步骤等。
务必不要将解决方案转为问题
在软件需求培训里面，我们经常会说到需求和问题定义的时候，务必不要把解决方案转变为问题。否则将导致帮助你解决问题的人误入歧途。
比如我们在耕田的时候，发现牛耕田很慢，这个时候我们本身的问题是如何提升耕田效率。但是我们很多时候提出的问题却是还有其它什么动物耕田比牛快。这种就是典型的将解决方案变成问题，这样反而是对协助你解决问题的人造成误导。因为最佳的解决方案是直接上自动耕田机，而不是去找寻耕田效率更高的某种动物。
问题分析
对于问题分析和解决我们经常会一起说，那么问题分析和解决的边界究竟在哪里？相信很多人都没有仔细去思考过这个问题，今天在这里我重新再说明下，即：
问题分析是找出引起问题原因的最可能假设并按优先级排序。而问题解决是按优先级对各个假设进行验证，以最终确认究竟是哪个原因导致了问题。
结构化分析和非结构化分析
如何找出问题根源并进行优先级排序？这个就涉及到结构化问题分析和非结构化问题分析两个方法。
- 结构化：对所有导致问题原因进行穷尽，然后逐个验证，可能优先级排序都给不出
- 非机构化：根据已有的经验直接提出最可能假设
简单来说结构化就是穷举，而非结构化则是直接最优假设。从这个我们就可以很明显的看到，别人为何比你解决问题快，因为别人直接就提出最可能假设并进行验证，而你自己还在逐个的排查和穷尽。
再举个例子，比如当前业务系统某个查询功能查询很慢，有经验的人之间提出最可能假设是数据访问层对应的SQL语句慢的原因导致，然后直接在后台运行SQL验证，最终确认是SQL语句效率导致，然后去解决和优化SQL问题解决。
问题分析关键-分解+排序
问题分析的目的是找到问题的关键影响因素，这就是问题分析的本质。
问题分析中两个关键点，一个是问题分解，一个是排序。
要做到这一点，我们常见的问题分析首先要做的就是基于问题的初步定义，对问题进行进一步的分解，这个分解可以是目标本身的分解，也可以是问题可能产生原因的分解。
比如当前经营业绩不好，这个问题已经转化为需要提升公司利润这个目标，那么就可以基于这目标进行分解；再比如当前IT系统运行缓慢，性能有问题，引起问题的原因可能是硬件，也可能是软件，对于软件部分又可能是数据库或中间件，也可能是我们自己的程序代码，这种分解方式就是基于问题本身的可能原因分解。
分解中用的模型都是树模型，包括逻辑树，问题树，风险决策树，思维导图，鱼骨图等方法归根到底都是树模型的应用。树模型更好的解释了所有的分解都围绕一个终极目标，而不是多个目标，多个目标往往仅仅是终极目标的子目标。
对于鱼骨图也是分解，但是鱼骨图更多是用于问题的分解，体现因果关系，同时又给出根据一般的法则即从人，机，料，法，环境五个方面进行分解。所以鱼骨图一般没有包括对子目标的分解。
对于决策树也是分解，当时更多的是对不同决策的分解，而我们在思考中一般不适合过渡跳跃，直接由问题转移到决策。因此分解没有明显限制的还是逻辑树，在前面几层可以是子目标的分解，在后面几层可以是控制变量的分解。
分解的目的仍然是找到所有可能的问题影响因素或控制变量。而排序的目的则是确定关键的影响因素，或者根据2/8原则确定的那20%的最可能影响因素。
在问题分析阶段的排序重点是关键影响因素的确定，注意在决策阶段还会涉及到决策过程中的排序，但是在分析阶段重点仍然还是对问题本身的关键潜在原因和可能影响点的排序。
举例来说对于IT系统的性能问题分析，经过初步诊断，认为问题产生原因可能性最大的数据库本身性能出问题，其次是程序代码出问题。经过这种优先级排序后才能够确定后续解决问题的策略和次序。
排序之目的最终就是形成优先级列表，为决策服务。
由分解后进行排序转化出来的决策往往则是一种结构化的决策方法。虽然很多时候我们往往并不会按部就班的这样一步步做，但是这确是一种科学决策和思考方法。
如何才能够真正做好优先级的排序，其中本质往往只有两种：
- 基于我们的历史经验积累，包括头脑风暴中各个专家经验的积累。
- 基于我们初步的问题诊断，在这个过程中已经做了初步尝试和假设的验证，对非关键点排除
正因为如此，你可以看到在问题分析中我们仍然会开展各种实践活动，目的是对问题进行初步诊断，找到真正的问题关键影响因素，并把非关键的影响点排除掉或降低其优先级。而问题分析最终形成的关键影响因素的优先级排序则是我们进入到问题解决阶段的关键输入。
对问题分析和定位过程的描述
首先再回顾下对问题的定义。问题即期望值和实际值之间的差距，有差距就产生了问题。而期望值和实际值本身都是输出，任何问题的产生往往都是有多个条件或信息作为输入，然后经过机器或大脑多步骤加工处理后形成的一个实际结果和期望结果的比较。
如果遵从这个简单的描述，那么问题的产生只有两个原因：
- 输入的某个X发生了错误或误差
- 加工中的多个步骤或某个步骤出现的错误，导致最终输出没有得到我们期望的值。
还是拿考试来举例，如果我们某一道题目做错了，那么只可能是两个原因，一个是我们对于已知输入条件看漏了或理解错了，要么是我们在进行计算的时候某个分解的步骤出现了计算错误，最终导致了题目做错了。
我们进一步对上面逻辑举例说明，比如一个软件应用出现Bug的场景，如下图：
可以看到看到要分析和定位Bug为何困难？
引入问题既可能是我们的输入出现错误，我们面对的软硬件环境运行状态有问题，也可能是我们实际程序处理构成出现问题。即使你定位到程序处理问题，那么还可能是逻辑层，数据访问层或数据库多个点导致的问题。
正是由于这个原因，我们对问题分析的核心思路为
- 静态分析：对问题产生的环境，背景，人等因素分析后列出影响因子
- 动态分析：对问题产生的过程进行动态分析后，列出可能的影响因子
- 优先级排序：根据已有的历史经验对影响因子进行判别并给出优先级排序
问题解决
把问题分析搞清楚后，我们再来看下问题解决。
问题分析的输出是已经进行了优先级排序的问题根源分析列表信息，对于没有历史经验储备的人可能仅仅是问题原因列表无法进行优先级排序。
那么拿到这个输入后，问题解决究竟要做什么？
简单来说，问题解决就是对这些问题原因点进行验证和确认的过程。即：
- 制定详细的验证方案和验证计划
- 执行验证计划，并对结果输出进行观察和确认，看是否解决了问题。
当你看到这里的时候，可能会感觉到问题的解决过程实际上很简单。确认问题解决没有想象的复杂，真正问题解决的难点从来都不在于对假设进行验证和确认。
而在于当我们解决当前问题的时候又引入了新的问题。
小张反馈当前我们的CRM系统，客户信息查询速度缓慢，经过假设分析最终判断最可能是SQL查询语句的问题。经过问题解决验证，确认了SQL语句问题。因此我们对SQL语句进行添加索引优化，但是发现虽然查询性能解决了，却导致了客户信息录入的时候新的性能问题。
以上是我们最常见的一个情况，即当我们对某一个影响因素进行调整的时候引入了新的问题点。当然对于问题解决的复杂度，还存在如下两个场景场景。
其一：单问题分解为了多个影响因素
比如我们说当前公司的经营遇到了瓶颈无法突破，然后导致这个问题可能有多方面的影响因素和原因，我们要解决这个问题本身也是需要从市场营销，产品研发，团队和激励机制等多个方面下功夫才能够真正解决。
即开始我们看到的单问题，但是变成了多因子影响，最终问题的解决也是多个举措同时进行。
即在问题分析的时候需要分析出引发问题的多方面原因和影响因子，并进行相应的优先级分析和排序。而我们在决策的时候同样也变复杂，即不是解决单个影响因子，而是需要解决多个影响因子。
多个举措并行往往影响我们对最终效果的分析评判。因为这是一个组合解决措施，最终得到的是一个整体改善效果，实际上如果我们要去评估单个影响因素的功效可能会比较困难。
其二：本身就是面对的一个事物群或问题群
比如我们说当前工厂生产的零部件的次品率很高，这是一个问题，那么这个次品率本身就是对所有零件集合的一个检查和计算得到的一个结果，即面对的是一个事物群出现的汇总问题。
当面对的是一个事物群或问题群的时候你可以看到，我们同样是分析出很多影响因素，但是你会发现导致次品率偏低的99%的原因可能都是原材料本身质量有问题。
那么实际我们最终可能只去解决原材料质量问题，在这个问题解决后，我们的产品质量控制已经就能够完全满足我们的要求。即面对问题群的时候，你可能只解决单影响因素，但是最终让问题控制到我们期望的一个范围值内。
问题解决-决策和行动
问题解决本质就是基于问题的关键影响因素（有可能1个，有可能多个；有可能独立，有可能相互影响），制定详细的实施计划和行动步骤，去将问题的根源和本质原因解决掉，并进一步观察和验证问题是否已经解决了？
如果还没有解决再进行循环迭代，直到问题真正解决为止的一个过程。
把这个想清楚后，对于问题解决也包含两个关键步骤，一个是决策，一个是行动。决策的目的是基于关键影响因素的解决从多个备选方案中确定最优方案，行动则是针对最优方案制订详细的行动计划。
对于决策，本身又分为结构化决策和非结构化决策。
结构化决策是指对某一决策过程的环境及规则，能用确定的模型或语言描述，以适当的算法产生决策方案，并能从多种方案中选择最优解的决策；而非结构化决策，是指决策过程复杂，不可能用确定的模型和语言来描述其决策过程，更无所谓最优解的决策。
决策要注意的就是仍然是多维度评估和排序，但是排序的目的是确定行动方案，在行动方案确定中就不能只是考虑影响因子本身，还需要考虑实施难度，投入工作量和成本，实施周期等多方面的内容。正是由于这个原因，最终的决策往往并不一定是解决关键影响点，而是变通为解决次关键影响点等。
锤子和钉子-跳出固定思维模式
在刘未鹏的《暗时间》这本书里面提到过，如果你有的是一把锤子，那么所有东西看起来都像钉子。心中有锤，就容易被奴役，必须要时刻考虑我们面对的真正问题是什么？而不是仅仅我有锤子那么就只能敲钉子。但是工具又是基础，没有工具又万万不可以。
我们很多时候倾向于在既有的框架约束下去解决问题，而且在很多时候很难发现这种约束的存在。那么我们需要的是跳出盒子和寻求突破。普通人遵守规则，牛人无视规则，伟人创造规则。
思维本身无定势，即使很多时候给你再好的方法论你也无法解决问题。
解决问题能力只有不断实践，不断碰壁中自我总结出来的。由于是自我实践的积累，所有是最适合你自己的方法。即如果你遇到的一个钉子，那么你看所有东西都可能成为锤子。知识的积累，如何在面对问题的时候快速匹配并为自己所用才是关键。
简单的事情简单处理，但是简单的事情通过类别和抽象，会得出归纳性知识，即简单的事情复杂处理。复杂的事情简单处理，很多时候我们没有对复杂事物进行分解，而通过搜索进行了粗粒度的匹配。
但是复杂的事情可以复杂处理，复杂事情可以进行分类，分解，细化和演绎，可以提出假设和验证，可以分而治之，可以进行细粒度的匹配，复杂的事情复杂处理积累的才是真正我们需要的思考的逻辑。
对于问题解决部分稍显仓促，后续还会举例来进一步说明。更多后续思维，问题，事物认知的文章请先关注我，会不定期进行分享。
作者：人月神话，新浪博客同名
简介：长期从事IT信息化建设和管理工作，对思维框架和个人管理多年兴趣和研究
