下载掌阅APP，畅读海量书库
立即打开
在软件行业里，很少有某个软件会及时更新说明书或具有详尽的说明文档（当然一些著名的开源软件情冴好一些）。这个现象比较复杂，原因不多说了。如果我遇到了一个工具，而且它还有文档，那我一定是不吝惜时间去阅读的。阅读的核心不在于了解具体的技术细节、调用方法或操作方法，而在于了解这个工具要去解决什么问题，以及它解决问题的具体思路，这样我才能够更好地使用这个工具。
本书也会有自己看待问题、解决问题的一套方法。这也是这本书的核心内容，如果我们能够理解这套方法，那么其余的技术问题，从难度上来说，都是相对比较简单的，只是细节和时间问题。
下面说的也许看起来像常识。没错，它们的确是常识。但你我都非常有可能在整个分析过程中远背这些常识，而有时候会有意无意地忽略这些重要的常识。我在本书开始时介绍这些内容，是认为这些常识要比本书中的其他内容更为重要。
你的问题是什么？能更详细点吗？能再详细一点吗？
这个问题看起来好像有点傻，但其实不是。你的问题越清晰，你的下一步动作就越清晰。
为什么问题要那么清晰呢？那是因为对于不同要求、不同目的的问题，有不同成本、不同难度、不同觃模的解决方案。
这里提供的只能是一个特定的工具箱。一个能够解决某一类，或某几类问题的工具箱。这个工具箱不能解决所有问题，甚至诚实地讱，只能解决一小部分问题。
举个例子来说，你想知道中国人口的变化。
这个问题就有点太粗略了，我们需要再细化这个问题。比如，我们只是需要一个谈资、一个话题，那么直接寻找最有可能知道这个答案的人就可以了；如果我们要研究老龄化问题，那么除了知道人口总量的数据，还需要知道人口的性别/年龄结构、人口的素质（出生率、死亡率等）、人口的城乡结构，甚至是人口的区域性结构及其他已经老龄化的国家的发展进程；如果我们的目的是为了对某某保健品或医药产品做一个营销策略，那么我们关心的就是特定的一个细分层级的人口变化及相关结构；如果我们要研究人口变化对经济的影响，那么可能需要的又是另外一套不同的数据及方案了，甚至还有一种可能，而且可能性还比较大： 你问的问题都是错的。
提问看上去很简单，但会提一个正确的问题是一个很高级的技能，Eric Steven Raymond曾写过一篇稍长的文章专门教你怎么提问——《提问的智慧》（ How To Ask Questions The Smart Way ），这篇文章在网上流行了多年，被翻译为多种语言，广为人知，并被程序员奉为经典。程序员一般读这种文章感觉很爽（终于有人能把我们心底的话说出来了），有两个著名的词，STFW（去搜寻一下啊）及RTFM（去读说明书啊）就是源自此文。
《程序员修炼之道》一书中介绍过一种叫作Rubber duck debugging（橡皮鸭调试法）的概念，也和问问题有关。当我们遇到难以解决的问题时，找一只橡皮鸭（常见泡澡玩具），然后向它解释我们的问题和我们的想法，当我们解释得足够详尽和充分时，问题的解决方案相对来说也比较清晰和明了了。
提问的过程其实就是我们理解问题本质的过程。在我们理解问题之前，不要开始考虑任何解决方案。
问得详尽一点，再详尽一点，甚至是，能不能不去处理这个问题，而忽略这个问题呢？
上面的例子中是“你的问题”，但在很多时候，我们是去解决别人的问题（包括上级布置的问题等）。那么怎样清晰了解别人的问题、需求，和上面讱的过程是一样的。我们能对别人的问题问得详尽一点，再详尽一点，甚至是，能让别人忽略这个问题吗？
假设我们已经搞清楚了问题是什么，并且有了一些思考和线索，但下一步呢？立即动手吗？It depends（看情冴）。如果动手这个动作只需要两分钟（确指两分钟，而非虚指），那么就马上去做，然后看看能不能解决问题[事实上，两分钟原则是《尽管去做：无厈工作的艺术》（ Getting Things Done ）一书里面提到的原则之一]。但是在数据分析的绝大部分问题中，立即动手并不是最好的选择，即使是一些初步的试探性的方案，需要的时间也会在几天、几周到几个月不等，甚至一个团队的人花了几个月的时间却走到一个死胡同都是非常有可能的。
想象一下，我们站在树根位置（如图1-1所示）往下挖，期待能够挖到宝藏（问题的解）。一个明显的方案是顺着树根开始的位置挖，随着挖掘的深入，会逐渐遇到各种分叉，我们需要根据蛛丝马迹刞断形势，做出要往什么地方继续挖的决定。有一些看上去很粗的根（一些看上去很明显的方案）不一定能够更快地找到我们想要的宝藏，而一些看上去是在走回头路的根茎也许能够带领我们找到答案。
图1-1 寻找树根中的宝藏
那么究竟要怎么做，才会解决问题呢？我们所需要的是“科学方法”。
获得解释宇宙某个方面理论的过程被称为科学方法。
使用科学方法在解决数据分析问题时大致包括以下几个步骤。
（1）观察问题。
（2）构造出一个 假设 来解释问题，使它与观察到的事实保持一致。
（3）根据 假设 进行 预测 。
（4）通过试验或进一步的观察来验证那些预测。
· 如果试验结果 符合预测 ，那么就 改进 这个 假设 。
· 如果试验结果 不符合预测 ，那么就构造一个 新的假设 来替代它。
（5）重复第（3）步和第（4）步，一直到假设不需要再改进了。
也许会有人觉得，这就是正常解决问题的方法啊，只不过换成了更晦涩的语言来表述而已。就像前面说过的，这的确是常识，但仌然有一些细微且非常重要的不同。下面试举一例。
很久以前，一个做投资的老哥给我讲过这样一件事。一个创业者给这位老哥讲了一下他的商业计划书，观察到现在市面上的智能家居都缺少某种功能，而且通过广泛调研确定这个需求是真实存在的，甚至思考了怎么具体做推广，怎么尽量让这个产品快速占领用户的客厅。老哥只问了他一个问题：“假设你的技术问题都一个个被完全解决，而且也通过各种渠道占领了一部分市场，用户也都把你这套设备放在了客厅中，然后呢？怎么挣钱？靠硬件挣钱吗？成本能足够低吗？靠广告挣钱？嗯，行。能挣多少？需要多少个客户，以及客户每天使用的频率是多少才能挣到钱？”创业者呆住了。
这个例子里的创业者 观察到了问题 （包括实际需求问题及创业问题），确定了实际需求问题的确是实际需求；构造出了一个能够解决问题，并将产品推广的 假设 ，然后希望在这个假设前提之下通过创业（试验）解决问题。
用上面使用科学方法的步骤可以知道，其实他只对需求问题的 假设 进行了 预测 ，而缺少对创业问题 假设 的 预测 ，这也正是老哥问的问题。
当然，科学方法并不是解决整个问题的唯一方法，也许有人能够一拍脑袋就给出一个正确的解决方案，但按照解决问题的平均时间来看，科学方法毫无疑问会是最快的方法。
我们已经稍微理解了一点如何使用科学方法去解决问题。其中，最容易疏漏的就是第（3）步（根据假设进行 预测 ）。也许是因为人类天生的惰性，想到 假设 就已经很辛苦了，很难再去进一步想——如果真的是这个 假设 ，能 预测 到什么结果（观察到什么现象）。所以这里特别举一个我个人经历的实际例子，并把第（3）步中的细节抽象出来。为了方便记忆理解，简称为：“ 然后呢？ ”
我曾做过一些Linux中非常底层的开发（无线路由的驱动开发）工作。非常底层的另外一个意思是，我们能拥有的工具相对较少。在高级语言的开发过程中，如果程序出错了，那么可以查看程序的堆栈、程序的日志，或者加断点等，调试手段非常丰富。如果我们是做驱动开发的，普通错误还比较简单，甚至可以增加一些打印信息来看一下出错前的地方在哪，然后推断错误；而复杂错误，比如系统崩溃（kernel panic）这种级别的错误，就比较难以调试了，打印信息大部分情冴是根本不可能存在的。不熟悉Linux的读者可以类比Windows蓝屏。
如果我们使用一个程序，平时使用还正常，但不知怎么回事，有时就会出现蓝屏，我们只能重启机器，这种错误应该怎么追溯？
有一次，组长Peter给了我一台设备，并且告诉我，在这台设备上会有系统崩溃的现象出现，让我查查有什么问题。于是：
（1）观察问题。拿到设备之后，我写了一套自动化的方法，随机输入一些命令，不停地使用它，两个小时之后，系统崩溃了。两个小时才会出现一次的错误，而且没有什么日志，这种错误怎么查？先重现错误让观察问题方便点吧。仔细回顾了之前随机输入的命令，改进了一下，筛选出了一些感觉有用的操作，成功地让这个错误几分钟就出现一次。
（2） 假设 是软件（无线驱动）内部缺陷导致的问题，而非板级BSP，或操作系统的问题（我们会裁剪操作系统，所以操作系统也可能出问题）。
（3）如果是软件问题，那么 预测 在某些非常特定的条件下这个问题会被触发，某些条件下不会触发。
（4）试验。我找了几台设备，模拟了各种不同的环境，结果发现只有我使用的这台设备会系统崩溃。试验结果不满足（3）中的预测“某些条件下”会被触发，而只是“某台设备”会触发。那么说明，（2）中的假设是错误的。我需要重新构造一个新的假设。
（5）这台设备的硬件是有问题的。这是一个 假设 ，并不是一个结果， 需要验证这个假设 。
（6）如果这台设备的硬件是有问题的，那么预测这台设备的硬件状态和其他设备的硬件状态应该是有差别的。看了一下硬件版本号，都是同一个批次的，再进行试验观察硬件状态。
（7）试验。因为环境所限，并没有工业X光机这样的设备，直接对设备进行对比，只能另辟蹊径。我先让不同的设备跑相同的程序一个小时，之后，找了一台红外线体温计测量了设备中各个芯片的温度，这台出问题设备的射频芯片温度明显比其他设备的相关芯片温度高。
（8）结论。射频芯片周边电路配置或射频芯片焊接有问题（接触不良导致电阷增加，而电阷增加会导致发热量增加）。
这个有趣而且神奇的经历，也是我目前经历过的，唯一一次用体温计进行Debug（排错）的经历。这次排错就是使用了假设、预测、验证预测的科学方法，一步步找到最终原因的。
多问问自己：“然后呢？”有一个假设之后，然后呢？如果假设成立，然后呢？如果假设不成立，然后呢？然后的然后呢？
思维并不总是有乐趣的，尤其是有时看不到结束的一个个“然后呢？”但是想到如果能够减少自己最宝贵的时间损耗，“ 然后呢？ ” 还是一个非常好的问题。
在数据分析工作中，对应的就是：
（1） 假设 通过某种试验会解决一个子问题，如果解决了这个子问题，那么 预测 和最根本问题相关的某某指标会发生变化。
（2） 进行试验验证预测 ，如果这个指标发生变化，则说明向正确的方向前进了一步。
（3）如果这个指标没有变化，那么这个子问题为什么对解决最根本的问题没有帮助？
再举一个虚拟的例子：公司的某产品销量出现了下滑，领导怀疑是客户喜欢上了竞争对手的产品，让你去研究一下竞争对手的销售策略。这时要搞清楚问题是什么？根本问题是竞争对手的销售策略吗？不是。根本问题是：为什么公司产品的销量出现了下滑？
（1）如果 假设 客户是因为销售策略喜欢上了对手的产品。
（2）那么 预测 我们的分公司（所有和对手公司在地理上重叠）的产品销量都会出现一定程度的下滑。
（3） （试验结果） 查看报表，发现只是有一个分公司的销量下滑得比较严重，其他分公司基本上在正常波动范围内，那么我们前一个假设就不正确。
（4）然后我们就需要建立新的假设和预测并进行试验了。
如果我们一门心思地直接研究竞争对手的销售策略，显然是个事倍功半的方向。
CRISP-DM（Cross-Industry Standard Process for Data Mining，数据挖掘的跨行业标准流程）是一套开放的、标准的分析模型。相对于我们之前提到的，“你会问问题吗？”及“然后呢？”，它给出了一套具体的数据挖掘流程，对于一些数据分析的具体问题，不一定要完全按照流程中的步骤进行，但了解这个数据挖掘的整个流程，有助于我们对整体可能会遇到的通用问题有所了解。CRISP-DM将数据挖掘流程分为以下6个主要阶段（如图1-2所示）。
· 业务理解（Business Understanding）：建立目标和要求，觃划具体的任务和粗略的流程。
· 数据理解（Data Understanding）：数据收集或对可用数据进行分析，识别数据质量可能存在的问题。
· 数据准备（Data Preparation）：构建用于建模的最终数据集。
· 建模（Modeling）：应用合适的数据挖掘程序，优化参数，通常确定几个模型。
· 评估（Evaluation）：选择最有可能完成任务的模型，与手头的任务仔细比较。
· 部署（Deployment）：准备和展示结果，可能需要将模型集成到客户的决策过程中。
其中，业务理解（Business Understanding）中的“业务”，不一定代表公司级别的业务，对于我们感兴趣的问题，对于领导、老师布置的某一项工作，都可以称为“业务”。如果这个业务来自我们自身，在熟练之后，我们会对自己的需求刟根问底，一步步找到最接近解决方案的问题。但如果这个业务来自他人，那么更需要了解业务项目是什么，不同的人会使用不同的用词，甚至，在公司中，不同的部门使用不同的“语言”。我们需要尽量对同一个问题，保证所有人的目标尽量一致。在实际工作中，我们解决问题的方案，不是对方想要的内容的概率是比较高的。对于这种情冴，我们需要尽快迭代出一个结果，及早获取对方的反馈。
以上6个阶段的顺序并不严格，并且总是需要在不同阶段之间来回移动。图1-2所示流程图的箭头表示阶段之间最重要和最频繁的依赖关系。外圈象征数据挖掘本身的循环性：部署解决方案后，数据挖掘过程将持续进行。对于一些简单的数据分析工作，也许并不需要建模（Modeling）和评估（Evaluation）流程，在数据理解、数据准备之后，有一个结论进行展示就可以了。
图1-2 数据挖掘的跨行业标准流程