工作中我们会遇到很多问题，特别是在软件开发的过程中，遇到的问题往往要更多。我们是怎么去解决这些问题的，我们的做法正确么？你有没有遇到过以下问题：

为什么有时候我们拼尽全力用尽聪明解决了问题，但是反而遭到了上司的批评？

为什么我们明明尽职尽责工作很努力，但是上司认为我们效率低下，完全达不到他的预期？

为什么项目和工程常常延期？

如果你不能很好的回答以上问题，那么这篇文章会让你受益匪浅！本文主要是为程序员所写，但是理论上对于其他行业也是适用的。

对的，今天我们要说的，是解决问题的方法。很坦白的说，大多数人在解决问题时，并没有在正确的时间做正确的事！所以才会有上面那些让人疑惑的问题。

本文主要观点有七个。

一、我们正在解决的问题其实不是问题

如果做一件事有A方式，但是采用A方式后遇到了一个拦路虎，我们会陷入到解决问题的泥淖里，在里面浪费很多时间，还不一定能解决。但是我们有没有及时意识到，其实还有B方式也可以达到目标。不否认，有时候我们花费1天2天3天1周能够解决这个问题，但是如果我们采用B方式，我们可能1分钟5分钟10分钟30分钟就能解决这个问题了。如果认真去算一下，这里的效率提升又何止100倍？!

有一句俗语，也是一句笑话——“有困难要上，没有困难创造困难也要上”，这句话用在这里真是太贴切了。我们有没有反思过，有时候我们是在给自己找麻烦？当陷入到问题里时，我们其实在做什么？对于大多数人来说——其实是在证明自己，证明自己聪明，或者证明自己不笨。但是聪明和智慧是有区别的，聪明的人能解决问题，智慧的人能跳出问题看问题。

所以，遇到问题不要马上开始解决问题，还是应该先认真考虑怎样去规避问题。做合适的选择，选择即妥协，选择即舍弃，想想算法实现的“空间换时间”和”时间换空间”，是不是这个道理？

二、以任务为导向 VS 以目标为导向

以任务为导向的人，眼里只会看到当前的任务，心里只会盘算怎么去完成任务，至于任务是为了什么，他们没有意识也不愿去关注和了解，他们往往会陷入到解决具体问题的泥淖里。

以目标为导向的人，有全局观，眼里看到的心里想到的都是怎么去达到目标，达到目标有几种方法，哪种方法比较稳妥不会遇到问题，一种方法遇到麻烦的问题时他们能很快速的切换到另一种方法，他们往往能比较快速的达成目标。

以任务为导向的人，会效率低下，达不到期望，没有长进，始终原地踏步；以目标为导向的人，会极有效率，超过期望，升职去做管理。你愿意选择哪一种？

三、期望和优先级

世界上最遥远的距离是——上司想要我们做成那样，结果我们做成了这样，上司想让我们先做那些，结果我们做了这些。当然，这和上司本身也有关系，但是和我们自身也有关系，这需要不断沟通和互相确认。

在搞清预期的情况下，合理的安排优先级，会更有效率。我们一般最好按照紧急程度、难易程度、任务切换成本来安排优先级，紧急又简单的任务自然最先做，紧急而稍难的问题其次。开始完成任务时，我们要优先完成目标的主要部分，以便问题尽早暴露。

四、成本考量

只要做事就是有成本的，包括时间、人力、物力和财力成本。做事时要兼顾成本，譬如在项目早期，可以采用现成的解决方案哪怕不那么完美（譬如开源方案），这样可以大大减少成本，到迅速发展期时再及时考量之前的方案是否还适用，不适用再寻找新的方案或自己搞定。现在已经是技术组合的时代，合理的组合各种现成技术能创造极大的价值。

五、尊重客观规律

古希腊物理学家阿基米德在洗澡时发现了浮力的原理，英国发明家瓦特在在英国格拉斯哥大学的草坪上想出了解决蒸汽机的有效办法，德国化学家凯库勒在梦中发现了苯的环状分子结构。

这三个故事有什么共同点？

这三个故事告诉我们——动机水平、问题难易和问题解决之间是有客观关系的。如下图：

动机引发与维持活动，对提高活动效率有重要的意义，但动机强度与活动效率之间并不是线性关系。一般说来，动机强度与活动效率之间的关系大致呈倒U型曲线，即中等强度的动机，活动效率最高。动机强度过低或过高，均会导致活动效率下降。

根据研究，每种活动都存在最佳的动机水平，这种最佳水平随活动的性质不同而有所不同，并且具有明显的个体差异。在比较简单的任务中，活动效率随动机的提高而上升；随着任务难度的增加，最佳动机水平有逐渐下降的趋势。

当我们遇到无法规避的难题时，如果一直钻牛角尖，对问题解决无益，最好先去做其他事，说不定你在做其他事的时候突然想到问题的解决办法。因为越难的问题越不能钻牛角尖！

六、解决问题的方法

善用搜索。

有可以使用的方案，不要重复造轮子。我们都会有强烈的创造和建造欲望。当我们重复造轮子时我们在做什么？我们在——我们还是在证明自己，不要证明自己，要超越自己！

善于提问。

善用工具帮助解决问题，譬如有些编程语言天然适合帮你做这种事，比如python。

七、解决问题的程度

在欧美家庭里，家长都会嘱咐孩子要 just right。

just right 即恰到好处。

想想我们做的那些事，过多的架构，不贴切和臃肿的基类，过度抽象，多余的自以为是的扩展性，是不是都违反了这个规则？长此以往，我们总会为自己做的错事负责。

做到恰到好处就好！

原创文章，转载请注明出处。http://xiezhuangping.github.io/problem_fix.html