上学写论文时，流传着这么一句话，
『大家虽然不知道鬼的样子，却都在画鬼。』
当时，觉得好有道理啊，我们提出了各种理论模型，却不知道世界到底是什么样子。
没想到后来进入了软件行业，也会遇到同样的问题。
我们很多项目，发起人其实并不知道要做成什么，
只是想做这个，想做那个，
似乎把想做的功能都做完，项目就成了。
我们假想存在某个问题，甚至都没有去调查，
我们觉得别人一定会来用，甚至都没想着去接受反馈，
我们自以为现存方案的问题很多，甚至都没用过它。
这就是在『画鬼』，
是一群人憋着实在想做些什么的时候的宏观表现。
那么，我们积极向上的心态，不对吗，
我们想造福社会，推动进步，不好吗？
当然好，只不过要坚持一些设计原则。
痛点
学过软件工程之后，我们知道，进行需求分析时，我们得先确定需求的背景和目的。
为什么要做这件事，是什么引起的，动机是什么。
只有确定了问题，才能有的放矢。
这是对新项目而言。
而对于实际的项目，几乎都是以现有的解决方案为起点的，
我们还要问，当前方案的痛点是什么，哪里做的不够好，
这些问题的优先级怎么安排，怎样逐步解决它。
通过分析痛点，我们才能找到立项的原因。
不是我们想做什么，而是我们不得不解决它。
没有迫不得已的形势，事情就不会往前发展。
我们不要急着去解决问题，
而是先要确定，到底要解决什么问题。
应变之道
应变，是可以锻炼的。
看到每一个方案时，不妨考虑下，它们是怎样被设计出来的。
这样才能积累经验，在遇到困难的时候，找到切实可用的办法。
每一个解决方案，都是为它的目的服务的，
人们做了哪些折衷和让步，又是以何种程度达到目的的。
我们要学的，不是会用哪些招数，
而是，学会这些招数的创造方法。
由此，繁杂的方案就不会迷惑我们了，
像工匠能看到工具的问题一样，我们会看到方案的缺陷，和它们引起的新问题。
无招胜有招。
结语
不能确定待解决的问题。
给定一个问题，想不出适用的解决方案。
这是两个难点。
我们会假想一个问题，结果做完了以后才发现白费心思。
我们会用流行的解决方案，结果发现越走越远。
经验多了，熟练掌握各种框架类库之后，这两个能力并不会相应提高。
我们需要刻意的训练，才能学会『面向痛点的应变之道』。
Love of bustle is not industry. ——Seneca