毕业10年才懂，解决问题的能力原来这么重要
The following article comes from 阿里技术 Author 张荣华
从学生开始老师就教导我们什么是问题？如何找出标准答案。然而，经过十几年的学习，大多数人依然没有理解问题的本质。正确定义问题是成功的开始，更是成功架构师的必要条件。
图片来自 Pexels
今天，阿里资深技术专家张荣华从问题的本质入手，用“升层思维”解决问题，告诉我们创新的核心，给出高效工作的途径。
问题的本质
我也在很多场合问过一个问题：什么是问题？虽然我们天天挂在嘴边，但是没有人能够给出较为合理的答复。之前我也没有想过这个问题，很多人对问题的理解还不太一样。
一部分人认为问题就是方案中的难点，一部分认为问题是现实和目标的差距，这些解读我觉得都还不够精确，我在尝试定义无果之后查询了大量的资料，终于找到了一个比较合理的定义。
目前我认为毛主席的解释是比较合理的：“问题就是事物的矛盾。哪里有没有解决的矛盾，哪里就有问题。”
而主管们经常问到：
你要解决的问题是什么？
这里的问题定义是什么？
其实潜台词在问，这里事物间的矛盾是什么（已经发生的矛盾，将来会发生的矛盾，可能潜在会发生的矛盾），这个矛盾如果不早点解决，可能会激化，带来很严重的后果。
其他例子：
中国人日益增加的财富和国产商品的低劣品质就存在矛盾，这个矛盾就是个问题（已经发生的矛盾）。所以我们要提倡中国质造。
如何利用新技术，更快更准地帮助消费者找到其最需要的商品，提升幸福感（将来会发生的矛盾，在矛盾发生之前，我们应该将之解决）。
上面几个问题的定义都是社会级问题，而且都是公司层面在解决的问题，在我们技术同学的手头的工作中应该也存在各种问题。
准确定义问题是成功的开始
这么多年来笔者 Review 过很多技术方案，而且也经历混沌混乱的模块设计，大部分糟糕的设计基本上是摸不清楚自己到底要解决什么问题，总是觉得这个问题我要解决，那个问题我也要解决，甚至不是问题的问题我也要解决。
然后设计出了一个能解决所有“问题”的方案。但是实际情况是有些问题根本不是问题，有些问题确实是问题但是却又不是核心问题，有些问题是核心问题，但是又不是当下最核心的问题。
我相信类似的方案有很多在 Review 的时候被挡下了，但是还有很多应该已经上线了。
如何尽可能减少这方面的损失？那就是要开始阶段就要准确的定义问题，这也是这么多思想家推崇问题定义的原因。
“A problem well-defined is a problem half solved.”
爱因斯坦如是说道：
“提出一个问题往往比解决一个问题更重要，因为解决问题也许仅能是一个数学上或实验室上的技能而已。而提出新的问题、新的可能性，从新的角度去看旧的问题，都需要有创造性的想象力，而且标志着科学的真正进步。”
这里应该是一个三维的图形，有时间维度，主次要维度，紧急不紧急维度。
对这个主要次要，紧急不紧急是不是眼熟，没错，在很多如何高效工作上都有类似的方法，把要做的事情分成重要紧急，重要不紧急，不重要紧急，不重要不紧急。
其实我不太认同将事情划分成重要或者不重要，紧急或者不紧急，我建议大家将自己手头要解决的问题划分为重要或者不重要，紧急或者不紧急。
因为事情只是一种方案或者手段，区分问题本身的重要度和紧急度才是思考的源头（包含问题的升层思考）。
要填满这张表格必须结合对业务的理解，和对产品的理解，尤其是业务理解，如果没有业务理解，很难准确地刻画问题。
可是什么叫问题的重要度呢？我也思考了很久，终于得出了一些较为自洽的解释。
问题的严重程度
问题严重程度的定义
当我们明确地定义问题之后，我们就要设定目标来解决这个问题，但是现状是残酷的，我们目标和现状之间可能存在巨大的落差。
有些书或者文章里这样定义问题：问题=目标-现状，这个定义是模糊的，因为目标-现状和这张图一样，往往表示的是落差。
落差往往让人想起差距，用差距来形容问题是含糊不清的，很难让人一下子就明白问题的本质。
我们拿性能问题举例，我们的目标是 RT<1 秒的请求占比大于 98%，当前的现状是 RT<1 秒的请求占比为 80%，那么这里的差距就是 98%-80%=18%。
这 18% 就是问题严重的程度，但是这 18% 绝对不是问题本身，这 18% 是问题的严重程度。
衡量问题严重程度的挑战
要区分问题的严重程度有两个挑战：
现状：对现状有准确的认知，比如该例中某系统 RT<1 秒的请求占比为 80%。
期待（目标）：问题解决后的状态有个清晰的表述，比如该例中某系统 RT<1 秒的请求占比大于 98%。
对于数值型的现状，我们要搞清楚这个数值是容易的，只要将你的目标值减去现状的值就可以得到问题的严重程度了。
对于难以量化的现状，那要摸清楚问题的严重程度，可能需要一些案例，需要一些数据统计。
比如说架构现在不合理是个问题，这个问题严重到什么程度，那可以计算一下最近半年的需求在实现的过程中，花费了多少工时，如果架构合理的情况下哪些工时是可以节省掉的。
或者现在的架构上迭代需求故障和 Bug 的情况是怎么样的，评估一下重构之后故障和 Bug 率会降低到多少。
只要现状和目标有一个没清晰，那我们就很难判断出问题的严重程度在哪里。
FBI warning：如果你不能确定问题的严重程度（现在的或者将来的），不要贸然行动去沉迷于方案的设计。
而不定义问题，不评估问题的严重程度，往往是很多工程师的常见思维习惯，大家可以对号入座。
问题的分类
基本上看这三类问题的字面意思就可以知道这三类问题的区别了：
恢复原状型：原本就应该是这样的，但是现在不是，比如说原本轮胎就应该是充满气的，但是现在扎了个钉子，所以我们要让轮胎恢复原状，这就属于恢复原状型问题。
风险防范型：问题可能发生，也可能不会发生，但是一旦发生，带来的危害是巨大的，所以我们不得不费大量的精力来防止这样潜在的问题发生。在安全和可用性方面，很多工作都是属于风险防范型。
这里的尴尬之处是做了对数字指标可能没什么提升，但是不做可能会发生特别严重的事故，带来极其负面的影响。
追求理想型：知道未来会发生的矛盾是什么，提前解决未来必然会发生的矛盾。
如果将这三个问题映射到架构上，那么应该是如下的描述：
①解决架构上未来会遇到的问题：已经明确预知到未来的业务问题，并且可以转换为未来的架构问题，提前做架构准备（功能性&非功能性）。
我根据自己的理解又将其划分成两类：
目标是非常明确且可以用数字衡量的：比如性能问题是可以准确定义一个指标来衡量问题当前的具体的量化值的，RT 要降低到多少毫秒，QPS 要提高到多少，稳定性要提升到几个九等等。
基本上非功能模块都可以用数字来衡量，比如我们系统中出现的数据搬移的功能，都是目标明确，且可以用数字来衡量的。
或者比如系统的可扩展性要达到什么程度，是否满足 95% 以上的需求下不需要进行大量重构。
目标是不明确的：比如将来要走哪个方向，要做什么样的技术准备，很多的类似的场景是很难直接评估出一个度量指标的。
可能只有一个愿景和使命，根据这个愿景和使命来分解问题，然后我们才能设定通往这个理想的问题的路径。
而探寻到这个理想的过程是相当的复杂，要考虑的因素实在太多，我只能说这个东西我的经验真的不多，我只能尝试用我所学的内容来进行自顶向下的推导，而以目前的功力实在很难保证结果的正确性。
②解决架构上当前已经发生的问题：架构上的问题已经发生了，要对架构当前的问题进行识别，定义，以及解决（功能性&非功能性）。
③解决当前架构合理迭代的问题：我们在架构上进行大量迭代，迭代过程中往往容易给架构挖坑埋雷，我们应该尽可能避免这样的情况发生（功能性&非功能性）。
这三大问题正是各线任意一个粒度的架构师需要明察，并时刻提醒团队的三大问题。如果无法定义这三大问题，那么这里可能就是最大的问题。
这里还要阐述一个问题：即使是未来的架构，我们还有分类，一类是你走在最前面，一种是你跟着别人，你跟着别人要怎么跟上去。
这里应该有个决策分支，告诉我们遇到什么场景的时候应该用什么样的思考方法，不过这只是个人总结，每个人脑海里应该都有一套类似的方法，而且这套方法是在不断的突破和修正的。
问题定义中的常见问题
误把方法/手段当“问题”
接下来，我编了三个小故事，大家从故事中感受一下手段和问题的区别，以及我们如何才能避免把手段当做问题。
案例一：鲧治水着重在堵的方法上，毕生精力都在思考如何更好地堵。
老师：请问这里的问题定义是什么？
小明：这里的问题是如何堵！
老师：其他同学也说说这里的问题定义是什么？
小红：这里的问题是洪水和生命财产的矛盾！堵只是解决这个问题的方法或手段。
老师：如果问题的定义是问题是洪水和生命财产的矛盾，堵只是方法，那么还有什么方法可以解决这个问题？
小王：还可以用疏通的方法来治水。
小白：我们还可以搬走，以避免水患。
老师：恩，这也是一个思路。
案例二：如果我问我们的客户他们想要什么，他们会告诉我他们需要一匹更快的马。——亨利福特
老师：请问这里的问题定义是什么？
小明：这里的问题是如何让马跑的更快！
老师：还有其他同学能说说这里的问题定义是什么吗？
小红：这里的问题定义是如何更快的到底目的地，马只是一种手段。
老师：是的，如果马只是一种手段，而不是问题的定义，请问还有什么什么手段可以解决我们提到的问题。
小王：根据目的地的距离的不同，我们可以选择坐飞机，坐火车，开汽车。
小明：老师，我不知道自己不知道，我不知道有汽车，火车，飞机，我只知道马，所以我想到的就是如何让马跑的更快。
老师：是的，我们的局限往往是受限于我们的认知，这种情况不可避免，唯一的方法就是不断的学习，提升自己的认知。
案例三：如何做好资金防控？
老师：请问这里的问题定义是什么？
小明：这里的问题是如何做好资金防控，怎么防，怎么控。
老师：还有其他同学能说说这里的问题定义是什么吗？
小红：这里的问题定义是如何避免公司产生资金上损失，防控只是手段。
小白：资损防控解决直接问题是避免公司产生资金和名誉的损失，这个问题背后更深层次的是社会信任的问题。
老师：小白，你的名字虽然叫小白，但是你的思考一点都不小白，显然你在思考问题定义时使用了升层思考的方法，看到了问题背后的问题。
小明：老师，为啥我每次思考的时候，都是在思考解决问题的手段，都没有看到问题定义呢？
老师：那你可以尝试自问自答，比如你可以问自己资损防控是手段吗？自己给个回答，如果回答是 yes，那么再问自己：如果资损防控是手段，那么资损防控是解决什么问题的呢？通过这样的自问自答的方式，基本上我们可以较为准确的找到问题的定义。
小白：老师，我在想资损防控解决的是社会信任的手段之一，但是解决社会信任问题的手段不止一种啊。
老师：小白，你在思考问题时使用了升层思考，在思考解决方案时使用了升维思考，给你 32 个赞。
小白：谢谢老师，此时此刻我有点开心啊。
老师：保持心态的平稳，可以看到更多的东西，谦卑的态度没了，那自己的局限也就到了。
小白：谢谢老师提醒，我记住了。
三个故事看完了，总结一下，这三个故事的核心在于：
准确区分手段和我们要解决的问题本身，这种情况非常常见，我 Review 的很多技术方案之所以有问题基本都是问题定义没有搞清楚，所以解决方案也就不符合需要了。
思考问题背后的问题时使用升层思考，在思考问题包含的子问题时使用升维思考。
当升层思考之后，之前的问题可能会变成手段/方法。比如说用堵解决生命财产问题，堵是方法。升层思考之后，生命财产问题背后的问题是民生问题，此时保护生命财产就是解决民生问题的一个手段/方法。
当然当我们无法准确的分辨问题的时候，我们还可以不断缩短描述问题句子，比如提炼主谓宾，如果还不能清晰地描述，那么在这几个词里再找出最最最关键的词。
尤其是主语或者宾语中的词汇非常重要，它有可能就是重点，只是我们无情的忽略它了。
误把挑战当"问题"
当我们明确定义出问题之后，我们开始解决方案的升维思考，可以从各个角度来给出解决方案，这些解决方案就是我们前面说的手段/方法。
举例：如果快速到达目的地是目标，而马，汽车，飞机，火车只是手段/方法，那么如何让马跑的更快，如何让汽车跑的更快，如何让飞机飞的更快，如何让火车开的更快就成了挑战。
此时如果你说“让马跑的更快也是个问题啊”，确实，广义上也可以这么理解，但我不建议这样做，原因是这样我容易将问题和手段/方法搅混。
所以这里我尝试给他们一个定义，以明确他们出现的场景：
问题：事物之间在某个时期存在的矛盾，在本文的语境中尤其是指企业的客户和某种事物，趋势之间的矛盾。
挑战：解决矛盾的方案中最困难的几个地方。
接下来我们回到上述的几个案例中，来看看问题和挑战：
回到用堵治水的案例上：
问题定义：洪水和人民生命财产安全的矛盾。
手段/方法：堵水。
挑战：获取息壤，以筑三仞高堤，这是手段/方法的挑战。
回到福特的案例上：
问题定义：如何让人更快的到达目的地。
手段/方法：造汽车来让人们更快的到达目的地。
挑战：设计出更高的扭矩，更高的功率的引擎，更平顺智能的变速箱等等。
这样我们在沟通的时候，就能明确的知道对方到底是在阐述客户的问题定义，还是在阐述方案中的难点和挑战。
思考问题时缺少时间维度
单个问题在时间轴上的不同时期的严重程度是不一样的，比如说闭关锁国公元后 1500 年-1700 年是看不出太大的问题的，但是，300 年后的 1800 年，闭关锁国的弊端就开始浮现了，当然我们都是事后诸葛亮。
所以任何一个问题的严重程度都有一个时间轴，也许过了某个时间点之后，问题便不再是个问题。
比如外卖兴起之后，如何更好的制作一包方便面以满足用户的口味需求就不是一个问题了。
时间维度是一个极其重要的维度，任何事情理论上都必须考虑在时间维度上的影响，所以即使在定义问题上，时间维度也是一个不能不考察的维度。
所以才需要一个 Roadmap 的路线图，标注不同阶段要解决什么样的问题。
升层思考及升维思考
我们不能用问题发生时的同一层次思维来解决问题。
——by 爱因斯坦
爱因斯坦阐述了思维存在层次这一现象，这里我发表另外一个观点：我们不能只局限于问题本身，还需要看到问题背后的问题，然后才能更容易的找到更多的解决方案。
当问题升层思考之后，前面的问题会变成手段/方法，比如说洪水和人民生命财产的矛盾背后的问题是社会的稳定性问题（1 和 2 是升层思考），而升维思考洪水和人民生命财产的矛盾的时候就会发现用疏通治水或者搬走都是方案（3 是升维思考）。
这就是升层思考问题，升维思考手段/方法。不过这张图中每个问题到底严重到什么程度，还没有给出量化。
不过我们在工作中，我们是要量化这个严重程度，而且要放在时间轴上来进行量化，因为有些问题当前可能并不严重，但是数月后可能会变成大问题。
值得注意的是这里思考的升层是依赖认知升级的，就像一个小朋友，也许也能升层思考，但是其认知的程度决定了他思考能到的层度。
所以历史，社会科学，哲学也是我们的必修课，有助于我们认知到更高的层次的存在。当问题的层次不断提升的时候，往往最终会归结为社会问题和人性问题。
重要的话说三遍：
缺乏升层思考的升维思考是不完整的自顶向下
缺乏升层思考的升维思考是不完整的自顶向下
缺乏升层思考的升维思考是不完整的自顶向下
问题定义：如何给客户提供纪念品？
升层思考：客户需要纪念品的背后是想解决什么问题？是不是解决客户的旅游纪念的需求。
对背后的问题升维思考：要满足客户的旅游纪念的需求有没有其他方法？
明信片：明信片也可以做为一种纪念的方式，有了明信片做纪念，游客敲石柱的比例可能会下降。
现场照片：可以安排现场拍照的摄像师，选择特别的角度为这些想要留念的客户拍摄特别的照片，游客敲石柱的比例可能会下降。
帕台农神庙模型：可以制作各种帕台农神庙的模型，让客户购买，以满足客户纪念的需求，游客敲石柱的比例可能会下降。
对原问题升维思考：
在地上洒上大理石碎片：让客户以为这是帕台农神庙的大理石，客户会捡起地上的大理石碎片带回去留念（这是网上的标准答案）。
进入神庙时寄存各种金属物件：让用户无法用金属去砍古老立柱，缺点是成本高，效率低，需要排队检测金属物件。
把柱子围起来，让用户只能在一米开外的距离观看：用户碰不到柱子，自然无法去砍柱子，成本比较低，也比较容易实现。
写标语，在入口处，以及门票上明确指出破坏文物是违法行为，会受到法律的制裁，等等。
我想说的是，这里的升层思考，和不同层次的升维思考会给我们带来很多种方案，如果集合全团队的力量，我们甚至还可以想出更多更多的 Idea。
问题定义：如何不让窃贼拧下灯泡？
升层思考：不让窃贼拧下灯泡是为了解决什么问题？是为了解决预算不足的问题。
对背后的问题升维思考：解决预算不足有没有其他方案？增加预算？募捐？防止窃贼拧下灯泡。
对原问题升维思考：不让窃贼拧下灯泡可以从哪些维度进行考虑？
焊住：缺点是灯泡坏了之后很难更换。
反向螺纹（窃贼在拧下灯泡的时候其实是在拧紧）：缺点是窃贼只要使用逆向思维就能破解（反向螺纹是网上的标准答案）。
特别的螺纹（特别螺纹让窃贼拿到灯泡之后也无法在其他地方使用）：缺点是需要定制，成本高。
摄像头：缺点是增加了设备，需要更大量的投入。
把灯安装在更高的位置：窃贼得用梯子才能去盗窃灯泡，要看线路是否支持。
在灯泡上印上地铁专用标志：别人不敢买这种灯泡，窃贼无法销赃，缺点是多一道工序，灯泡的成本变高。
如果让整个团队使用这一思考方式，我们就可以得到更多更多 Idea。
是新问题还是新技术解决老问题？
小结
区分手段和问题
明确问题定义
对问题背后的问题进行升层思考
对问题的分解进行升维思考
作者：张荣华
编辑：陶家龙、孙淑娟
出处：转载自微信公众号阿里技术（ID：ali_tech）
精彩文章推荐：