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