《底层逻辑》本书作者是刘润，他在得到上开设了课程《5 分钟商学院》，我也是在得到上知道的这本书，这本书在豆瓣上的评分不是很高，褒贬不一，不过我看着觉得挺好。
看了一些豆瓣的评论，觉得这本书不好有这么几个原因：
书中的内容很多在公众号和《5 分钟商学院》中有写过，有点像是一个内容的合集；
书内容不是很系统；
觉得内容很鸡汤；
对我来说，首先这本书我很容易读进去，而且我之前也没看过公众号和《5 分钟商学院》，内容对我来说是全新的。
另外本书从是非对错、如何思考、个人能力提升、与人协作等方面来进行讲述，一些知识点对我来说还挺长见识和开阔眼界的。比如：数学思维中提到的概率论、数字的方向性、博弈论等，都能跟思维、认知结合起来。
今天再次看了下豆瓣的评分，已经降到 7 分以下了。不过豆瓣的评分只是一个参考，主要的还是看书是否能读得进去，是不是对现阶段的自己有用处。
下面说说我比较有印象的一些点。
1、事实和观点
事实：独立于人判断的客观存在，比如：今天的气温是 18 度。
观点：对事物的看法。会受到你的认知、当下掌握的信息和思维模式的影响，比如：我觉得今天很热。
不止一本书中都提到了事实和观点，比如在《沟通的方法》中，作者讲到作为沟通中的讲述者，需要时刻注意自己的语言中是在讲事实，还是带有情绪。
这对日常的沟通和管理非常重要，无论是对上、平级或对下，一定要做到的是只陈述事实，陈述事实就不会有个人主观情绪因素掺杂在内，不带情绪是良好沟通的开始。
教育小孩也是如此，我对女儿说：“这种题这么简单，怎么总是做错了？”，「简单」是我的一种主观判断，而「总」也是我的一种主观印象，这样说话，女儿的情绪就会立即爆发，后面就无法正常地沟通的。这种场景以前经常发生。如果换成：“这道题的解题步骤有 3 步，我们一起来分析下”，就会好很多。
2、透过现象看本质
现象千千万，往往本质都是相同，这个相同的部分就是底层逻辑。在软件开发中有两个重要的地方需要看清本质：
跟客户需求调研时，要找到客户背后的真实需求，在《有效需求分析》等书中都有详细介绍；
代码出现 Bug 后不能只打个补丁解决当前的问题，而要找到根本原因。
只有找到这些本质的东西，才能算是在做正确的事情，否则看着很努力，却是在做无用功。比如产品中的 Bug，如果不找到根因，那就只能在外围打补丁，看似解决了问题，但代码会越来越混乱，总有崩溃的那一天。
这些本质的东西往往埋比较深的黑盒子里，书中将这个黑盒子比作一个系统，系统是由一些元素和之间的关系构成（软件好像也是如此），然后将系统分成了 5 个模块：变量、因果链、增强回路、调节回路和滞后效应，这几个概念看书时能够理解，但怎样用到实际中，我还没有想好，也就是说没有形成自己的知识。
3、几种思维模式
在思考问题的底层逻辑一章中，讲到复利思维、概率思维、数学思维、系统思维几种思维模型。其中数学思维让我很受启发。
我们大学都学习过微积分，但毕业就还给老师了，书中用简单的例子来解释了什么是微积分，还将其延伸到我们的日常生活，就是要用动态的眼光来看问题。
对程序员来说，能够拥抱变化，快速响应需求，得益于长期以来的代码重构、优化等，这是一个累积的过程，这就是积分；而当系统出现问题，事后复盘时，不能只看出现问题那一刻的现象和特征，而是要顺藤摸瓜，找到最小的触发点，这就是微分。
作者确实很善于总结，这种能力是值得学习的。
4、知识、技能
在《好好学习》一书中，成甲认为只有能改变你行动的才是知识，否则只是信息，刘润觉得知识是已经被发现和证明的规律，是确定的。
我更认同成甲的定义，而且我认为行动不局限在动手去做，思维方式上的转变也算是行动。有句名言：学了很多知识，知道很多道理，但依然过不好这一生。原因就是，了解到的只是信息，而不是知识。
技能是一个具体的，可操作的，通过重复训练能够学会的能力，比如：游泳、骑自行车、演讲等，这里的关键是重复训练，别人教的、书中讲的都是学习技能的步骤，而不是技能本身。
结合起来就是，通过书籍、公众号、等各种渠道获取大量信息，经过筛选、过滤、思考将其转化为自己的知识，这个过程中，需要学习很多的技能来加以支撑。
5、黄金三问
黄金三问就是对任何一项任务，要搞清楚要做什么？怎么做？为什么要做？
很多时候，我们提出的问题往往不是问题本身，而是解决问题的答案。比如：你让一个 Java 程序员看一个 .NET 项目的代码，分析一些业务逻辑，一会，他可能会问你，操作系统怎么重装？但真实的问题是怎么装系统吗？深入了解才知道是想安装 VS 来打开项目，但提示系统有些不兼容，想要升级系统。最初的任务是代码阅读，代码阅读可以用很多的工具，记事本、VS Code 都可以。
在需求调研的时候，客户给我们提的需求很多时候也不是真正的需求，而是客户自己针对问题想出的解决方案，就算我们“完美”地满足了客户提出的“方案级需求”，最终的结果也未必能让客户满意。所以需要用黄金三问去进行深挖，找到最底层、最真实的想法，才更容易达成共识。
产品经理在提需求的时候，多提提问题，可能问着问着，需求就不用做了。
