大家好，我是Z哥。
今天我们聊的话题对大多数人来说应该都算是一个“痛点”，就是怎么提高自己解决问题的能力。
我们的工作中，每天会遇到大大小小的很多问题。其中有些是之前从未遇到过的问题，这对很多人来说就会很棘手，不知道该怎么解决，可能吭呲吭呲折腾好几天都不一定能搞定。
但是身边往往也一定会存在这么一小部分人，好像无论什么问题，到他们那就能够顺利地解决。
难道他们真的只是“看得多，懂得更多”而已吗？
我根据我身边所接触的人群来看，还真不是。
根本原因我认为是他们有自己的一套成体系的思考策略。表现出来的“懂得更多”而是基于这些策略经过时间的打磨后产生的结果，而不是原因。
之前看过一个淘宝技术团队里的故事。
当时某个小组遇到一个问题，组内的几位成员搞了好几天没搞定。没办法，不得不跨部门去请教多隆大神，多隆5分钟后回复了一个解决方案，他们试了下果真把问题解决了。
所以你看，解决问题的能力高低可以差距那么大，远远超过所谓的10倍程序员的概念。而这其中能不能掌握正确的思路至关重要，但是我们很多人往往是“脚踩西瓜皮”，滑到哪算哪。
很多人平时遇到问题，最习以为常的就是四连招，「打开百度，复制，黏贴，点击搜索」。
然后就扫一眼标题去点开觉得靠谱的网页去看。
这样解决问题的方式从形态上大致是下面的这样子。
这其实是一种最理想的状态，从「问题」直接对应到「解决方案」。但现实是，建立这个对应关系其实没那么容易。就像找对象，你想在忙忙人海中找到你命中注定的另一半，还不想刻意去找，TA就出现在你眼前的概率有多少？
我们的人性深处就是喜欢「低投入高收益」的事情。希望正好有人和我遇到一样的问题，并且还解决了，同时还花时间整理成文发布在了网上。然后，自己可以顺手摘下这个果实，解决眼前的问题。
但现实往往是，
没人和我遇到一样的问题哎。
这个问题和我的有点像，但是又不完全一样，没法用。
这个人和我遇到了一样的问题哎，但是下面没人回复怎么解决的，扎心……
要摆脱这种状态，就得培养自己解决问题的思路体系。
我们可以这样来考虑。
把解决问题的过程想象成是一个“漏斗”，逐渐收敛，最终定位到某几个具体的解决方案。
这个“漏斗”分为几个阶段，场景分析、定义问题、建立假设、验证。
每个人大脑中所沉淀下来的「经验」，其实就是将经过这个漏斗走过一遍的路线图保存在了你的大脑里，然后才达到了“开箱即用”的状态。
/01 场景分析 when where/
大家都知道，很多问题其实背后的本质是一样的，只是换了一个外壳出现在你的面前。
比如，当你看到一个程序内存占用持续上升，和从系统日志中看到这个程序有内存溢出的错误日志，你很容易得到它们背后的原因都是一样的，某些对象使用完后没有释放资源。
但是，当你在实际解决一个问题的时候，还是不能把问题所在的场景给忽略了。因为这里面埋藏着导致这个问题的“变量”。
这个问题是在一个什么场景下发生的？
这个场景的完整过程是怎样的？
只有搞清楚了所处场景，你才能顺藤摸瓜找到问题的根源。否则你的系统化思维也培养不起来，而且系统化思维对于做接下去的第二点也很重要。
/02 定义问题 what/
当你通过百度搜索一个问题的时候，输入的内容越多，得到的结果越精确，对你价值越大，但是结果的数量却越少。与之相反的是，输入的内容越少，得到的结果越泛，但是数量越多。
当第一种方式不管用的情况下，想要得到更多有价值的信息，前提条件就是要我们提炼出合理的关键字。
因此，能否把一个问题定义的够清楚，触达问题的本质显得格外重要。
其实世上本无“问题”，“问题”源于现状与期望之间的「差距」。
当你觉得现状符合你的预期的时候，哪还有什么问题啊。比如，我们做程序员的小伙伴预期是什么？永远没有bug！那么只要出现了bug，就不符合预期，这就是“问题”：D。
回到这个「差距」上，要搞清楚每个问题的「差距」，你就得对这个问题的相关信息有充分的认识，而不是以偏概全。
比如，当你看到一个程序cpu跑得很高，不能简单将其定性为cpu资源分配太小，加大就行了。而要分析看看，对比上周、上月的同期情况如何？如果对比下来差异很大，那么至少这个「cpu需要加大到XX」这个期望就是错误的。
期望错了，问题的定义也就错了。自然后面去解决它的道路也是错的。
所以，这第二个环节就是「搞清楚这到底是一件什么事？」
/03 建立假设 why/
这是一个人「解决」问题能力高低的关键。「想得到」才谈得上「去解决」。
很多人在解决问题的时候容易停留在表面，这会导致解决问题的方式指标不治本，后续还会再反复出现。
比如，某个程序发起的请求出现超时，发现超时时间的配置是5秒。首当其冲进入大脑的解决方案是，改长啊，改成10秒。
上面提到的「程序cpu跑得很高」的例子也是这样。
这就是典型的还没找到原因，就去解决问题的例子。虽然短期内，从表象上看着问题是解决了，但是根本原因并没有找到，反而是被掩盖掉了。
在不久的将来必定会重蹈覆辙，再次暴露问题。
怎么办呢？建立假设。
这个方法本质上也是易经中的「象、数、理」概念的体现。
任何「现象」的背后一定会存在「数据」的变化，而之所以产生这个变化一定有它的「道理」。
其实简单来说就是不断地追问why？why？why？将当前场景中导致这个问题的“变量”尽可能多的挖掘出来。这些变量最终会是一个「树形」的结构，因为你顺带将它们分解好了。
/04 验证 how/
Ok，通过第三步将影响这个问题的众多变量给提炼出来了，那么可以开始逐步验证了。如果这个变量……（这样），会……（怎么样）。
验证假设的时候，需要我们带着批判性思维来质疑自己刚才提出的假设。当然这个有点难，需要练习。
有时候也可以选择动手实践，比如像我们做程序员的，可以实际去改一下代码试试看。只是这会比较费时间一些。
好了，思路捋清楚了，那么具体我们可以怎么做呢？
/01 把思考的过程写下来，画出来/
这其实在倒逼自己转换成“漏斗思维”，而不是想寻求一步到位的结果。
比如，在纸上将前面提到的第一点「场景分析」通过流程图的形式画出来，这样你对整个过程能有更直观的认识，也能更准确的定义问题。（字丑，请见谅……）
像第三点的建立假设也可以在纸上画出来。比如，画个鱼骨图。
/02 帮助解决之后要追问/
很多人找人帮忙解决掉一个问题之后恍然大悟，哦原来是这样子啊。然后就高高兴兴的回去按照对方说的去改了。
只是这样的话，下次遇到类似的问题还是不会。对方身上解决问题的能力一丁点都没学到。
我建议是，当别人告诉你解决方法后，不要停留在结果上。简单多问问，
你是如何想到这里的？
你是如何搜索到解决方法的？
你是根据问题什么输入做出判断的？
这种发问相当重要，通过这种发问其实你是在问别人解决问题的思考方式。别人的思考方式再和你自己的一印证，再问问自己我当时为什么没有想到那个点上呢？我下次再遇到类似问题我应该多考虑点什么呢？
长期以往，你的解决问题的能力会显著超过其他人，并且会大大加强「建立假设」的能力，因为你不是一个人在“战斗”，知识的广度和深度积累更快。
/03 了解上下游/
关于上下游的了解，不用多，只要上一级和下一级就够了。比如，遇到一个数据库的问题，可以了解一下，存储或者操作系统相关的知识。遇到某个模块B的问题，可以了解一下它的上游模块A是做什么的？对这个业务是怎么处理的？下游模块C是做什么的？对这个业务是怎么处理的？
这间接也是在为强化漏斗第三环的能力。
/04 关键字也需要迭代/
其实想用好搜索引擎，对我们大部分人来说，你不用去研究搜索引擎的原理，提炼好关键字就够了。
关键字的选择一定要屏蔽个性化的内容，比如源代码行数，你自己的方法命名等等。
其次找最有价值的关键字，比如异常的类型、某个系统原生方法或者系统内置变量等等。
关键字上再配合你出现问题的软硬件环境，如java环境、版本号等等。
在搜索过程中许多网页虽然没有明确提供解决答案，但是会提供有价值的补充关键字。所以，你可以借此来迭代你搜索时键入的关键字，以此找到更深或者更广的内容。
其实我们平时所面对的「问题」，存在两种类型。一种是现实中的“异常”，也就是「我知道应该怎么样，但实际不是这样」；另一种是现实中的“痛点”，「我知道这里不好，但是不知道该怎么变得更好」。前者面向当下，后者面向未来，我们这里聊的主要是第一种。
好了，我们总结一下。
这篇呢，Z哥先和你强调了解决问题的能力在不同的人之间可以拉开很大的差距，所以我们要重视培养自己解决问题的能力。
其次，列举了一些我们解决问题能力还不强时会普遍出现的情况，让你判断自己当前所处的阶段做参考。
然后，我建议你通过“四层漏斗模型”「场景分析、定义问题、建立假设、验证」来作为解决问题的思路。
最后分享了4个实践技巧，后面有想到再补充。也欢迎大家在留言区分享你的技巧。
希望本文对你有所启发。愿大家都能成为10倍高效的问题解决者：D
推荐阅读：
程序员与「中台」的爱恨交错
认知的高度 = 人生的高度
