I：即战力是一种不管在什么情况下都可以快速高效的投入工作的一种状态，想要达到这样的状态，其中的一个能力就是解决问题的能力。
当然我们这里说的解决问题的能力并不是我们通常说的遇到一个问题，然后解决问题的那种能力。而是一种追本溯源，从本质上解决问题的能力。
听上去有点抽象，我们来看一下解决问题的具体步骤就清楚了。
第一步：找到问题的本质
很多问题我们可能看到都是事情的表面，没有找到事情的本质。所以经常会出现解决完这个问题，下一个问题又出现了，每次都是做无用功。
第二步：问题为什么会发生？
找到问题的本质之后，就要开始问自己为什么会发生这样的问题。是什么原因导致的？是公司制度问题，还是没有及时沟通……。
第三步：提出假设，并验证
在第二步的时候，我们提了很多问题，以及原因。有些原因我们一眼就可以看出来，但有些原因却需要通过验证来排除。
以上的三个步骤组成了解决问题的一个循环结构，如果我们一旦发现哪一步有问题，就要及时的返回去修正。
A1：
昨天我在公司搭建了一个新的服务器和数据库。因为这个服务器是为下半年做项目准备的。所以现阶段要先开始测试，以及试运行。
我把之前数据库的表结构复制到了新的服务器上，因为是新项目，所以需要配置用户，项目信息。
在我把信息都配置完之后，我开始测试软件，但是这个时候，软件一直报一个错误，显示有个字段是空的，不能修改。
那怎么办呢？（好在程序猿对解决问题还是有经验的）
1.我把软件连接到了另外一个服务器上操作，显示正常。那基本可以排除软件问题，问题发生在服务器的数据库上。
2.数据库上容易发生的错误，就是信息配置错误。（按以往的经验判断）
3.调试跟踪代码，看问题出在哪？
这是我以往的解决问题的思路，但是这次还是失算了。我调试了整整一早上，跟踪的结果显示各个部分的数据均正常，但是一旦将数据插入数据库就开始报错。
当时快奔溃了。
但好在根据出错的提示，我就在想，会不会是字段的结构有问题？
然后查看了数据库的表结构，发现表多了一列属性，也不知道是哪里来的。于是，我修改了表结构之后，又重新调试了一下。
哎，这下就正常了。
在这个经历中，其实解决的办法也是遵循之前说的三个步骤的，只不过我在第二步，做出了错误的假设，导致了错误的结果。但好在及时发现。
问题到这里其实已经算解决了，但是如果继续深入的话，还是有问题。比方说既然是复制的表结构，为什么数据库表会多了一列？
是数据库的问题，还是不小心的人为？
这其实又是新的一轮问题。（但这个我并没有做，以后可以补上。没有做的原因一个是因为时间有限，另一个是因为弄这个真的好烦。）
编程可能很多人没有经历过，那我就再举个我之前看到的一个例子。
话说一个电梯，因为电闸的原因，导致电梯速度变慢，刚开始大家没觉得，但是时间一久大家就开始抱怨说电梯慢。
这时我们的主人公小明就接到了这样的任务，他心想抱怨电梯慢，不就是因为大家在电梯里无聊嘛。
于是在电梯里面摆了一面镜子。镜子一摆果然大家的抱怨变少了。但是过了一段时间之后，大家又开始抱怨了，因为有人在镜子上乱画东西。
小明一看，哎，你既然想画，那我干脆再放面镜子，还放上笔，让大家随意画。就这样又过了一段时间，大家又开始抱怨电梯乱涂乱画。
其实这个问题很简单，修一下电闸就行。但是因为问题的本质没有找对，就陷入了无休止的问题中。
A2：
虽然我在A1中举的是一个还算合格的例子，但是不要忘了我在大学学的就是软件工程，这样的问题以及解决思路早已经使用了不知道多少遍了。
但是，很多事情都有但是哈，我这个也有。
除了在编程中，我有没有按这样的步骤解决问题呢？
答案是没有，因为实际生活中我们遇到的问题远比编程复杂，我们很难一眼就找到问题的本质，另一方面我们的假设验证并不那么有效。
为什么这么说呢？
其一：假设的原因有很多，很难一一排除，而如果都去验证的话，那么时间成本和精力成本太大。
比如一个人写文章，没有人看。怎么办？
那么可能的问题和假设就太多了，标题不好，逻辑不清楚，话题不吸引人，排版不行，故事性不够……。
其二：有些原因可能并不具备验证性
比如今年公司搞丢了一个客户，找本质的时候，有两个原因，一个是沟通问题，一个是制度问题。
可能沟通问题还可以验证，但是制度却是不容易验证的。
那是不是说明这个步骤对我们的用处不大呢？
恰恰相反，正因为实际情况的复杂性，才更需要这样一个方法去提升我们解决问题的能力。
万维钢是我很喜欢的一个作家，但是在这之前他其实是一位物理学家。他就曾经为了提高写作的能力，用之前提到的三个步骤训练过自己。
为此呢？我准备效仿一下万维钢老师，做以下两件事情。
1.关于学习，阅读方面的困惑和问题，按解决问题的三个步骤，去找答案，并写成系列文章。（在这周末之前，解决怎么样记笔记更高效的问题。）
2.关于文章的风格问题，尝试一下不同的写作风格，但是这个事情暂时还没有头绪，先待定。
